MaxSize option affects Gui size Topic is solved

[iPhilip]

The script below seems to show that the +MaxSize Gui option reduces the initial size of the Gui. If you run the script below and drag the right Gui edge, a tooltip will show the size of the Gui as it expands. Removing the +MaxSize Gui option, produces the correct initial Gui size.

Code: Select all

Index := 0
; Gui, +Resize +MinSize  ; This results in the correct size.
Gui, +Resize +MinSize +MaxSize300x
Gui, Margin, 0, 0
Gui, Add, Edit, w300
Gui, Show
return

GuiSize:
s .= ++Index " - " A_GuiWidth "`n"
ToolTip % s, 0, 0
return

Esc::
GuiClose:
GuiEscape:
   ExitApp

[iPhilip]

Until the problem is fixed, here's a short-term solution:

Code: Select all

Index := 0
Gui, +Resize +MinSize
Gui, Margin, 0, 0
Gui, Add, Edit, w300
Gui, Show
return

GuiSize:
if (Index = 0)
   Gui, +MaxSize%A_GuiWidth%x
s .= ++Index " - " A_GuiWidth "`n"
ToolTip % s, 0, 0
return

Esc::
GuiClose:
GuiEscape:
   ExitApp

[Helgef]

I don't know anything about guis but you should note that a_guiwidth doesn't account for dpi scaling.

[lexikos]

MinSize and MaxSize do not account for the non-client area until Gui Show is called for the first time, but any explicit limits are still applied if the WM_GETMINMAXINFO message happens to be received. The problem is that MoveWindow is called prior to showing the window, so the window (not client area) width is limited to 300.

If you add +MinSize300x, you may see two GuiSize calls: something like 285 on the first, then immediately 300. This is because the initial MoveWindow is limited to 300 (285 is taking into account the non-client area), but then ShowWindow is called and the new min and max are applied.

It will be fixed.

MinSize/MaxSize and A_GuiWidth both deal with normalized coordinates (relative to 100% DPI), so the example does not need to account for DPI scaling. The result should be 300.

@Helgef
It is unclear what "account for DPI scaling" means. WinGetPos does not account for DPI scaling; it just returns the actual size. A_GuiWidth returns the actual width divided by the DPI scaling factor, so it would probably be more accurate (but still unclear) to say that it does account for DPI scaling. If what you want is the actual size and you are using A_GuiWidth, then you need to account for the fact that it accounts for DPI scaling...

[iPhilip]

MinSize and MaxSize do not account for the non-client area until Gui Show is called for the first time, but any explicit limits are still applied if the WM_GETMINMAXINFO message happens to be received. The problem is that MoveWindow is called prior to showing the window, so the window (not client area) width is limited to 300.

Thank you. That helps explain what I am observing.

If you add +MinSize300x, you may see two GuiSize calls: something like 285 on the first, then immediately 300. This is because the initial MoveWindow is limited to 300 (285 is taking into account the non-client area), but then ShowWindow is called and the new min and max are applied.

I saw that, but only when I don't have another window being created via ToolTip or MsgBox inside the GuiSize subroutine.

It will be fixed.

Thank you.

MinSize/MaxSize and A_GuiWidth both deal with normalized coordinates (relative to 100% DPI), so the example does not need to account for DPI scaling. The result should be 300.

I agree.

[lexikos]

I saw that, but only when I don't have another window being created via ToolTip or MsgBox inside the GuiSize subroutine.

Using these commands causes window messages to be processed. MsgBox in particular will allow the current thread to be interrupted even if it was Critical, and obviously has a bigger effect on timing as well as changing the active window and keyboard focus. For debugging, it is generally better to write to stdout or OutputDebug, to be captured and displayed by an external program.

[Helgef]

It is unclear what "account for DPI scaling" means

I meant that a_guiwidth doesn't reflect changes in size made due to dpiscaling, as is stated in the documentation,

For example, with a DPI of 144 (150%), Gui Show, w100 would make the Gui 150 pixels wide, but A_GuiWidth would still return 100.

Cheers.

[lexikos]

as is stated in the documentation

Is it? The quoted documentation only says that A_GuiWidth will have a particular value in a specific example scenario.

A_GuiWidth is calculated from the width passed by WM_SIZE, with the current setting for DPIScale. It's not that it doesn't reflect changes, but that it makes the opposite change. In fact, it's possible that DPI scaling wasn't even turned on when the GUI was created, but was turned on prior to GuiSize being called. For example,

Code: Select all

Gui -DPIScale
Gui Show, Hide w500
GuiSize:
Gui +DPIScale
MsgBox % A_GuiWidth
ExitApp

This shows 333 for me on my current monitor.

[Helgef]

Clearly my mistake, over interpreting the example. Given what you have shown, I can't see the point of the example.

A_GuiWidth is calculated from the width passed by WM_SIZE, with the current setting for DPIScale

Maybe this should go in the documentation. Edit, I don't know what people use a_guiwidth for, maybe it doesn't matter.

Cheers.

[iPhilip]

...I don't know what people use a_guiwidth for...

Hi @Helgef

Here is an example of how I use A_GuiWidth and A_GuiHeight to resize a control:

Code: Select all

#NoEnv

Text := "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."

Gui +Resize
Gui, Font, s11, Segoe UI
Gui, Add, Edit, w300 h300 vEditCtrl, % Text
Gui, Show
return

GuiSize:
   if GuiWidth {
      EditCtrlW += A_GuiWidth - GuiWidth
      EditCtrlH += A_GuiHeight - GuiHeight
      GuiControl, Move, EditCtrl, W%EditCtrlW% H%EditCtrlH%
   } else
      GuiControlGet, EditCtrl, Pos
   GuiWidth := A_GuiWidth
   GuiHeight := A_GuiHeight
return

GuiClose:
   ExitApp

I hope this helps.

[Helgef]

Thanks @iPhilip

The example only uses the difference from the previous call, so in this case the dpiscaling doesn't matter.

Cheers.

[iPhilip]

The example only uses the difference from the previous call, so in this case the dpiscaling doesn't matter.

@Helgef I don't follow the logic. If dpiscaling proportionally affects A_GuiWidth, then the difference would also be affected by dpiscaling. In actuality, A_GuiWidth is not affected by dpiscaling so it doesn't matter.

[Helgef]

Sorry all for making a mess here, I'll try to improve in the future

Cheers

[iPhilip]

@Helgef, Actually the discussion helped me clarify a few things for myself and find an inconsistency in the documentation.

These values are affected by DPI scaling.

should be

These values are not affected by DPI scaling.

Without your comments, I may not have seen that. Thank you.

[lexikos]

No, those values are most certainly affected by "DPI scaling". If they were not, you would get the actual size, not the fake relative-to-100%-DPI value which happens to match the number you originally used (but might not).

Turn off DPIScale before querying A_GuiWidth, and you will see the difference.

[iPhilip]

No, those values are most certainly affected by "DPI scaling". If they were not, you would get the actual size, not the fake relative-to-100%-DPI value which happens to match the number you originally used (but might not).

Turn off DPIScale before querying A_GuiWidth, and you will see the difference.

Since this is off-topic, I started a separate thread here.

[lexikos]

Fixed by v1.1.34.03.

[iPhilip]

Fixed by v1.1.34.03.

Thank you.