Sign in to follow this  
Followers 0
qwert

[Solution Revised] Windows 10 clobbers my GUI

19 posts in this topic

#1 ·  Posted (edited)

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.

 

Windows_10_Flawed_Sizing.thumb.png.0990a

 

 

Edited by qwert

Share this post


Link to post
Share on other sites



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.


√-1 2^3 ∑ π, and it was delicious!

Share this post


Link to post
Share on other sites

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.

 

 

Drag_Point.thumb.png.384e1e3db553c7fa354

 

Drag_Result.thumb.png.423ae2e1983ade7443

Share this post


Link to post
Share on other sites

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.


If I posted any code, assume that code was written using the latest release version unless stated otherwise. Also, if it doesn't work on XP I can't help with that because I don't have access to XP, and I'm not going to.
Give a programmer the correct code and he can do his work for a day. Teach a programmer to debug and he can do his work for a lifetime - by Chirag Gude
How to ask questions the smart way!

I hereby grant any person the right to use any code I post, that I am the original author of, on the autoitscript.com forums, unless I've specifically stated otherwise in the code or the thread post. If you do use my code all I ask, as a courtesy, is to make note of where you got it from.

Back up and restore Windows user files _Array.au3 - Modified array functions that include support for 2D arrays.  -  ColorChooser - An add-on for SciTE that pops up a color dialog so you can select and paste a color code into a script.  -  Customizable Splashscreen GUI w/Progress Bar - Create a custom "splash screen" GUI with a progress bar and custom label.  -  _FileGetProperty - Retrieve the properties of a file  -  SciTE Toolbar - A toolbar demo for use with the SciTE editor  -  GUIRegisterMsg demo - Demo script to show how to use the Windows messages to interact with controls and your GUI.  -   Latin Square password generator

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Normal.thumb.PNG.7ca087f6676c2598e8ac094

Failure.thumb.PNG.d1c898248b9e96bf1b4a08

 

 

Share this post


Link to post
Share on other sites

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


If I posted any code, assume that code was written using the latest release version unless stated otherwise. Also, if it doesn't work on XP I can't help with that because I don't have access to XP, and I'm not going to.
Give a programmer the correct code and he can do his work for a day. Teach a programmer to debug and he can do his work for a lifetime - by Chirag Gude
How to ask questions the smart way!

I hereby grant any person the right to use any code I post, that I am the original author of, on the autoitscript.com forums, unless I've specifically stated otherwise in the code or the thread post. If you do use my code all I ask, as a courtesy, is to make note of where you got it from.

Back up and restore Windows user files _Array.au3 - Modified array functions that include support for 2D arrays.  -  ColorChooser - An add-on for SciTE that pops up a color dialog so you can select and paste a color code into a script.  -  Customizable Splashscreen GUI w/Progress Bar - Create a custom "splash screen" GUI with a progress bar and custom label.  -  _FileGetProperty - Retrieve the properties of a file  -  SciTE Toolbar - A toolbar demo for use with the SciTE editor  -  GUIRegisterMsg demo - Demo script to show how to use the Windows messages to interact with controls and your GUI.  -   Latin Square password generator

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

#11 ·  Posted (edited)

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 by qwert

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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:

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

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

Odd_Drop_Position.thumb.PNG.ff41d381b636

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites

#19 ·  Posted (edited)

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 by orbs

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0