In my 10.13 tests, I’m noticing that when I drag a window (by grabbing its titlebar and dragging with the mouse) I’m getting a bunch of “Window.Moved” event during the drag, even while the mouse button is down and the mouse is still moving.
Under 10.12 and earlier, there would be only a single .moved event when the user had paused movement, or had released the mouse button.
In my case this is causing a problem, because I re-calculate some window locations on the .Moved event, and in 10.13 since the user is still moving the mouse, it seems like I’m getting different inconsistent values for some of the window positions.
Sounds like another High Sierra bug. Have you reported it to Apple?
Dont think this is MacOS 10.13 bug.
Did a quick test with Xcode (using NSWindowDelegate) and it only triggers when you release the button.
Got an idea; how about in the mouse event. All you do is make sure that a timer is set to mode 2. Then in the timer check system.mousedown is false and fire your moving code.
Not yet, as I’m not sure if it’s really a bug vs. just “undefined behavior”. I’m pretty sure that the problem this is causing me is due to some sort of math error on my end - my code which adjusts window positions should be robust to this.
Why using a timer? You can also check for MouseDown in the event method. Does it still get fired after moving the window (after MouseUp)?
I haven’t tried it and can’t be sure that it will, hence the timer so that it will work.
I believe it does not get fired again - in my initial tests, if you ignore .Moved events when the mouse is down then you will miss some.
Hence the timer, in the move event you make sure that the timer is running, in the timer you check to see when the user has let go of the mouse and then do your math there.