[Solution Revised] Windows 10 clobbers my GUI

[qwert]

This one has caught me completely by surprise ... and it's affecting all my GUIs ... and even (slightly) Microsoft's own programs, like Control Panel.

Synopsis: In Win7, if you drag a window ABOVE the top of the screen, it dutifully repels your placement and aligns the window with the top edge.  In Windows 10, the same repel happens so long as you don't go farther than about 25 or so pixels ... probably the height of a window title bar.  But drag it beyond that, and Windows 10 SHORTENS THE WINDOW by the exceeding amount ... and the shortening is of the entire window, which causes the contained elements to be repositioned in some really odd ways.

I've attached examples of the result for one of my utility windows that can be dragged from any unused area of the background.  The utility's script is on the forum: https://www.autoitscript.com/forum/topic/164345-utility-to-look-up-constants/

Regarding programs like Control Panel, if you drag it as high as you can using the title bar, you'll notice that it's shortened by a couple or three pixels when you release.  At least I hope you'll notice.  Otherwise, I've somehow managed to get a buggy version of the OS.

At minimum, I'd like to hear that someone is able to duplicate my result.

And although I don't hold much hope for an easy fix, anyone's suggestion of what to try will be greatly appreciated.

 

 

 

Edited September 6, 2015 by qwert

[JLogan3o13]

I tested with the Control Panel and (unless I am misunderstanding what you're doing) did not see the same. I used the following:

$aPos = WinGetPos("All Control Panel Items", "")
    MsgBox(0, "", $aPos[2] & ", " & $aPos[3])

And got the same size before and after dragging it to the very top and then releasing.

[qwert]

Maybe these will help.  I didn't confirm whether Windows reports the window as being smaller.  But it is displayed reduced by 2 or 3 pixels.  Or, with my draggable background, by many pixels.

 

 

 

[BrewManNH]

I ran your app and I didn't get the same result. If I drag the control panel to the top of the screen it just maximizes it.

Seeing as how you're experiencing it with Windows native apps as well as AutoIt apps, I can't see that this is something AutoIt related. It could be something as simple as a video driver on your system.

[qwert]

An interesting possibility.  I'd like to think M'soft has these things under control.  But I've seen otherwise.  Under 8.1 I had GUIs lose their composure when a tablet screen was rotated 90 degrees and then rotated back. 

I'll try to locate another Win10 PC and try some things.

Thanks for your response.

[qwert]

I've continued to test this ... with no improvement.  I've confirmed that the video and monitor drivers are "the latest available".

So I worked up a very simple test script, which also fails:

;
;       Win10 GUI Drag Failure Example
;
#include <WindowsConstants.au3>
#include <GUIConstantsEx.au3>

$GUI = GUICreate("Win10 Drag Failure", 250, 160)
$btn = GUICtrlCreateButton('Button', 10, 10, 100, 100)
$close = GUICtrlCreateButton('Close', 20, 120, 80, 24)
GUICtrlCreateLabel("drag", 150, 60, 80, 40)
GUICtrlSetFont(-1, 24, 600)
GUICtrlSetColor(-1, 0xFFFFFF)
GUICtrlSetState(-1, $GUI_DISABLE)
GUISetState(@SW_SHOW)
GUIRegisterMsg($WM_NCHITTEST, "WM_NCHITTEST")

While 1
    $nMsg = GUIGetMsg()
    Switch $nMsg
        Case $GUI_EVENT_CLOSE, $close
            Exit
        Case $btn
            MsgBox(64, '', 'you clicked the button')

    EndSwitch
WEnd

Func WM_NCHITTEST($hWnd, $iMsg, $iwParam, $ilParam)
    If ($hWnd = $GUI) And ($iMsg = $WM_NCHITTEST) Then Return $HTCAPTION
EndFunc

... and have attached captures of the normal and failed cases.

I would like to hear if anyone can observe this same failure.  I'm really at a loss ... and I only have one Win10 PC to test with.

Thanks for any help.

 

 

[BrewManNH]

If you have the hard drive space, you could create a VM on your computer and install Win10 onto it to test.

[orbs]

sorry, but i can not reproduce your issue on a VM - Windows 10 Pro (build 10240) on VirtualBox. the behaviour is as usual - over-the-top placement is repelled.

[qwert]

@orbs: thanks for testing.  It helps confirm one side of the equation, but I'm skeptical that the window processing under VM would be that of the PC's native OS.  Hopefully, I'll hear of results from native Win10 PCs.

 

[draconem]

@qwert I've tested your code under XP, 7 and 10; my 10 showed the drag behaviour you mention here, I can't tell if it is really some Win10 issue, but doing some testings, the "odd" behaviour went away doing the following:

1. Right click on the desktop.
2. Select "Display Settings".
3. Select "Multitasking" from the left panel.
4. Turn [ON] the Snap feature.
5. Minimize or Close the Window and test your "Win10 GUI Drag Failure Example".

The above steps worked for me.

The simplest way to test the "odd" drag behaviour, its to drag the GUI by the "drag" Label to the top most area of the screen, NOT from the TitleBar itself.

[qwert]

That fixed it!

Thank you! ... and welcome to the forums!!!  It appears you've joined just to post this fix and I appreciate that.  I really was at a loss of what to try ... so I have to ask:

How did you know about the Multitasking settings?  I would assume the defaults would have duplicated Win7 behavior.  Obviously, that's not the case.

Now that I know of this, I'll keep a watch for similar failures.  Based on what I've already observed, it looks like M'soft has left a door open for a variety of little problems.  But since the paint isn't really dry on Win10, maybe it will change in an upcoming update. 

 

 

Edited September 5, 2015 by qwert

[orbs]

i confirm the same issue and solution in VM. for me, the Snap feature was already set to ON so i did not observe the issue. when i turned it OFF the issue became apparent. i cannot imagine this not being a bug, and i sure hope they'll fix it soon.

[orbs]

what can i say, Microsoft bugs sure come with a style... this one can not be fixed manually by simply sizing the window back to its preset size. by registering WM_SIZE i can indeed resize the window, but the controls remain misplaced:

expandcollapse popup

;
;       Win10 GUI Drag Failure Example
;
#include <WindowsConstants.au3>
#include <GUIConstantsEx.au3>

; the variables hereunder must be global for WM_SIZE function to work
Global $hGUI = GUICreate("Win10 Drag Failure", 250, 160)
Global $aWinPos = WinGetPos($hGUI)
Global $nGUI_W = $aWinPos[2]
Global $nGUI_H = $aWinPos[3]
; no more mandatoy global variables

$btn = GUICtrlCreateButton('Button', 10, 10, 100, 100)
$close = GUICtrlCreateButton('Close', 20, 120, 80, 24)
GUICtrlCreateLabel("drag", 150, 60, 80, 40)
GUICtrlSetFont(-1, 24, 600)
GUICtrlSetColor(-1, 0xFFFFFF)
GUICtrlSetState(-1, $GUI_DISABLE)
GUISetState(@SW_SHOW)
GUIRegisterMsg($WM_NCHITTEST, "WM_NCHITTEST")
GUIRegisterMsg($WM_SIZE, "WM_SIZE")

While 1
    $nMsg = GUIGetMsg()
    Switch $nMsg
        Case $GUI_EVENT_CLOSE, $close
            Exit
        Case $btn
            MsgBox(64, '', 'you clicked the button')
    EndSwitch
WEnd

Func WM_NCHITTEST($hWnd, $iMsg, $iwParam, $ilParam)
    Return $HTCAPTION
EndFunc   ;==>WM_NCHITTEST

Func WM_SIZE($hWnd, $iMsg, $wParam, $lParam)
    #forceref $hWnd, $iMsg, $wParam, $lParam
    If $hWnd = $hGUI Then
        WinMove($hGUI, '', Default, Default, $nGUI_W, $nGUI_H)
    EndIf
EndFunc   ;==>WM_SIZE

 

the trouble is, i do not think Microsoft think this is a bug at all. i think an MS developer was thinking something along these lines:

"hey, the user is trying to move a window away. let's just keep it around less the screen area the user needs vacant. oh, and let's just give a crap about windows that are not meant to be resized! yeah, that sounds right to me..."

i conclude this because i have observed this bug for $WS_POPUP windows as well, which do not have a border for resizing. and, of course, the fact that Windows 8...10 seem to give a crap about so much other stuff - anything not mobile, in general - so why not this one too.

[orbs]

ok, a seemingly-working solution would be to set the resizing method for each and every control on your GUI, like this:

GUICtrlSetResizing(-1, BitOR($GUI_DOCKTOP, $GUI_DOCKLEFT, $GUI_DOCKSIZE))

 

[orbs]

sorry, i missed the obvious - one can set the default resizing method to all controls, like this:

Opt("GUIResizeMode", BitOR($GUI_DOCKTOP, $GUI_DOCKLEFT, $GUI_DOCKSIZE))

add this line once, instead of applying resizing method to each and every control individually, as suggested in the post above.

[qwert]

@orbs: thanks for taking this to a workable state.  I was concerned about having to instruct users about a setting they would otherwise never touch.

I've tested your method and found only one minor anomaly:

When Snap is Off, Win10 places the GUI such that its title bar is above the edge of the screen (capture is attached), but the overall size is correct and all fields are in their relative positions.  (When Snap is On, the behavior is exactly the same as in Win7, of course.)

I'll begin applying this to all my scripts as a way to inoculate them against the GUI corruption that otherwise takes place.

Considering the bigger picture, I agree that this is a formidable oversight in the current Windows 10 release.  If it's not remedied in short order, then your GUIResizeMode statement and WM_SIZE function will need to become standard issue for all 'parent drag'-style GUIs.

 

[draconem]

Elegant solution, nicely done @qwert!

To fix the "minor anomaly" change this:

WinMove($hGUI, '', Default, Default, $nGUI_W, $nGUI_H)

For this:

WinMove($hGUI, '', Default, 0, $nGUI_W, $nGUI_H)

[qwert]

@draconem: thanks for that refinement.  It takes care of the window title, as well as another small problem I noticed with popup windows (dragging from a point at the very bottom of the GUI still shorted the GUI, but only until the next drag).

Now, everything works in both Snap modes.

 

 

[orbs]

for easy implementation, i packed the solution (including the refinement made by draconem) as a UDF:

also i found that $WS_POPUP style is not working properly, and must be combined with $WS_BORDER or $WS_THICKFRAME to work. i'm ok with that for now.

Edited September 7, 2015 by orbs