GUIFrame UDF - Melba23 version - 19 May 14

[WildByDesign]

I have run into some issues with what I am attempting to do with the GUIFrame UDF. One of them might be a bug or something that could be improved possibly. By the way, this is not related to the WS_EX_COMPOSITED changes that we were discussing earlier.

The two examples that I am providing are designed to work with the original GUIFrame.au3 UDF (not the beta GUIFrame_WBD_Mod.au3 version).

Diagram of what I am attempting to do:

Spoiler

┌──────────────────────────────────────────────────────┐
│                                                      │
│          (1)                                         │
│                                                      │
┼────────────────┬─────────────────────────────────────┤
│                │                                     │
│                │                                     │
│                │                                     │
│                │                                     │
│                │                                     │
│                │                                     │
│                │                                     │
│      (2)       │                (3)                  │
│                │                                     │
│                │                                     │
│                │                                     │
│                │                                     │
│                │                                     │
│                │                                     │
└────────────────┴─────────────────────────────────────┘

1. Top area (toolbar buttons, etc.)
   • Height must remain specific pixels (eg. 100px) when GUI resizes
   • Width can resize accordingly
2. Left side (treeview)
   • Height and width can resize accordingly
   • Control will dock to all sides and resize
3. Right side (listview)
   • Height and width can resize accordingly
   • Control will dock to all sides and resize

 

 

The first example is where I believe that there might be a bug. This example uses the _GUIFrame_Create feature that allows you to specify the Y coordinates of where the GUI frame (FrameParent) begins. In this example, I am using the variable $iTopSpace = 60

If you resize the width of the GUI only, you notice that the controls (labels) in the two bottom frames stay at the appropriate ratio. Keep in mind, this would also represent the same whether they are treeview controls or whatever. I just used labels to keep the example simple.

Now, if you resize the GUI height, bigger to smaller, smaller to bigger, etc., you will notice that the controls (labels) in the two bottom frames start to have their ratios significantly impaired. It still happens even if I don't use GUICtrlSetResizing to lock down the label size in the top section.

I feel like there must be something within _GUIFrame_SIZE_Handler that does not take into account the value, in this case $iTopSpace = 60, placed for the Y coordinates in the _GUIFrame_Create  function. I believe that it must be getting the height for the main GUI instead of the main GUI height minus the $iTopSpace = 60 (or whatever value the user puts there).

Example 1:

expandcollapse popup

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>

#include "GUIFrame.au3"

; DPI awareness
DllCall("User32.dll", "bool", "SetProcessDpiAwarenessContext" , "HWND", "DPI_AWARENESS_CONTEXT" -2)

Global $iSep_Pos

$hGUI = GUICreate("GUI_Frame Example", 500, 500, -1, -1, BitOR($WS_MINIMIZEBOX, $WS_MAXIMIZEBOX, $WS_SIZEBOX))

GUISetState(@SW_SHOW, $hGUI)

$iTopSpace = 60
$aGUISize = WinGetClientSize($hGUI)
GUICtrlCreateLabel(" ", 0, 0, $aGUISize[0], $iTopSpace)
GUICtrlSetBkColor(-1, 0x808080)
GUICtrlSetResizing(-1, $GUI_DOCKLEFT + $GUI_DOCKRIGHT + $GUI_DOCKHEIGHT)

; Create a 1st level frame
$iFrame_A = _GUIFrame_Create($hGUI, 0, 100, 5, 0, $iTopSpace, 0, 0, 0, 0x02000000)
_GUIFrame_SetMin($iFrame_A, 50, 125, True)  ; This line sets the minima as absolute values <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
;_GUIFrame_SetMin($iFrame_A, 50, 125)       ; This line adjusts the minima to equivalent percentages on resizing <<<<<<<<<<<<<<<<<<<<<

_GUIFrame_Switch($iFrame_A, 1)
$aWinSize = WinGetClientSize(_GUIFrame_GetHandle($iFrame_A, 2))
GUICtrlCreateLabel("", 5, 5, $aWinSize[0] - 10, $aWinSize[1] - 10 - $iTopSpace)
GUICtrlSetResizing(-1, $GUI_DOCKLEFT + $GUI_DOCKRIGHT + $GUI_DOCKTOP + $GUI_DOCKBOTTOM)
GUICtrlSetBkColor(-1, 0x00FF00)

_GUIFrame_Switch($iFrame_A, 2)
$aWinSize = WinGetClientSize(_GUIFrame_GetHandle($iFrame_A, 2))
GUICtrlCreateLabel("", 5, 5, $aWinSize[0] - 10, $aWinSize[1] - 10 - $iTopSpace)
GUICtrlSetResizing(-1, $GUI_DOCKLEFT + $GUI_DOCKRIGHT + $GUI_DOCKTOP + $GUI_DOCKBOTTOM)
GUICtrlSetBkColor(-1, 0xFF0000)
GUICtrlSetState(-1, $GUI_DISABLE)

; Set resizing flag for all created frames
_GUIFrame_ResizeSet(0) ; Adjust the second parameter to change the resizing behaviour <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

; Register the $WM_SIZE handler to permit resizing
_GUIFrame_ResizeReg()

While 1

    Switch GUIGetMsg()
        Case $GUI_EVENT_CLOSE
            ; The UDF does all the tidying up as you exit
            Exit
    EndSwitch

WEnd

 

Now for the second example. I had exhausted all of my attempts to get Example 1 to work properly over the course of a few days. So in Example 2, I am attempting to use the built-in GUIFrame UDF features to make the top section an actual frame.

So with this method, all of the mathematics works out perfectly as far as how the controls and everything measures up when resizing the GUI. This seems very promising.

The problem that I am having is getting that top section (frame) to stay at a locked height. For example, let's say that the top frame is 100 pixels, I don't want it to go any smaller or larger than the 100 pixel height. The width can resize, of course.

Resizing the width of the GUI is perfect and no issues there. The issue is when I resize the height of the GUI again. The control (label) measurements all stay proper ratio which is fantastic. But that top frame likes to grow and shrink.

In this example, I don't think that it is a bug. This is likely just me not knowing how to set it properly. Or possibly might be a good feature request if it's not yet possible.

Example 2:

expandcollapse popup

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>

#include "GUIFrame.au3"

; DPI awareness
DllCall("User32.dll", "bool", "SetProcessDpiAwarenessContext" , "HWND", "DPI_AWARENESS_CONTEXT" -2)

$hGUI = GUICreate("GUI_Frame Example #", 500, 500, -1, -1, BitOR($WS_MINIMIZEBOX, $WS_MAXIMIZEBOX, $WS_SIZEBOX))
GUISetState()

; Create a 1st level frame
$iFrame_A = _GUIFrame_Create($hGUI, 1, 100, 5, 0, 0, 0, 0, 0, 0x02000000)
_GUIFrame_SetMin($iFrame_A, 100, 100)

_GUIFrame_Switch($iFrame_A, 1)

$aWinSize = WinGetClientSize(_GUIFrame_GetHandle($iFrame_A, 1))
GUICtrlCreateLabel("", 5, 5, $aWinSize[0] - 10, $aWinSize[1] - 10)
GUICtrlSetResizing(-1, $GUI_DOCKLEFT + $GUI_DOCKRIGHT + $GUI_DOCKTOP + $GUI_DOCKBOTTOM)
GUICtrlSetBkColor(-1, 0x00FF00)

; Create a 2nd level frame
$iFrame_B = _GUIFrame_Create(_GUIFrame_GetHandle($iFrame_A, 2), 0, 100, 5, 0, 0, 0, 0, 0, 0x02000000)
GUISetBkColor(0xCCFFCC, _GUIFrame_GetHandle($iFrame_B, 1))

_GUIFrame_Switch($iFrame_B, 1)

$aWinSize = WinGetClientSize(_GUIFrame_GetHandle($iFrame_B, 1))
GUICtrlCreateLabel("", 5, 5, $aWinSize[0] - 10, $aWinSize[1] - 10)
GUICtrlSetResizing(-1, $GUI_DOCKLEFT + $GUI_DOCKRIGHT + $GUI_DOCKTOP + $GUI_DOCKBOTTOM)
GUICtrlSetBkColor(-1, 0x0000BB)

_GUIFrame_Switch($iFrame_B, 2)

$aWinSize = WinGetClientSize(_GUIFrame_GetHandle($iFrame_B, 2))
GUICtrlCreateLabel("", 5, 5, $aWinSize[0] - 10, $aWinSize[1] - 10)
GUICtrlSetResizing(-1, $GUI_DOCKLEFT + $GUI_DOCKRIGHT + $GUI_DOCKTOP + $GUI_DOCKBOTTOM)
GUICtrlSetBkColor(-1, 0x0000BB)

; Set resizing flag for all created frames
_GUIFrame_ResizeSet(1, 1)
_GUIFrame_ResizeSet(2, 0)

; Register the WM_SIZE handler
_GUIFrame_ResizeReg()

While 1

    Switch GUIGetMsg()
        Case $GUI_EVENT_CLOSE
            ; The UDF does all the tidying up as you exit
            Exit
    EndSwitch

    ; Get resize flags
    ;$aResize = _GUIFrame_ResizeState()
    ; If a frame has been resized then the [0] element = 1
    ;If $aResize[0] Then _Check_Frames($aResize)

WEnd

 

Thank you.

[Melba23]

WildByDesign,

Does this do what you want? Fixed Top Zone.au3  Basically it creates a single frameset 100 pixels down.

M23

[WildByDesign]

1 hour ago, Melba23 said:

Does this do what you want? Fixed Top Zone.au3  Basically it creates a single frameset 100 pixels down.

I appreciate you taking the time to respond, Melba. Thank you.

This helps a little bit with subtracting the value of the control height with the value of the top section. It gives me a better understanding of that aspect. However, once you add the resizing with:

_GUIFrame_ResizeSet(0)
_GUIFrame_ResizeReg()

The problem is still there with GUI height resizing. Resizing the GUI width is not an issue.

In my example, when resizing the GUI height, it would show the problem at the top and bottom of the controls that are in the two bottom frames.

With your example, there is an improvement, since the issue is now only present at the top of the controls (no longer an issue at the bottom).

The problem is that those label controls go under the top section when resizing the height of the GUI. They can also end up moving further down as well. But if you can imagine with a TreeView and ListView control in those bottom frames (instead of the labels), what happens is that the header for the ListView goes under the top section and some of the TreeView gets cut off as well.

[WildByDesign]

I just did some digging. In the WM_SIZE function in GUIFrame.au3 I see:

Func _GUIFrame_SIZE_Handler($hWnd, $iMsg, $wParam, $lParam)
...
        ; Get new base GUI size
        Local $aSize = WinGetClientSize($hWnd)
...

So it pulls the width/height for the client area of the main GUI to do all of the math. I admit that I am terrible at all of the intricate math stuff involved here. However, it would seem that it may not take into consideration the values from:

$iFrame = _GUIFrame_Create($hGUI, 0, 0, 5, hereX, hereY, 0, 0, 0, 0x02000000)

The X and Y values from where FrameParent is positioned initially within that main GUI. So that could cause this problem vertically as I am experiencing but also horizontally if a user puts a value other than 0 for the X position.

[Melba23]

WildByDesign,

You could well be right - I will look into it.

M23