WinMove is broken on Windows 10

Report problems with documented functionality
gallaxhar
Posts: 143
Joined: 03 Sep 2014, 06:35

WinMove is broken on Windows 10

17 May 2016, 20:48

On Windows 10, WinMove does not work properly because when told to make the window the entire screen area, it pads the window above the taskbar, by about 10 pixels, and below the top of the screen, by about 10 pixels, and has about a 20 pixel padding on the left and right. I even tried WinMove, A,, 0, 0, 9000, 9000 and there was still padding on all sides, and above the taskbar.

It appears the way Windows 10 provides information about the screen area to AHK has changed.
Last edited by gallaxhar on 18 May 2016, 03:20, edited 1 time in total.
guest3456
Posts: 3453
Joined: 09 Oct 2013, 10:31

Re: WinMove and Sysget, MonitorWorkingArea are broken on Windows 10

17 May 2016, 21:48

gallaxhar wrote: On Windows 10, WinMove does not work properly because when told to make the window the entire screen area, it pads the window above the taskbar, by about 10 pixels, and below the top of the screen, by about 10 pixels, and has about a 20 pixel padding on the left and right. I even tried WinMove, A,, 0, 0, 9000, 9000 and there was still padding on all sides, and above the taskbar.
see WinGetPosEx:
https://autohotkey.com/boards/viewtopic.php?t=3392

gallaxhar
Posts: 143
Joined: 03 Sep 2014, 06:35

Re: WinMove and Sysget, MonitorWorkingArea are broken on Windows 10

17 May 2016, 21:53

While with a lot of effort that may help, even making WinMove set the width of a window to 43534890573485734853 will not make it fill the screen area. The only way is to use a different command, such as WinMaximize, but that won't allow you to set window position/size to anything except "maximized".

The underlying code that WinMove uses is not working correctly with windows 10. This has nothing to do with having the real window positions or not.
guest3456
Posts: 3453
Joined: 09 Oct 2013, 10:31

Re: WinMove and Sysget, MonitorWorkingArea are broken on Windows 10

17 May 2016, 22:54

gallaxhar wrote:This has nothing to do with having the real window positions or not.
lol, ok

guest3456
Posts: 3453
Joined: 09 Oct 2013, 10:31

Re: WinMove and Sysget, MonitorWorkingArea are broken on Windows 10

17 May 2016, 23:10

just to be clear

open up a window that is not maximized, and move your cursor to the left, right, or bottom edges. your cursor will go to the edge, and then at exactly the edge, the cursor will change to the resizing cursor, and will stay that way for approx 10px further out past the window. this shows that the window borders still do exist, but are merely invsible.

my guess is that WinMove merely wraps SetWindowPos anyway, so even if you thought this was a bug, then it would be a bug from microsoft's own api. but its not a bug as described. WinMove is working correctly: taking into account those invisible borders.

as noted, if you want those border offsets, you can use the WinGetPosEx function i linked, and then WinMove according to those offsets. i don't know whether using SysGet to get the x/yborders would work as well. you can experiment

http://stackoverflow.com/questions/3275 ... windows-10

gallaxhar
Posts: 143
Joined: 03 Sep 2014, 06:35

Re: WinMove and Sysget, MonitorWorkingArea are broken on Windows 10

17 May 2016, 23:34

you're just not getting it, even if I find out the ACTUAL window size I need to size the window,
WinMove will NOT make it take up the area close to the borders of the screen

Image

I understand it may be that Windows 10 native API may be lying to AHK about window positions concerning the code underlying WinMove, so maybe WinMove needs a tweak in order to account for that, under the hood, but what I'm stressing here is that WinMove is told to make the window 3000 width, and instead it makes it about 2544 width on a 2560 screen. If what you're saying is true about an "invisible border", then winmove can't solve the issue, because as the image demonstrates, try to stretch the window past the screen area is not working right. Furthermore, the top border doesn't have this behavior, so that seems fishy. Since I imagine such a command as WinMove is used a lot... should we just let it be, since Microsoft code is shitty, and subsequently this would basically become a Windows-Automation-Scripting-Language that now can't accurately automate window sizing in the current Windows OS? Of course not.

Windows doesn't seem to have a problem snapping windows correctly to the sides, top, bottom working area. Maybe WinMove is based on an outdated api only used for pre-windows 10 windows, and windows 10 has a new way to do it, based on snap, who knows.
Does nobody love AHK enough, and have the experience/knowledge to fix it? If so, the language should be considered no longer maintained/updated for new Windows OS'es.
guest3456
Posts: 3453
Joined: 09 Oct 2013, 10:31

Re: WinMove and Sysget, MonitorWorkingArea are broken on Windows 10

17 May 2016, 23:43

gallaxhar wrote:Does nobody love AHK enough, and have the experience/knowledge to fix it? If so, the language should be considered no longer maintained/updated for new Windows OS'es.
sigh

you would do well to be less certain about things

gallaxhar
Posts: 143
Joined: 03 Sep 2014, 06:35

Re: WinMove and Sysget, MonitorWorkingArea are broken on Windows 10

17 May 2016, 23:59

I ran WinGetPos on a maximized window, which does entirely fill up the screen except the task bar.
The result was: -8,-8, 2576, 1416 in x,y,width,height
WinMove on that window after it was removed from the maximized-state, with the -8,-8, 2576, 1416 paramters, and it Hugged the Left, Top, and Bottom perfectly, but not the right.
Obviously, one-or-more AHK window-related commands are just not jiving with Windows 10. I can see and verify that behavior, am I certain that it's happening, yes, am I certain as to why, no, but it's obviously not how it should be working, I'm also certain of that.


Also, I know people love AHK, I was highlighting how ridiculous your position was that we should shove this under the rug, because you suspect some custom function/script on the forums may be a possible workaround to an intensely used feature on the current OS this scripting language is intended to automate.
guest3456
Posts: 3453
Joined: 09 Oct 2013, 10:31

Re: WinMove and Sysget, MonitorWorkingArea are broken on Windows 10

18 May 2016, 00:07

and yet you continue with the same attitude

:shakeshead:

gallaxhar
Posts: 143
Joined: 03 Sep 2014, 06:35

Re: WinMove and Sysget, MonitorWorkingArea are broken on Windows 10

18 May 2016, 00:12

because there is nothing wrong with my attitude, if there was, there would be a need to change it
once again I contribute some useful feedback to the community
once again you make a bold and erroneous assumption

this time it's
so even if you thought this was a bug, then it would be a bug from microsoft's own api. but its not a bug as described. WinMove is working correctly: taking into account those invisible borders.
Sorry, no, WinMove is working correctly on windows operating systems other than Windows 10, perhaps, but not on Windows 10.
Even if what you said is true about the invisible borders, which is not actually the entire story as my latest example highlights, then WinMove should be updated on Windows 10 to account for the invisible borders, so the intended behavior works, not so you can maximize some partially-invisible windows. Just because some code runs, doesnt mean that it achieves the design goal in a new operating system. If I made a script which calculated your age, and it depended on the input being peoples birthdates, and the code worked, then you updated the typical input to be peoples conception-dates, then my code has a bug - it is giving incorrect results, even if the code runs, and it "used to function" or it "still functions with the birthdate", if I claim that it will calculate anyones age, like AHK implies it works on Windows, then it's not working correctly. We colloquially call this a bug..
Last edited by gallaxhar on 18 May 2016, 00:16, edited 1 time in total.
guest3456
Posts: 3453
Joined: 09 Oct 2013, 10:31

Re: WinMove and Sysget, MonitorWorkingArea are broken on Windows 10

18 May 2016, 00:15

you sure do have all the answers

did you study the code in the link i provided? play with the example?

did you read the other link i provided, of people outside of AHK running into the same issue?

you admit you are a newb to AHK, yet you are so certain about problems that you think exist. you would do well to be less certain. this should be in "Ask For Help", not "Bug Reports"

gallaxhar
Posts: 143
Joined: 03 Sep 2014, 06:35

Re: WinMove and Sysget, MonitorWorkingArea are broken on Windows 10

18 May 2016, 00:18

I believe you can find the people that want Microsoft to release code that works with all their legacy products in a nice, beautiful, elegant, way, either dead, or in the waiting-forever camp, or on a non-windows OS. Perhaps you should go there, instead of implying how AHK should not adapt to a changing environment..

I did not come to the bug reports section to ask how I can make windows size correctly with some workaround, I came to report a problem with the native built in commands WinMove and Sysget (work area option) on Windows 10. Your feedback about a possible workaround was welcome anyway, your preaching about how it's not actually a bug is simply wrong.
just me
Posts: 9406
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: WinMove and Sysget, MonitorWorkingArea are broken on Windows 10

18 May 2016, 01:22

Well, back to your OP:
On Windows 10, Sysget, MonitorWorkingArea gets the entire screen area, including the taskbar, this is not how the docs say it should function - the taskbar should be subtracted.

Code: Select all

#NoEnv
AhkVersion := "AHK " . A_AhkVersion . " " . (A_IsUnicode ? "U" : "A") . (A_PtrSize = 8 ? "64" : "32")
OSVersion := "Win " . A_OsVersion . " " . (A_Is64BitOS ? "x64" : "x86")
SysGet, MWA, MonitorWorkArea
MsgBox, 0, MWA / Screen,
(
AHK version:
%AhkVersion%

OS version:
%OSVersion%

MonitorWorkArea:
%MWALeft% - %MWATop% - %MWARight% - %MWABottom%

Screen:
%A_ScreenWidth% - %A_ScreenHeight%
)
---------------------------
MWA / Screen
---------------------------
AHK version:
AHK 1.1.23.06 U64

OS version:
Win 10.0.10240 x64

MonitorWorkArea:
0 - 0 - 1920 - 1050

Screen:
1920 - 1080
---------------------------
OK
---------------------------
gallaxhar
Posts: 143
Joined: 03 Sep 2014, 06:35

Re: WinMove is broken on Windows 10

18 May 2016, 03:22

Thanks just_me
I updated the title and OP
It must have been the winmove side-effect that made me think MonitorWorkingArea was not functioning properly (before I did the later tests)
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: WinMove is broken on Windows 10

18 May 2016, 06:55

galaxhar wrote:you're just not getting it
Right back at you.
I understand it may be that Windows 10 native API may be lying to AHK about window positions concerning the code underlying WinMove, so maybe WinMove needs a tweak in order to account for that, under the hood
Your eyes are lying to you. The window is larger than it appears.

It seems you're asking for WinMove to compensate for the invisible borders, placing them outside the area indicated by your coordinates. In that case, it is possible that the invisible borders will overlap with something else and get in the way - for example, if you were placing windows side by side, one window's edge would be inaccessible because it is covered by the other window's border.

Even if the "tweaks" were desirable, there's a significant risk of them backfiring. There's no reliable way to determine whether the borders actually are invisible; they could be visible in specific situations (like when the window is "snapped"), with specific combinations of window styles, in programs with custom window frames, or on all windows after some as yet unreleased Windows updates. If AutoHotkey falsely assumes there are invisible borders and eliminates them, the results are going to be even worse.
Windows doesn't seem to have a problem snapping windows correctly to the sides, top, bottom working area.
When you "snap" a window - rather, when the window manager "snaps" a window - the window manager knows which screen edge the window has been snapped to and can adjust the borders accordingly. It is evident that the window is in a different "state" than normal, because when you start to move the window, its size restores to what it was before it was "snapped".
Furthermore, the top border doesn't have this behavior, so that seems fishy.
What's fishy? There's no reason for the top border to be invisible. With the other sides, one could rationalize that making the borders invisible reduces distraction from the window's content, reduces the risk of clashing colours, or something like that; but even if you made the top border invisible, most windows would still have a title bar.
guest3456
Posts: 3453
Joined: 09 Oct 2013, 10:31

Re: WinMove is broken on Windows 10

18 May 2016, 08:34

lexikos wrote:
galaxhar wrote:you're just not getting it
Right back at you.
:thumbup:

gallaxhar
Posts: 143
Joined: 03 Sep 2014, 06:35

Re: WinMove is broken on Windows 10

18 May 2016, 11:58

Do you even have windows 10? You seem to be talking from the ignorance of not being able to see for yourself. In my first example, the top border is padded. In my second example, it is not. Using basic logic and deductive reasoning, you can easily discern that what you are proposing is NOT the full story. It is NOT just the invisible borders causing the problem, although it is part of it.


Never updating AHK because Windows 10 may change in the future is an extremely poor argument. AHK can add an option to size windows that are partially invisible, without breaking the retro functionality for everyone, took 2 brain cells to come up with that one! It can also try and detect when they are invisible if that is needed. Also it appears windows are the same size even when maximized on Windows 10, they just have the invisible-parts forced off-screen, again seems like you aren't using Windows 10 to see this stuff?

Also, why did you use your main account, and then your "guest account" to try and act like two different people think I don't get it? LOL
What a cheap/lame attempt at trolling
gregster
Posts: 8884
Joined: 30 Sep 2013, 06:48

Re: WinMove is broken on Windows 10

18 May 2016, 13:37

So, AHK's current main developer Lexikos is a troll ...?!? Heck, I didn't expect that :-)

p.s.: gallaxhar, if you don't like it here, you can always fork (well, if you can... but with the power of dedcutive reasoning you will work it out...)
gallaxhar
Posts: 143
Joined: 03 Sep 2014, 06:35

Re: WinMove is broken on Windows 10

18 May 2016, 15:03

p.s., as I claimed before, I'm a newb, so how could I possibly fork new working functionality? Should I forgo working and paying rent, therefore not have access to a computer, so I can learn to do this? Logical deduction is a marvelous thing, and now it's showing you and others in this post are simply intolerant of innocent bug reports.
AHK's main current developer or not, he was trolling *me*, in this post, with the dual-account character-attack trick.
even Hitler was a vegetarian because he loved non-human animals, just because someone does something good or bad in another area at another time, doesn't absolutely speak to their character at any other given place and time. I love Lexikos in general, and his bipolar alter-ego guest3456 or whatever, that doesn't mean I'm going to sugarcoat pointing out when they're mistaken, and neither do I expect they should sugarcoat it for me when I'm mistaken (as I have been in other threads and even partly in this thread, thanks to just_me).

Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 27 guests