SampleControls.au3 in Dark Mode

[UEZ]

Please test:

<code removed because test only>

Since I'm at home (vacation) I cannot properly test DPI behaviour, that's why I marked the size box in red to see if the scaling works correctly when the DPI is changed. Can somebody test and report?

Thanks.

Edited April 2 by UEZ

[WildByDesign]

21 minutes ago, UEZ said:

Since I'm at home (vacation) I cannot properly test DPI behaviour, that's why I marked the size box in red to see if the scaling works correctly when the DPI is changed. Can somebody test and report?

It looks like the Edit control is aligned correctly but the ListView control sizebox seems misaligned by 1 pixel. Screenshot in spoiler below.

Spoiler

 

[UEZ]

Can you please replace _PaintSizeBox() function with this and test it again?
 

expandcollapse popup

Func _PaintSizeBox($hWnd, $hDC)
    Local $iWinStyle = _WinAPI_GetWindowLong($hWnd, $GWL_STYLE)
    
    ; Only proceed if both horizontal and vertical scrollbars are active
    If Not (BitAND($iWinStyle, $WS_HSCROLL) And BitAND($iWinStyle, $WS_VSCROLL)) Then Return False

    ; 1. Retrieve exact Window and Client dimensions
    Local $tRW = _WinAPI_GetWindowRect($hWnd)
    Local $tRC = _WinAPI_GetClientRect($hWnd)
    
    ; 2. Map Client coordinates to Window-DC space
    Local $tPoint = DllStructCreate($tagPOINT)
    $tPoint.X = 0
    $tPoint.Y = 0
    _WinAPI_ClientToScreen($hWnd, $tPoint)

    ; Calculate border offsets
    Local $iOffL = $tPoint.X - $tRW.Left
    Local $iOffT = $tPoint.Y - $tRW.Top
    
    ; Calculate total window dimensions
    Local $iWinW = $tRW.Right - $tRW.Left
    Local $iWinH = $tRW.Bottom - $tRW.Top

    ; 3. Define the SizeBox Rect
    Local $tCorner = DllStructCreate($tagRECT)
    
    ; LEFT/TOP: Start exactly where the client area ends (scrollbar junction)
    $tCorner.Left   = $iOffL + $tRC.Right
    $tCorner.Top    = $iOffT + $tRC.Bottom
    
    ; RIGHT/BOTTOM: Align with the inner edge of the window border.
    $tCorner.Right  = $iWinW - $iOffL
    $tCorner.Bottom = $iWinH - $iOffT
    
    ; Adjust for ListView the size of the box
    If _WinAPI_GetClassName($hWnd) = "SysListView32" Then
        $tCorner.Right  += 1
        $tCorner.Bottom += 1
    EndIf

    ; 4. Paint the box using the dark theme color
    Local $hBrush = _WinAPI_CreateSolidBrush(_ColorToCOLORREF(0xF00000)) ;;$COLOR_TITLE_DARK
    _WinAPI_FillRect($hDC, $tCorner, $hBrush)
    _WinAPI_DeleteObject($hBrush)

    Return True
EndFunc   ;==>_PaintSizeBox

 

[WildByDesign]

20 minutes ago, UEZ said:

Can you please replace _PaintSizeBox() function with this and test it again?

Everything is sized and aligned perfectly. I tested on 100%, 125%, 150% and 175% and it was correct on all of the scaling settings that I was able to test.

The issue with the Edit box losing the overpaint when the cursor goes over is fixed as well. The whole thing with regard to sizebox overpainting is excellent now.

[WildByDesign]

There is an interesting bug only in the DPI aware version of the script where some of the controls disappear for approx. 1 second and reappear. It took me a while to figure out exactly where it was happening. It has to do with the non-client painting of the border of the controls.

Repro:

• Click anywhere in the ListView control so that it has focus
• Click on the taskbar (or any other program)
• Click on the titlebar (specifically titlebar) for Sample GUI with Dark Mode
• ListView control should disappear for 1 second and reappear

It happens with most of the controls. But most notably controls that have scrollbars (whether enabled or not). So this would be a problem when switching back and forth between programs. It happens with the controls that do not have scrollbars as well but it is just not as noticeable.

I do not think that it has anything to do with painting of the sizebox. I tested by removing all border painting code and keeping the sizebox painting functional, and the issue was gone. So painting sizebox is not the problem. It seems to be just the border painting.

The interesting thing is that if you click anywhere in the background of the app and not the titlebar, the issue does not happen. I don't know why it is only the titlebar that causes the issue.

I have narrowed down the code that is causing the issue:

Case $WM_SETFOCUS, $WM_KILLFOCUS
    Local $sClass = _WinAPI_GetClassName($hWnd)
    If _IsBorderedControl($sClass) Then
        ; Trigger WM_NCPAINT to redraw border with updated focus color
        _WinAPI_SetWindowPos($hWnd, 0, 0, 0, 0, 0, BitOR($SWP_NOMOVE, $SWP_NOSIZE, $SWP_NOZORDER, $SWP_FRAMECHANGED))
    EndIf

If you comment out that code temporarily, you will see that the issue can no longer be reproduced. Commenting out that code fixes the problem.

However, then we lose the ability to recolour the border for ListView and TreeView controls because it seems they rely on that to trigger recolouring when focus changes.

Do you know if adding double buffering with _WinAPI_BitBlt to the $WM_NCPAINT of that function could solve this problem?

[UEZ]

Can you try instead?

If _IsBorderedControl($sClass) Then
                ; Trigger WM_NCPAINT to redraw border with updated focus color
                ;_WinAPI_SetWindowPos($hWnd, 0, 0, 0, 0, 0, BitOR($SWP_NOMOVE, $SWP_NOSIZE, $SWP_NOZORDER, $SWP_FRAMECHANGED))
                _WinAPI_RedrawWindow($hWnd, 0, 0, BitOR($RDW_FRAME, $RDW_INVALIDATE, $RDW_NOERASE))
            EndIf

 

[WildByDesign]

24 minutes ago, UEZ said:

Can you try instead?

This solves the problem 100% and everything works as expected. Thank you.