WinMove is broken on Windows 10

[nnnik]

Do you even have windows 10? You seem to be talking from the ignorance of not being able to see for yourself.

He doesn't need to. He only needs to know how it works. A thing he can do by reading up about it. A thing you haven't done yet as far as I can tell.
You are talking from the ignorance of not knowing the things you are talking about.

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

Those are 2 different people.

[nnnik]

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).

Consider yourself banned if you compare anyone to Hitler again. There are rights of free speach and alike, but I'm not going to tolerate ungratefulness.

[gallaxhar]

You can't know the intricacies of Windows 10's buggy behavior unless someone fully documents this online. Some stackxchange posts etc are not full documentation of all the intricate scenarios, like what happens when trying to use AHK WinMove or WinGetPos on maximized windows, non-maxmized-side-dock windows, etc

Furthermore your interpretation of me comparing anyone to Hitler is completely mistaken
I was pointing out a fact of all humanity - we are complex creatures and just because we create something good (polyetherene) doesn't mean we aren't wrong or troll-like in some other aspects at other times and places.
Similarly if we do something bad, like kill a lot of people, we may do something society thinks is good at the same time - spare animals from butchery. This doesn't mean that person is beyond reproach, in other areas. I was pointing out the flaw in reasoning.

I suspect you knew that, but decided to pretend you didn't, because you don't like me - if so, then ask yourself how that behavior is tolerant of free speech? Are you really tolerant of it, or do you use it as a viel to your actual character?

[gregster]

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).

It seems to me that you lost contact to reality. Have a tea or work a bit at the punching bag...

By the way, as far as I remember, Lexikos referred in other posts to personal experiences with Win10.

[gallaxhar]

It seems to me that a simple bug report is still shoved under the rug as a Windows 10 problem, not an AHK problem, because many in this post failed to look at the subject objectively, and instead started assigning labels to things which are bugs as not being bugs, and starting focusing on the character of the poster, rather than the content of the bug report..

Fear not, I won't be bothering this section again, since it seems fruitless to try, as long as the current overseers of this subforum will chock up my efforts of reporting actual bugs to whatever they read after a quick google search about it. Why spend the effort.. If the people with the know-how don't care to investigate, I can't make them.

[Nextron]

Goodwin's law in action...
BTW: Which dual accounts? Can't it just be multiple users?

I don't like the window coordinate behavior either, but I see it as a W10 issue, for giving it an transparent bezel. Whether you see it or not, it is there, so the coordinates aren't wrong.

[gallaxhar]

The coordinates may not be wrong, but the WinMove behavior is wrong
If this is due to Windows 10 OS and not AHK, then in order to automate Windows 10 correctly AHK has to take extra (even optional for non-Windows 10 users) steps
If they don't, they can only hope that Windows 10 OS changes to suit their code, which I don't think Windows 10 gives a damn about AHK.

Surely you can see how the end user doesn't care about how the code runs for x command under the hood, only that a scripting language's built in commands work at the high level they are used at in the way they are used.. That is what a scripting language is about - using functions/commands that were solved right the first time, so every individual doesn't have to start from scratch..

[nnnik]

It's not fruitless to try here. But the implications of all arguments exchanged here might be extremely tough to understand if you do not have the proper expertise on the field discussed.
If you want to you can always fork on github.com:
https://github.com/Lexikos/AutoHotkey_L
There you can take the entire project. And fork it (meaning creating a clone that you can edit). Then you add the new functionality that you want to have to the source of AutoHotkey.
If your Fork is proving to be helpful the changes you made might get integrated into the main project.

To the topic: It is simply new behaviour added to Win10 that has (according to what I understood of Lexikos post) no official consistency.
If you add a tweak that fixes certain behaviour it might still be buggy or might not work with certain programs under certain conditions.
It then often needs a massive amount of adjustment before being in an accepteable state.
However that tweak might become completely obsolete with the next update.
Meaning you have to adjust the tweak again.
That leads to a massive amount of maintenance work. Work a single developer neither has the nerves nor the time for.

[gallaxhar]

mouse-dragging a window to the sides on Windows 10 reveals the padding the window will have
but instead it appears windows does an extra-step that fixes this padding when you use the snap-behavior

[guest3456]

Lexikos is the current active developer of AHK, and has been on record for using Windows 10 for a long time. if you think the developer is trolling you, then i don't know what to tell you

he is not me, i am not him, we are two different people. i have disagreed with him in the past in a similar situation when i wanted a new WM_MOUSEMOVE option added to ControlClick. i too am using Windows 10.

i told you multiple times that you were wrong, and that you should stop being so stubborn. you refused. then the developer of AHK told you you were wrong. you continue to be stubborn and not listen. now more people are joining in.

you can continue to _think_ you know what you're talking about, but you don't. you're only making yourself look worse each time. the WinMove behavior is not wrong. on all other OS, when you move a window to 0,0, you can still resize the left edge window if you choose. the same is true when you WinMove to 0,0 in win10. you are suggesting to compensate for the invisible borders, and actually move the window to -8,0. i guess thats what youre suggesting, but you're not clear because you don't even understand the problem, while everyone else does. i linked to code so that you can do that yourself.

internal microsoft api's all take into account those invisible borders as if they are part of the window.
SetWindowPos
https://msdn.microsoft.com/en-us/librar ... s.85).aspx
GetWindowRect
https://msdn.microsoft.com/en-us/librar ... s.85).aspx
GetDC
https://msdn.microsoft.com/en-us/librar ... s.85).aspx

feel free to DllCall those directly and see the results. speaking of which, why dont you attempt to take a screenshot of a window with GetDC and tell me what the screenshot looks like on win10. or try this: open a few windows. then right click on an empty space on the taskbar, and choose "Show windows side-by-side"

i suggest you take a deep breath, re-read everything thats been said to you, and try again to understand it.

you:
5 others:

[gallaxhar]

Windows 10 OS can correctly snap a window to the sides with no void space around the taskbar or right/left edge
It can correctly snap to quarter-corners as well
If a few internal API's take the invisible borders into account as the actual window, that is not the end of what Windows 10 does because it correctly snaps windows in the end, with no ugly visual effect either.
AHK doesn't do this for windows 10. WinMove is working, it's just not working correctly on Windows 10, yet Windows 10 itself is moving windows correctly.


You are trying to argue that the reason justifies the bug, which I continue to point out is a poor argument. AHK may adapt to Windows 10, or instead have a poor WinMove on windows 10 command behavior.

If every individual on Win10 has to discover this for themselves, go through the headache of using DLLcalls to try and hack it together for a simple window sizing problem, then AHK is not doing its job regarding properly sizing/moving windows the way users expect. Even if Windows 10 made the job of AHK harder (as should be expected of Microsoft) that doesn't mean we should lie down and just accept poor functionality, I hope.. I am merely reporting this, not proclaiming that others should fix it right now. I just wanted people to accept it as a problem/bug, whether or not they fix it is up to them, since I'm not paying them, and I have not enough experience to fix it myself. Instead what I'm receiving is this idea that AHK is perfect, and bugs/problems aren't actually bugs/problems, that way we can keep believing AHK is perfect, and windows is to blame for AHK not working as expected.. I don't see the logic in that, as AHK is supposed to make poor/nonexistent windows behavior easier to work with, and that's where I'll continue to be "stubborn".

Using numbers of people that don't agree with me to try and tell me my argument is false is another poor argument. Stip it out and use only arguments of substance.

[guest3456]

everyone has given you substance, you refuse to listen to it. thats fine. i gave you code to try, you didn't try it. i asked you questions, you didn't answer. i gave you more suggestions to try, you didn't try them. i told you to take a deep breath, you stayed in shambles. i told you to re-read, you didn't re-read.

what you did do is show an extreme ability to ignore everything and stay angry and stay stubborn. thats your perogative, and its unlikely you will ever give it up at this point. you've voiced your arguments too strongly where now its impossible for you to concede because the embarassment would be too much to face. oh well. i told you earlier you kept digging your hole deeper and you continued to ignore it. you've done it again

if you wanted to snap, then you should have said so: Send, #{left}

[gallaxhar]

I don't want to snap. I want to WinMove a window with potentially no voidspace except the taskbar, that is not always the same as snapping. Snapping using #{left} and the various other hotkeys would only work for a few cases. Furthermore, the Windows 10 snap hotkeys #{left} can be turned off indirectly by disabling the snap feature altogether in the Windows 10 Control panel, so that hotkey will not work reliably either.

You are again giving no substance, merely claiming that substantive argument was given previously, yet you can't seem to ever point exactly to this elusive contribution, because it doesn't exist. What you posted previously does not address the problem of WinMove not working correctly, it potentially, maybe, addresses how to work around WinMove. That isn't helpful for reporting a bug and making everyone aware of how WinMove has a problem, as this bug report thread is aimed to do.

You seem to have some crazy ideas about my personality and behavior, that you can't possibly know. You are assuming things about me that you can't possibly know. Put simply, you are projecting your own fantasies of me / who I am. These fantasies are worthless, but more importantly off-topic.

[lexikos]

It seems to me that a simple bug report is still shoved under the rug as a Windows 10 problem, not an AHK problem,

My feeling is that it is not any kind of problem. I prefer the current behaviour, and yes, I primarily use Windows 10. Yours is not the first post about this "bug". Aside from that, I've been aware of the behaviour since the day I installed Windows 10, used a WinMove-based script (as I regularly do) and saw the "gaps" for myself.

AHK can add an option to size windows that are partially invisible,

How can a program reliably detect whether a window is partially invisible? I'm of the opinion that it is not possible, as I've already stated, and you have not refuted.

You can't know the intricacies of Windows 10's buggy behavior unless someone fully documents this online.

Why would I have to read something online to know it?

If this hypothetical documentation were so important for a mere argument on an online forum, would it not be even more important for designing program behaviour?

You are again giving no substance, merely claiming

You've done that yourself, and as far as I can tell, you have addressed none of the important points of my previous post.

I want to WinMove a window with potentially no voidspace except the taskbar

What if you were to start by making the invisible borders visible?
http://www.tenforums.com/tutorials/7935 ... -10-a.html
http://winaero.com/blog/enable-the-hidd ... indows-10/
(I have not tested these myself.)

[gallaxhar]

How can a program reliably detect whether a window is partially invisible?

By detecting the operating system and if it's a top level parent window (is my first guess)
A_OSVersion https://autohotkey.com/docs/Variables.htm#OSVersion
and
Getparent https://msdn.microsoft.com/en-us/librar ... s.85).aspx

What if you were to start by making the invisible borders visible?

I'll be thrilled if this works,
but usually: 1) such workarounds have unintended side-effects
2) every newb that follows will have to first realize winmove is acting strange, then find the same or similar workaround, not exactly good for the AHK community, but perhaps some extra documentation on the WinMove page would help that issue
3) winmove will still not give the generally expected behavior (whether it's your personal preferred behavior or not) on windows 10 by itself, natively, out of the box, like it was originally designed to do

I can understand if it was a small subset of windows on windows 10 with an invisible border, but virtually every parent level window having one means that window sizing itself has dynamically changed on windows 10. If Windows 10 took the philosophy that you are on this issue, then every snapped window would have voidspace on Windows 10, and people would be raging on the internet about how ugly Windows 10 is. The reason that isn't happening is Windows 10 allows users to size windows with no voidspace (except the taskbar). Ahk doesn't allow this natively on Windows 10, but does on the other windows OS's, that's inconsistent with both Windows native behavior and AHK behavior on other window versions. Someone developing an ahk script which sizes windows on windows 7, for example, will be completely blindsided when their users on windows 10 say the sized windows have voidspace and arent behaving correctly. Said developer may spend an awful lot of time trying to figure out it's because AHK doesn't size windows like windows does, but instead sizes windows like AHK does on windows 7, which doesnt work on windows 10 the same way.

[just me]

Well, back again to the OP.

It appears the way Windows 10 provides information about the screen area to AHK has changed.

I'm pretty sure that's not true.

WinMove:

The X and Y coordinates (in pixels) of the upper left corner of the target window's new location, ...

In other words: The X and Y coordinates of the upper left corner of the window's non-client area / the windows's frame.

This has been no problem with prior versions of Windows, because the whole frame was visible. With at least Win 10 (I don't remember what Win 8.1 did) Microsoft decided to make parts of the frame on left, bottom and right sides transparent respectively invisible. But these parts still react on mouse events and are still parts of the frame. So positioning the frame at 0, 0 will result in a visible 'gap' on the left side caused by the unvisible/transparent frame.

The following script might give you an idea about what's happening:

Code: Select all

#NoEnv
Gui, +LastFound +AlwaysOnTop +hwndHGUI +OwnDialogs
Gui, Margin, 20, 20
Gui, Font, s10, Lucida Console
Gui, Add, Text, Section, Title:
Gui, Add, Text, xp y+5,Class:
Gui, Add, Text, xp y+5,Window X-Pos:
Gui, Add, Text, xp y+5, Window Y-Pos:
Gui, Add, Text, xp y+5, Window Width:
Gui, Add, Text, xp y+5, Window Height:
Gui, Add, Text, xp y+5, Client X-Pos:
Gui, Add, Text, xp y+5, Client Y-Pos:
Gui, Add, Text, xp y+5, Client Width:
Gui, Add, Text, xp y+5, Client Height:
Gui, Add, Text, xp y+5, Style:
Gui, Add, Text, xp y+5, ExStyle:
Gui, Add, Text, xp y+5, State:
Gui, Add, Text, xp y+5, Border Width:
Gui, Add, Text, xp y+5, Border Height:
Gui, Add, Text, xp y+5, Type:
Gui, Add, Text, xp y+5, Version:
Gui, Add, Text, vTitle ys w200
Gui, Add, Text, vClass xp y+5 wp 
Gui, Add, Text, vWX xp y+5 wp
Gui, Add, Text, vWY xp y+5 wp
Gui, Add, Text, vWW xp y+5 wp
Gui, Add, Text, vWH xp y+5 wp
Gui, Add, Text, vCX xp y+5 wp
Gui, Add, Text, vCY xp y+5 wp
Gui, Add, Text, vCW xp y+5 wp
Gui, Add, Text, vCH xp y+5 wp
Gui, Add, Text, vStyle xp y+5 wp
Gui, Add, Text, vExStyle xp y+5 wp
Gui, Add, Text, vState xp y+5 wp
Gui, Add, Text, vBW xp y+5 wp
Gui, Add, Text, vBH xp y+5 wp
Gui, Add, Text, vType xp y+5 wp
Gui, Add, Text, vVersion xp y+5 wp
Gui, Add, Button, xm gAddResize vBtnResize, Remove sizing border
GuiControl, , BtnResize, Add sizing border
Gui, Show, , GetWindowInfo()
WinMove, 0, 0
WindowInfo := GetWindowInfo(HGUI)
Update_GUI(WindowInfo)
Return

GuiClose:
ExitApp

AddResize:
Gui, +OwnDialogs
GuiControlGet, BtnResize
If (SubStr(BtnResize, 1, 3) = "Add") {
   Gui, +Resize
   GuiControl, , BtnResize, Remove sizing border
}
Else {
   Gui, -Resize
   GuiControl, , BtnResize, Add sizing border
}
WinMove, 0, 0
WindowInfo := GetWindowInfo(HGUI)
Update_GUI(WindowInfo)
Sleep, 1000
WinMove, , , 0, 0,  % WindowInfo.WindowW, % WindowInfo.WindowH
Return

Update_GUI(WindowInfo) {
   GuiControl, , Title, % WindowInfo.Title
   GuiControl, , Class, % WindowInfo.Class
   GuiControl, , WX, % WindowInfo.WindowX
   GuiControl, , WY, % WindowInfo.WindowY
   GuiControl, , WW, % WindowInfo.WindowW
   GuiControl, , WH, % WindowInfo.WindowH
   GuiControl, , CX, % WindowInfo.ClientX
   GuiControl, , CY, % WindowInfo.ClientY
   GuiControl, , CW, % WindowInfo.ClientW
   GuiControl, , CH, % WindowInfo.ClientH
   GuiControl, , Style, % Format("0x{:08X}", WindowInfo.Style)
   GuiControl, , ExStyle, % Format("0x{:08X}", WindowInfo.ExStyle)
   GuiControl, , State, % WindowInfo.State
   GuiControl, , BW, % WindowInfo.BorderW
   GuiControl, , BH, % WindowInfo.BorderH
   GuiControl, , Type, % WindowInfo.Type
   GuiControl, , Version, % WindowInfo.Version
   WinGetPos, X, Y, W, H
   MsgBox, 0, WInGetPos, X: %X% - Y:%Y% - W: %W% - H:%H%
}


; #FUNCTION# =======================================================================================
; Name...........: GetWindowInfo
; Description ...: Provides an object for the passed window handle containing the values retrieved
;                  by the  API function GetWindowInfo() and additionally the window title and class.
; Syntax.........: GetWindowInfo(HWND)
; Parameters ....: HWND       - handle (HWND) to the window.
; Return values .: On failure:   False
;                  on success:   Object with the following keys:
;                  - Title       : window title
;                  - Class       : window class
;                  - WindowX     : x-position of the window (screen coordinates - pixels)
;                  - WindowY     : y-position of the window
;                  - WindowW     : width of the window
;                  - WindowH     : height of the window
;                  - ClientX     : x-position of the client area
;                  - ClientY     : y-position of the client area
;                  - ClientW     : width of the client area
;                  - ClientH     : height of the client area
;                  - Style       : styles
;                  - ExStyle     : extended styles
;                  - State       : state (1 = active)
;                  - BorderW     : width of the vertical frame (pixels)
;                  - BorderH     : height o the horizontal frame (pixels)
;                  - Type        : "The window class atom (see RegisterClass)."
;                  - Version  : "The Windows version of the application that created the window." 
; Author ........: ich_L (de.autohotkey.com)
; Modified.......:
; Remarks .......:
; Related .......:
; Link ..........: http://msdn.microsoft.com/en-us/library/ms633516%28VS.85%29.aspx
; Example .......:
; ==================================================================================================
GetWindowInfo(HWND) {
   If !(A_PtrSize) {
      MsgBox, 16, %A_ThisFunc%, Diese Funktion benötigt AHK_L+!
      Return False 
   }
   If !WinExist("ahk_id" . HWND)
      Return False
   WinGetTitle, Title
   WinGetClass, Class
   ; Struct WINDOWINFO
   NumPut(VarSetCapacity(struct_WI, 60, 0), struct_WI)
   If !DllCall("User32\GetWindowInfo", "Ptr", HWND, "Ptr", &struct_WI)
      Return False
   ; Object WindowInfo
   obj_WI := Object()
   obj_WI.Title := Title
   obj_WI.Class := Class
   obj_WI.WindowX := NumGet(struct_WI,  4, "Int")
   obj_WI.WindowY := NumGet(struct_WI,  8, "Int")
   obj_WI.WindowW := NumGet(struct_WI, 12, "Int") - obj_WI.WindowX
   obj_WI.WindowH := NumGet(struct_WI, 16, "Int") - obj_WI.WindowY
   obj_WI.ClientX := NumGet(struct_WI, 20, "Int")
   obj_WI.ClientY := NumGet(struct_WI, 24, "Int")
   obj_WI.ClientW := NumGet(struct_WI, 28, "Int") - obj_WI.ClientX
   obj_WI.ClientH := NumGet(struct_WI, 32, "Int") - obj_WI.ClientY
   obj_WI.Style   := NumGet(struct_WI, 36, "UInt")
   obj_WI.ExStyle := NumGet(struct_WI, 40, "UInt")
   obj_WI.State   := NumGet(struct_WI, 44, "UInt")
   obj_WI.BorderW := NumGet(struct_WI, 48, "UInt")
   obj_WI.BorderH := NumGet(struct_WI, 52, "UInt")
   obj_WI.Type    := NumGet(struct_WI, 56, "UShort")
   obj_WI.Version := NumGet(struct_WI, 58, "UShort")
   Return obj_WI
}

The only mystery for me is that the reported windows dimensions which are equally retrieved by WinGetPos do not change. Edit: No mystery, I overlooked that Windows is adjusting the dimensions of the client area.

For me, it's definitely no AHK bug.

[gallaxhar]

Microsoft added those padded invisible borders to the frames of windows,
but they also implemented a way to handle those borders when you want to snap a window to the sides or quarter points, so that the improper side-effect having a void space never comes up natively. AHK brings this up because unlike Microsoft, it hasn't updated its code to handle Windows 10's new window frames in all scenarios.

You dont say your code which handles the old format is bug-free, just because it used to work or works on a different OS. It is not functioning properly on Windows 10, no matter if it's using the correct window size.

I can at least understand the position that "it's not working right, but it's too hard to change it" or "it's not working right, but we're fine with that", but the whole "it's working just fine, we love unexpected behavior" position is insane.

[just me]

Sorry, but moving and 'snapping' a window are different actions.

It is not functioning properly on Windows 10, no matter if it's using the correct window size.

Any proof on this?

[gallaxhar]

Yes moving and snapping windows are different actions,
which both result in a window being moved and/or resized

The proof that it's not functioning properly is that currently WinMove leaves voidspaces when you try to make a window occupy certain regions, such as the left 25% of the screen width and the entire height except the taskbar.

Of course, the argument so far is "WinMove is just putting the invisible borders to cover up part of that space"

Windows 10 is handling those invisible borders and making them not interfere with the window size/position that is desired.
AHK therefore isn't automating Windows 10 behavior, it's automating "what the developer of AHK would like windows to do" behavior, which is inconsistent with how that screen space is designed to be used (not voided for no reason).

Anyway, this is beating a dead horse, obviously you guys don't agree, the message that I got from this is it's every AHK layman for themselves to find workarounds from here on out when new operating system features come out. AHK can only accurately handle pre-windows 10 features, and all new features that give problems to AHK are not actually problems, they are shining examples of beautiful functionality.

[just me]

The proof that it's not functioning properly is that currently WinMove leaves voidspaces when you try to make a window occupy certain regions, ...

This only proves that WinMove isn't doing what you want it to do under certain crircumstances. It doesn't prove a wrong behaviour or a bug.