WinMove is broken on Windows 10

[gallaxhar]

WinMove isn't doing what its expected to do to the visible regions of the window, like it does in older versions of the OS
At the same time it's not doing what native Windows 10 does to size/pos windows
At the same time it's also not doing what I want it to do, but what I want is irrelevant. The intended behavior is what's important, and that's what's wrong here.

Does a user ever need to interact with the invisible portion of the window, where they can't interact with the exact edge of the window?
If not, then what is the purpose of that invisible portion of the window taking up screen space?
The answer is, there is no reason invisible border windows to take up visible screen space after a WinMove. AHK is simply lazy at the current time in how it handles Windows 10 WinMove's, so it just lets that useless frame occupy space.
That is a design flaw which results in buggy behavior by WinMove on Windows 10, whether or not it is ever addressed. When a unsuspecting AHK user actually uses WinMove on windows 10, and runs into this very real problem, they have to debug, and try to figure out what's going on.
They test windows 10 by snapping windows correctly, and determine that Windows 10 can do it right, but AHK can't do it right, then they go to the forum to let others know this, and are told by a great many people that AHK is doing it right, but also Windows 10 is doing it right, even though two different results happen, and therefore their program is actually bug-free, but still has the bad behavior, then they resolve that AHK is no longer maintained for new operating systems. If AHK works with windows 10, hey that's great! If it doesn't, well, the project is up to you, since it apparently only has one main developer that likes the way AHK works on pre-windows-10.

[Bruttosozialprodukt]

I don't really understand why you compare AHK with Windows 10. They are two completely different things.

AHK's WinMove is probably using the same internal WinAPI function as the program responsible for snapping windows.
My guess is, that the dwm (or whatever is responsible for snapping windows) is simply compensating for the invisible borders by using some math before calling the WinAPI function that moves and resizes a window.

And since the dwm on Windows 10 has to compensate, AHK scripts have to compensate, just like any other program that has been written to move windows.

As a nice workaround it might be possible to register an event that gets called every time your script calls WinMove and have it compensate for the offset. This way you wouldn't need to modify your existing code.

[gallaxhar]

It doesn't make much sense for every individual ahk script, and every individual ahk-user to have to mathematically compensate for a universal phenomenon on Windows 10 top level windows.
It only makes sense that AHK internally does this.
When it doesn't, you offset the work the few have to do to make it work natively, to everybody else. For something as primary as a window, I'd consider this a bug, since on the homepage AHK claims to automate Windows, and the operating system is probably named Windows because it has to do with windows themselves.
Having to concoct workarounds to work with simply sizing window on a single monitor on a fresh install on Windows, seems like one of the only things you shouldn't have to do in AHK yourself..

[sinkfaze]

It doesn't make much sense for every individual ahk script, and every individual ahk-user to have to mathematically compensate for a universal phenomenon on Windows 10 top level windows.

If Windows isn't doing it for you, then AHK isn't doing it either. That's what AHK is, in essence, a user-friendly language for utilizing Windows' internal capabilities.

It only makes sense that AHK internally does this.

You are in a vast minority of people who think this.

Having to concoct workarounds to work with simply sizing window on a single monitor on a fresh install on Windows, seems like one of the only things you shouldn't have to do in AHK yourself..

I think this discussion has been pretty clear on the fact that this is more than "simply sizing a window". Most of us here have written our own functions to work around issues that annoy us but aren't important enough to change AHK's code. Give it a try.

[Bruttosozialprodukt]

It's not only AHK, it is every single program accessing that WinAPI functionality.
But since weird hacks have been implemented before to make AHK commands work the way the user would expect, it might actually make sense for AHK to internally compensate for this.

I remember that WinActivate for instance calls its WinAPI function up to 6 times.

[gallaxhar]

what could be more important of a fix for Windows 10 users than the easy ability to size every single Windows 10 top-level window based on its useful, visible, frame (this is a universal mathematical offset apparently, minus the invisible frame)? Like really, name one new feature in ahk v2 that warrants more developer attention than something so primary as enabling the newbie AHK user to actually size a window like they expect to, from previous window-movement knowledge, or using ahk on a previous windows OS.

I'm pretty sure AHK doesn't intend users to work with invisible window frame's using WinMove, it's not like someone would choose to put that hindrance in the AHK code if it was extra work to do so, since the invisible region is utterly useless to end users and ahk developers alike. It seems to be an unhappy side-effect of one of Microsoft's bad ideas, but regardless of why the bad behavior came about, it still should be considered bad behavior. Using the "it's Windows's fault" excuse, then every single bug in AHK could be chocked up to "it uses windows underneath, and if windows had done things differently, it could work more easily".

[sinkfaze]

what could be more important of a fix for me and a couple of other Windows 10 users...

Fixed.

I'm pretty sure AHK doesn't intend users to work with invisible window frame's using WinMove...

No, it doesn't. Windows does.

Using the "it's Windows's fault" excuse...

You were told that any attempt on AHK's part to work around this issue may have other consequences, and it's not worth the additional development time just to run into that risk for an issue few people are complaining about anyway. That's not an excuse, that's reality. If you want to work around it yourself, you have been given tons of information on how to do so.

[gallaxhar]

quoting me with things I didn't actually say is pretty childish, I won't respond to you, even if your arguments are stupid
if you can actually respond with substance, rather than childish nonsense, maybe I'll invite you to the grown up table

[sinkfaze]

quoting me with things I didn't actually say is pretty childish...

And you telling a developer what he should be doing with the time he donates to this product isn't?

I won't respond to you, even if your arguments are stupid

I didn't make an argument, I gave you the argument that the developer already gave you. So you're saying that the developer is stupid? You're really going out of your way to not get help.

[gallaxhar]

I didn't request any help, if I did, I'd post it in the Ask For Help section.
This is a bug report.
At least one developer is already aware of the weird behavior on windows 10 from using winmove (which I didn't know when I made the original thread).
Now other people might become aware of it to, when they were not before, due to more exposure.
If making AHK work for something is hard to do, then that's a good reason not to implement it. Not even trying because it might be hard to do, or because it has potential risks, doesn't seem like a good reason, but that is not my decision or my purpose here, my purpose is to proclaim that yes, it is actually a problem, whether it gets solved or not.
That is speaking purely from a logical standpoint, of course what the developers decide to spend time on, is their choice.
However if the community's opinion (including mine) about what constitutes a problem in AHK doesn't matter, then why have a bug report forum at all?
Just to bait people in so you can yell at them for trying to help out with feedback?
Trust me I didn't come to this bug report forum to just waste my own time, or to try and get someone to hurry up and fix things, I've been around long enough to know that things don't work like that, especially at any speed.

Furthermore your reasoning is out of whack. I didn't call anyone stupid, I said your arguments (in a certain recent post) may be stupid, but I won't even address them, since the first childish tactic clued me in to the fact that you were not really concerned with cooperatively moving forward, but merely inciting more drama (in the last two posts at least).

[Bruttosozialprodukt]

Reading through the thread, I think Lexikos has given you a reasonable explanation for why AHK should not simply alter the behavior. https://autohotkey.com/boards/viewtopic ... 378#p87378
Just imagine (hypothetically) you had two windows that would be 5 pixels in width each.
What would happen if you were to place them directly next to each other (ignoring the invisible frame)?
Correct: The topmost window of the two would be the only one that you could click because its invisible border is completely overlapping the other window. So the user would click on the second window wondering why it doesn't receive a click event because he/she is actually just clicking the invisible border of the other window.

Nevertheless I would say that adding a command like #IgnoreWin10Borders, On would probably make sense. Or maybe a new option for the WinMove command directly.

[guest3456]

lol and he is still arguing with everyone

whats more likely?

1. self admitted AHK newb is wrong
2. the other 10 people (included the AHK developer) are wrong

@gallaxhar you claim that i was jut making random observations about your personality without knowing you, yet i wake up this morning and everything i predicted came true: you still haven't relented, you still haven't given in, you are still being stubborn and refusing to try to understand what people are telling you. and now you have 3-4 more people trying to help you understand. so my assumptions were correct, you've proven them. you will probably prove them further by responding again with more rants

[gallaxhar]

@Bruttosozialprodukt
While in theory that may seem like a good reason, a window that is 5 pixels in width each is an extreme case that is not really useful or the norm.. which should be obvious
In real-world situations, you can activate another window (just about anything over 5 pixels in width) simply by clicking on it past the 5 pixel mark, not hard to do at all.
Furthermore, let's use a little reasoning here:
Lexikos says that overlapping the invisible frames is a bad side-effect, yet windows 10 does this on purpose, so it hardly seems like a bad side-effect.
Just dock one window to the left on win 10, and one to the right, in the middle, the invisible "frame" apparently overlaps, but doesn't really cause any user-interaction problems in the real world, since most people don't aim to activate a window in the hardest possible spot.

@guest3456
according to you the only right course of action is to concede and agree with you, no matter what the facts are, that is simply stupid. you are still using number-games to try and seem like you have authority on truth, sorry that is not how the universe works. the universe doesn't care how many monkeys worship the sun-god, the sun-god still is false. facts stand on their own, truth stands on its own, regardless of how many agree/disagree. stronger arguments rely on substance not mobs. it's called a bandwagon, and it so much easier to agree with the majority, and to yell at the minority, than to actually use your brain and think of points concerning the actual topic.

[Bruttosozialprodukt]

If during the snapping-state the windows actually still have those borders, then that's actually a point that should not be ignored. (I'm still not saying that the normal WinMove behavior should be changed, though!)

While 5px wide windows may not be very realistic, a 5px overlap could still be enough to prevent a user from changing the size of the other window (dragging the visible border).

[guest3456]

@guest3456
according to you the only right course of action is to concede and agree with you, no matter what the facts are, that is simply stupid. you are still using number-games to try and seem like you have authority on truth, sorry that is not how the universe works. the universe doesn't care how many monkeys worship the sun-god, the sun-god still is false. facts stand on their own, truth stands on its own, regardless of how many agree/disagree. stronger arguments rely on substance not mobs. it's called a bandwagon, and it so much easier to agree with the majority, and to yell at the minority, than to actually use your brain and think of points concerning the actual topic.

you know you're delusional when^^^. its like dealing with an addict during an intervention. everyone telling him he's got a problem yet he thinks everyone else has the problem. lol

you need to get help

facts have been provided. make the borders visible like Lexikos suggested, and everything works on win10 just like win8/7/6/5/4. and then your arguments turn to sand. did you try his suggestion? no. did you try any suggestions offered to you? no. just more ranting. i was proven correct yet again

[gallaxhar]

I'm not currently looking for a solution/workaround, even though they are welcome if anyone else stumbles on those solutions. This isn't an ask for help topic.
I'm reporting the problem on WinMove/Windows 10 and arguing for why it should be fixed internally, whether or not that happens is not in my control.
Making the borders visible, or removing the invisible borders, are just other workarounds, again not the primary purpose of a bug report.
Arguments about fixing it natively still stand, whether or not you agree with them, doesn't speak to the validity of such an argument.
You're one of several here only ranting here without providing any reasons why it should/shouldn't be implemented natively, and without providing any insights to the Windows 10 behavior in conjunction with AHK..

[guest3456]

i've provided many insights, and so have others, please re-read the thread

[gallaxhar]

Yes, others have, and you did provide one insight in one post, at the very beginning, about Windows 10, and about how the bug is in Windows API, yet Windows 10 seems to be functioning just fine with window-sizing, so you're mistaken, there is no bug for Window Sizing in windows 10. The behavior we are concerned with, is how AHK utilizes windows api and doesn't take into account offsets related to the invisible frame.
so, besides the 4th post,
You're one of several here only ranting here without providing any reasons why it should/shouldn't be implemented natively, and without providing any insights to the Windows 10 behavior in conjunction with AHK..

[Bruttosozialprodukt]

Would you mind to just stop arguing?

In my opinion a new thread should be started in the Wish List subforum.
The fact that the snapping feature might be overlapping windows without causing any problems should be inspected further.
And I don't see changing the WinMove behavior as the only option. As I said something like #IgnoreWin10Borders, On could make sense. Or simply a new option for WinMove, just like ControlClick has its NA option to change its behavior slightly.
It might also be good idea to mention the Windows 10 borders in the help file. (In case that hasn't been done yet.)

[gallaxhar]

#IgnoreWin10Borders, On might conflict with win7 and before compatibility, if it forces winmove to always offset as if the script is running on win 10
so it shouldn't be a directive that executes before runtime probably

buggy behavior fixes are always wished for, but that doesn't make them more wishes than buggy behaviors
wish list is more for new features, not fixing existing ones to exactly match the end-result visual appearance of how a command works on previous operating systems

and I really wish they would stop contributing nothing but slander, but as long as they do I guess it will an exercise in how long it takes them to pollute their own thread, I'm not asking them to reply to mine