Maximize window anomaly

[jballi]

This is probably not an AutoHotkey bug but I can't be certain. I also am not sure that this is not just me or my PC.

The Problem
The "gui Maximize" command sometimes sizes the window larger that the monitor work area which is the size of the monitor less the taskbar and other registered desktop toolbars. Specifically, the problem occurs when "gui Maximize" command is used on a window where the MaximizeBox button has been disabled.

Example
Here is a script that demonstrates the problem. Instructions are included at the top.

Code: Select all

/*
    Instructions:

    Run 2 tests.

    1st test.   Comment out the "-MaximizeBox" option (may already
    commented out) so that the MaximizeBox button will show.  Run the
    script.  Maximize the window.  Note the value of A_GUIHeight.  You
    should be able to see the text control at the bottom of the
    maximized window.

    2nd test.  Uncomment the "-MaximizeBox" option so that the
    MaximizeBox button is hidden.  Run the script.  Press F11 to
    maximize the window.  Note the value of A_GUIHeight.  If the
    "gui Maximize" command is over-sizing the window, you will not
    be able to see the text control at the bottom of the maximized
    window assuming that your PC is showing a taskbar at the bottom of
    the monitor.
*/

#NoEnv
#SingleInstance Force

Loop 200
    List.=(A_Index>1 ? "`n":"") . A_Index

gui -DPIScale +hWndhWindow +Resize  ;-MaximizeBox
GroupAdd MyWindowGroup,ahk_id %hWindow%
gui Margin,0,0
gui Add,Edit,w350 r10 vMyEdit
gui Add,Text,h20 vMyText,Text control - 20 pixels high
gui Show
GUIControl,,MyEdit,%List%
return

GUISize:
$Maximized:=(A_EventInfo=2) ? True:False
GUIControl Move,MyEdit,% "w" . A_GUIWidth . " h" . A_GUIHeight-20
GUIControl Move,MyText,% "y" . A_GUIHeight-20
outputdebug A_GUIHeight=%A_GUIHeight%
if $Maximized
    {
    gui +OwnDialogs
    MsgBox A_GUIHeight=%A_GUIHeight%
    }

return

GUIClose:
GUIEscape:
ExitApp

#IfWinActive ahk_group MyWindowGroup
F11::
if $Maximized
    gui Restore
 else
    gui Maximize

return
#IfWinActive

Help
First of all, I just want to verify that this problem is occurring outsize of my PC. Secondly, I'm running Windows 7, SP1. I'm curious if this is just a Windows 7 issue or whether it occurs on the more recent versions of Windows.

If you run the test, post if you experienced the problem or not and let me know what version of Windows you have. Thanks.

[wrongsectionalert]

Windiws 8.1/64bit

Using the maximize button: 972px
Using F11: 990px, The text "Text control - 20 pixels high" is hidden under the taskbar, tb is transparent so I can still see it.

[jballi]

Thanks wrongsectionalert. At least I know it's not just me and it's not just Windows 7.

Anyone have any idea why this is happening and/or how to fix it without manually intervening? Thanks.

[JJohnston2]

Does the same on Win7x64.

By the looks of it, the gui maximize statement appears to be sizing the window to the monitor area vs. the monitor working area when there is no maximize button enabled... maybe an internal bug(?).

See SysGet for determining the two different areas (Monitor and MonitorWorkArea).

If you don't care about the actual MinMax state of the window you could resize it yourself using SysGet to determine the MonitorWorkArea.

I currently have a different but somewhat related issue and would like to detect the state of whether a window has a Maximize button or not... haven't figured out yet how to do so.

[jballi]

Does the same on Win7x64.

Thanks. Same OS as me. At least I know it's not just me.

By the looks of it, the gui maximize statement appears to be sizing the window to the monitor area vs. the monitor working area when there is no maximize button enabled... maybe an internal bug(?).

See SysGet for determining the two different areas (Monitor and MonitorWorkArea).

If you don't care about the actual MinMax state of the window you could resize it yourself using SysGet to determine the MonitorWorkArea.

I am with you on what is happening. I'm just not sure why. Is this an OS bug or is this a problem with the "gui Maximize" command? Also, I would only write a work-around if we determined that this OS bug and I really REALLY needed to fix it.

I currently have a different but somewhat related issue and would like to detect the state of whether a window has a Maximize button or not... haven't figured out yet how to do so.

Determining whether or not there is a maximum button is tricky and I haven't found anything to tell me definitively whether there is one or not but there a few things you can do to determine if the Maximize button is active or not.

First of all, you can determine if Resizing and therefore a Maximum button is even possible by checking to see if the WS_SIZEBOX style has been set. Something like this (untested code):

Code: Select all

;-- Determine if window is resizable
WinGet l_Style,Style,ahk_id %hMyWindow%
if (l_Style & WS_SIZEBOX:=0x40000)
    MsgBox Yes`, This window is resizable!

If the window is not resizable, the Maximize button may or may not be showing. If it is showing, it is automatically disabled because resizing is not an option.

If the window is resizable, the Maximize button may or may not be showing. If it is showing, it may have been disabled by the "-MaximizeBox" option.

You can dig through the window's system menu to determine if the "Maximize" menu item is enabled. If it is, then the Maximize button exists and can be used.

I haven't done this exact thing myself before but you would need to use the GetSystemMenu function to get the handle the handle to system menu and then use the GetMenuString function to get the desired menu item and then use the GetMenuState function to determine if the "Maximize" menu item is disabled or not. Like I said, I haven't done this myself but if it sounds like it may what you need, take a look/see. PM me if you want to discuss it further or if you want to work on it. I would be happy to help if I can.

Thanks for your feedback.

[JJohnston2]

One thing you could possibly do to determine if it was an OS issue or not would be to use a PostMessage for the maximize command instead of the ahk native gui maximize command.

Code: Select all

PostMessage, 0x112, 0xF030,,, %WindowTitle%

Could probably just use A instead of the window title variable.

I will definitely look at the WS_SIZEBOX style... that looks very promising.

I also have GetSystemMenu code that I have used up until recently to go through the system menu and get rid of buttons by deleting the menu options... that worked fine and could be adapted as you note in this case, but maybe detecting whether a window is resizable will get me most of the way there. Using GetSystemMenu can get a little more complicated.

[JJohnston2]

Well, I was curious enough to try the PostMessage call... has the same weird behavior, so looks like an OS issue.

[JJohnston2]

...and your check for resizing works beautifully and appears to do exactly what I want it to... thank you.

[jballi]

@JJohnston2 - Thanks for your feedback.

[just me]

I'm sure that this issue occurs on all Windows versions from (at least) Vista to 10 (I'm not sure if occurred on XP, too).

...or how to fix it without manually intervening? Thanks.

It's not feasible without. AHK could set the appropriate values when processing the WM_GETMINMAXINFO message, but it doesn't. So the size seems to depend on the availability of the maximize button, don't know why.

[IRBaboon]

Win7 64bit, two screens, the second one extends the desktop

on screen one with MaximizeBox : 748
on screen two with MaximizeBox : 748

on screen one without MaximizeBox: 718
on screen two without MaximizeBox: 748

[jballi]

Maximize is a special window condition and although I could try to manually emulate the correct window size in this case (no, I haven't tried yet), I'm reluctant to pursue it because of all of the unknown factors. Since this condition should only occur when Resize is enabled and the Maximum button is disabled, it becomes a low risk condition. Well, at least for now. I may look into it in the future. Bother factor: 10. ROI: 2.1%

Thanks everybody for your feedback.

[JJohnston2]

Too bad you can't...

• Check if there is a maximize button
• If no, enable it
• Make the maximize call
• Disable it again

I'm guessing [but not entirely sure] that there are cases where a resizable window is not necessarily tied to the absence of a maximize button, otherwise that could be used for step 1.

Enabling and disabling the maximize button might be possible via the GetSystemMenu calls.


Are you using this function only for autohotkey GUIs, or also for other random windows?

[jballi]

Too bad you can't...

• Check if there is a maximize button
• If no, enable it
• Make the maximize call
• Disable it again

I'm guessing [but not entirely sure] that there are cases where a resizable window is not necessarily tied to the absence of a maximize button, otherwise that could be used for step 1.

Enabling and disabling the maximize button might be possible via the GetSystemMenu calls.

Probably more trouble than it's worth but you've got me curious (dang it to heck!) so I'll probably try it when I get time.

Are you using this function only for autohotkey GUIs, or also for other random windows?

Only for AutoHotkey GUIs at this point.

[JJohnston2]

Never thought I'd figured out a way to write the function I was just asking for...

Code: Select all

F11::
if $Maximized
    gui Restore
else if HasMaximizeButton()
    gui Maximize
else {
    gui +MaximizeBox
    gui Maximize
    gui -MaximizeBox
    }
return

And the magic DLL call...

Code: Select all

HasMaximizeButton() {  ; https://msdn.microsoft.com/en-us/library/windows/desktop/ms633585(v=vs.85).aspx
    return DllCall("GetWindowLongPtr", "ptr", WinExist("A"), "Int", (GWL_STYLE:=-16)) & (WS_MAXIMIZEBOX:=0x10000)
}

This operates on the active window since that's all the example code required... updating the WinExist() call to be an hwnd/ID variable will return the button status for other windows.

And now that I'm ready to post and reviewing the thread, I see that I could have done this with native code very similar to the previous example to check for the resize flag... always doing things the hard way I suppose, maybe I'll touch it up later.

[jballi]

It works!

Like you said, the built-in WinGet command will also work instead of calling the DLL. This is what I came up with:

Code: Select all

F11::
if $Maximized
    gui Restore
else
    {
    WinGet l_Style,Style,ahk_id %hWindow%
    if (l_Style & WS_MAXIMIZEBOX:=0x10000)
        gui Maximize
    else
        {
        gui +MaximizeBox
        gui Maximize
        gui -MaximizeBox
        }
    }

return

This is an excellent solution and I'm going to call it a win but I wanted to point out that it may introduce other problems for some windows. Adding the WS_MAXIMIZEBOX style to the window may automatically set or reset other styles and those styles are not reset back to what they were when the WS_MAXIMIZEBOX style is removed.

The one thing I found when doing some quick testing is that if the "-SysMenu" option is used (removes the system menu, icon, minimize, maximize, and close buttons in the title bar) with the "-MaximizeBox" option, the "-SysMenu" option is negated (everything that was removed is now showing) when the WS_MAXIMIZEBOX style is temporary added but the condition is not restored when the WS_MAXIMIZEBOX style is removed.

There are probably other conditions/situations. If you use this solution (thanks JJohnston2!) be sure to thoroughly test it.


Edit: After some brief testing, I've found that this solution severely messes with the Attach routine that I'm using. Unless I figure out a workaround, I probably won't be using this solution myself.

Edit 2: It has nothing to do with the Attach routine. It's the web browser control. The control goes blank (hidden?) when the "gui +MaximizeBox" or "gui -MaximizebBox" commands are used.

[jballi]

Created a new post to help resolve a new problem found while trying to implement the solution to this post.