UEZ

It started with copy / paste and continued without the need of StringLower because string compare is not case sensitive in Autoit -> can be removed to improve performance. I would say use a hybrid approach using one shared function for controls that behave identically and dedicated functions for complex controls like the ListView, TreeView, etc. Messages like WM_MOUSEMOVE or WM_NCHITTEST fire constantly and it doesn't make sense regarding performance to have huge different Case statements for every pixel the mouse moves, Also drawing complex GDI+ functions in WM_PAINT or WM_ERASEBKGND may reduce the overall performance.

Can you please replace _PaintSizeBox() function with this and test it again? 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

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.

Good catch - let me try to fix it...

As far as I'm concerned, the DarkMode project is complete for now. You're well on your way to building a great UDF! Keep it up. That's right. I usually have to switch back and forth between three languages every day, which isn't easy, but there are some great tools out there that make the work easier when it comes to phrasing things. 😉

Any control that has its own HWND can be subclassed. WM_NOTIFY is always sent upward - from the control to its parent window. When you subclass the trackbar itself, you're watching messages sent to the trackbar - but WM_NOTIFY from the trackbar is sent away from it, never back into it. The trackbar will never see its own WM_NOTIFY. GUIRegisterMsg works because it hooks into the main GUI window's message pump, which is exactly where those notifications land. You need to attach the subclass proc to the parent HWND (your GUI), not the trackbar: ; Subclass the main GUI window to catch child-control notifications Local $hGUI = GUICreate("Test", 400, 300) Local $hSlider = GUICtrlCreateSlider(10, 10, 200, 30) Local $hSliderHWND = GUICtrlGetHandle($hSlider) _WinAPI_SetWindowSubclass(WinGetHandle($hGUI), $g_pSubclassProc, 1, 0) Then inside _SubclassProc, branch on $hFrom to identify which child sent the notification: ... Case $WM_NOTIFY Local $tNMHDR = DllStructCreate($tagNMHDR, $lParam) Local $hFrom = $tNMHDR.hWndFrom Local $iCode = $tNMHDR.Code Switch StringLower(_WinAPI_GetClassName($hFrom)) Case "sysheader32" ; ... existing header handling Case "msctls_trackbar32" Switch $iCode Case $TRBN_THUMBPOSCHANGING ; handle slider EndSwitch EndSwitch ...

It seems to be a problem with GetPrivateProfileStringW which I suppose is internally used. Obviously ANSI and UTF-16 LE with BOM only are supported by this WinAPI call. #include <Array.au3> Local $sPathA, $sPathB, $sPathC, $sPathD, $hFile ; File A - UTF-8-BOM - No Leading LineBreak $sPathA = "C:\Temp\File_UTF-8-BOM_v1.ini" $hFile = FileOpen($sPathA, 2 + 8 + 128) FileWrite($hFile, "[SectionA]" & @CRLF & "Key=Value") FileClose($hFile) ; File B - UTF-8-BOM - Leading LineBreak $sPathB = "C:\Temp\File_UTF-8-BOM_v2.ini" $hFile = FileOpen($sPathB, 2 + 8 + 128) FileWrite($hFile, @CRLF & "[SectionB]" & @CRLF & "Key=Value") FileClose($hFile) ; File C - UTF-8 - No Leading LineBreak $sPathC = "C:\Temp\File_UTF-8_v1.ini" $hFile = FileOpen($sPathC, 2 + 8 + 256) FileWrite($hFile, "[SectionA]" & @CRLF & "Key=Value") FileClose($hFile) ; File D - UTF-8 - Leading LineBreak $sPathD = "C:\Temp\File_UTF-8_v2.ini" $hFile = FileOpen($sPathD, 2 + 8 + 256) FileWrite($hFile, @CRLF & "[SectionB]" & @CRLF & "Key=Value") FileClose($hFile) Local $aSectionA = IniReadSectionNames($sPathA) Local $aSectionB = IniReadSectionNames($sPathB) Local $aSectionC = IniReadSectionNames($sPathC) Local $aSectionD = IniReadSectionNames($sPathD) ConsoleWrite("$aSectionA" & @TAB & UBound($aSectionA) & @CRLF) ConsoleWrite("$aSectionB" & @TAB & UBound($aSectionB) & @CRLF) ConsoleWrite("$aSectionC" & @TAB & UBound($aSectionC) & @CRLF) ConsoleWrite("$aSectionD" & @TAB & UBound($aSectionD) & @CRLF) ConsoleWrite("-------------------------------------------------" & @CRLF) Global $a = _WinAPI_IniReadSection($sPathA) ConsoleWrite("$aSectionA" & @TAB & UBound($a) & @CRLF) Global $b = IniSectionRead($sPathA) ConsoleWrite("$aSectionA" & @TAB & UBound($b) & @CRLF) Exit Func _WinAPI_IniReadSection($sIniFile) If Not FileExists($sIniFile) Then Return SetError(1, 0, 0) Local $iSize = 4096 Local $tBuffer = DllStructCreate("wchar d[" & $iSize & "]") Local $aResult = DllCall("Kernel32.dll", "dword", "GetPrivateProfileStringW", "ptr", Null, "ptr", Null, "wstr", "default", "struct*", $tBuffer, "dword", $iSize, "wstr", $sIniFile) If @error Or Not IsArray($aResult) Then Return SetError(2, 0, 0) If $aResult[0] < 1 Then Return SetError(3, 0, 0) Local $aSections[0] Local $sTemp = "" For $i = 1 To $iSize Local $tChar = DllStructCreate("wchar t", DllStructGetPtr($tBuffer) + ($i - 1) * 2) Local $sChar = $tChar.t If $sChar = Chr(0) Then If $sTemp = "" Then ExitLoop ReDim $aSections[UBound($aSections) + 1] $aSections[UBound($aSections) - 1] = $sTemp $sTemp = "" Else $sTemp &= $sChar EndIf Next Return $aSections EndFunc Func IniSectionRead($sIniFile) Local $hFile = FileOpen($sIniFile, 256) Local $sContent = FileRead($hFile) FileClose($hFile) Local $aLines = StringSplit($sContent, @CRLF, 1) Local $aSections[1] For $i = 1 To $aLines[0] If StringRegExp($aLines[$i], "^\[.+\]$") Then ReDim $aSections[UBound($aSections) + 1] $aSections[UBound($aSections) - 1] = StringMid($aLines[$i], 2, StringLen($aLines[$i]) - 2) EndIf Next $aSections[0] = UBound($aSections) - 1 Return $aSections EndFunc

To handle all headers generically you need something like my _SubclassProc() and NM_CUSTOMDRAW notification to manage ListView headers. Since $hWndFrom contains the actual handle of the sending control, the StringLower(_WinAPI_GetClassName($hWndFrom)) = "sysheader32" check automatically matches all ListView headers regardless of how many ListViews you have. If you need per-ListView differentiation, you can check the header's parent: Case "sysheader32" ; Optionally identify which ListView this header belongs to: Local $hParentListView = _WinAPI_GetParent($hFrom) ; Apply different colors per ListView if needed ; Otherwise the generic class name check handles all of them uniformly I hope it helps you.

You can overpaint the size grips in edit, listvew and treeview. I used in my example $WM_PAINT in _SubclassProc function: ... Case $WM_PAINT Local $sClass = StringLower(_WinAPI_GetClassName($hWnd)) If $sClass = "syslistview32" Or $sClass = "systreeview32" Or $sClass = "edit" Then ; hide Sizegrip boxes Local $iRet = _WinAPI_DefSubclassProc($hWnd, $iMsg, $wParam, $lParam) ; Overpaint sizegrip boxes if visible Local $iWinStyle = _WinAPI_GetWindowLong($hWnd, $GWL_STYLE) If BitAND($iWinStyle, $WS_HSCROLL) And BitAND($iWinStyle, $WS_VSCROLL) Then Local $hDC = _WinAPI_GetWindowDC($hWnd) ; GetWindowDC statt GetDC! Local $tWnd = _WinAPI_GetWindowRect($hWnd) Local $tClient = _WinAPI_GetClientRect($hWnd) Local $iScrollW = _WinAPI_GetSystemMetrics($SM_CXVSCROLL) Local $iScrollH = _WinAPI_GetSystemMetrics($SM_CYHSCROLL) ; convert client-area to Window coordinates Local $tPt = DllStructCreate($tagPOINT) $tPt.X = $tClient.right $tPt.Y = $tClient.bottom DllCall("user32.dll", "bool", "ClientToScreen", "hwnd", $hWnd, "struct*", $tPt) ; direct relativ coordinates Local $tCorner = DllStructCreate($tagRECT), $delta = (_WinAPI_GetWindowLong($hWnd, $GWL_EXSTYLE) And $WS_EX_CLIENTEDGE ? 4 : 1) $tCorner.left = $tClient.right + $delta $tCorner.top = $tClient.bottom + $delta $tCorner.right = $tCorner.left + $iScrollW $tCorner.bottom = $tCorner.top + $iScrollH Local $hBrush = _WinAPI_CreateSolidBrush(_ColorToCOLORREF($COLOR_TITLE_DARK)) _WinAPI_FillRect($hDC, $tCorner, $hBrush) _WinAPI_DeleteObject($hBrush) _WinAPI_ReleaseDC($hWnd, $hDC) EndIf Return $iRet Else Return _WinAPI_DefSubclassProc($hWnd, $iMsg, $wParam, $lParam) EndIf ... I didn't test it for DPI <> 1 aka 96 if $tCorner is properly calculated.

It seems to work also for child windows: ;Coded by UEZ #include <GUIConstantsEx.au3> #include <GDIPlus.au3> #include <WinAPI.au3> #include <WindowsConstants.au3> AutoItSetOption("GuiOnEventMode", 1) Global Const $DWMWA_REDIRECTIONBITMAP_ALPHA = 39 _GDIPlus_Startup() Global $hImage = _GDIPlus_ImageLoadFromFile("c:\Program Files (x86)\AutoIt3\Examples\GUI\Torus.png") Global $iW = _GDIPlus_ImageGetWidth($hImage) Global $iH = _GDIPlus_ImageGetHeight($hImage) Global $hGfx = _GDIPlus_ImageGetGraphicsContext($hImage) _GDIPlus_GraphicsSetSmoothingMode($hGfx, $GDIP_SMOOTHINGMODE_HIGHQUALITY) _GDIPlus_GraphicsSetTextRenderingHint($hGfx, $GDIP_TEXTRENDERINGHINTANTIALIAS) Global $hBrush = _GDIPlus_BrushCreateSolid(0xA0FFFFFF) Global $hFormat = _GDIPlus_StringFormatCreate() Global $hFamily = _GDIPlus_FontFamilyCreate("Arial") Global $hFont = _GDIPlus_FontCreate($hFamily, 30) Global $tLayout = _GDIPlus_RectFCreate(0, $iH - 100, $iW, 32) _GDIPlus_StringFormatSetAlign($hFormat, 1) _GDIPlus_GraphicsDrawStringEx($hGfx, "Hello world", $hFont, $tLayout, $hFormat, $hBrush) _GDIPlus_FontDispose($hFont) _GDIPlus_FontFamilyDispose($hFamily) _GDIPlus_StringFormatDispose($hFormat) _GDIPlus_GraphicsDispose($hGfx) Global $hGUI = GUICreate("Parent", 200, 150, 300, 200) Global $hChild = GUICreate("Child", $iW, $iH, -1, -1, $WS_POPUP, $WS_EX_TOOLWINDOW, $hGUI) Global $aCall = DllCall("dwmapi.dll", "long", "DwmSetWindowAttribute", _ "hwnd", $hChild, _ "dword", $DWMWA_REDIRECTIONBITMAP_ALPHA, _ "bool*", True, _ "dword", 4) GUIRegisterMsg($WM_PAINT, "_WM_PAINT") GUISetState(@SW_SHOW, $hGUI) GUISetState(@SW_SHOW, $hChild) GUISetOnEvent($GUI_EVENT_CLOSE, "_Quit") Do Until Not Sleep(100) Func _WM_PAINT($hWnd, $iMsg, $wParam, $lParam) If $hWnd <> $hChild Then Return $GUI_RUNDEFMSG Local $tPS = DllStructCreate($tagPAINTSTRUCT) Local $hDC = _WinAPI_BeginPaint($hWnd, $tPS) Local $hGfx = _GDIPlus_GraphicsCreateFromHDC($hDC) _GDIPlus_GraphicsSetCompositingMode($hGfx, $GDIP_COMPOSITINGMODESOURCECOPY) _GDIPlus_GraphicsSetSmoothingMode($hGfx, $GDIP_SMOOTHINGMODE_HIGHQUALITY) _GDIPlus_GraphicsDrawImageRect($hGfx, $hImage, 0, 0, $iW, $iH) _GDIPlus_GraphicsDispose($hGfx) _WinAPI_EndPaint($hWnd, $tPS) Return 0 EndFunc Func _Quit() GUIRegisterMsg($WM_PAINT, "") _GDIPlus_BitmapDispose($hImage) _GDIPlus_Shutdown() GUIDelete($hGUI) GUIDelete($hChild) Exit EndFunc

Seem that it can display GUI with 32bit image with transparency without using WS_EX_LAYERED: ;Coded by UEZ #include <GUIConstantsEx.au3> #include <GDIPlus.au3> #include <WinAPI.au3> #include <WindowsConstants.au3> AutoItSetOption("GuiOnEventMode", 1) Global Const $DWMWA_REDIRECTIONBITMAP_ALPHA = 39 _GDIPlus_Startup() Global $hImage = _GDIPlus_ImageLoadFromFile("c:\Program Files (x86)\AutoIt3\Examples\GUI\Torus.png") Global $iW = _GDIPlus_ImageGetWidth($hImage) Global $iH = _GDIPlus_ImageGetHeight($hImage) Global $hGUI = GUICreate(" DWMWA_REDIRECTIONBITMAP_ALPHA Test", $iW, $iH, -1, -1, $WS_POPUP) Global $aCall = DllCall("dwmapi.dll", "long", "DwmSetWindowAttribute", _ "hwnd", $hGUI, _ "dword", $DWMWA_REDIRECTIONBITMAP_ALPHA, _ "bool*", True, _ "dword", 4) GUISetState() GUIRegisterMsg($WM_PAINT, "_WM_PAINT") GUISetOnEvent($GUI_EVENT_CLOSE, "_Quit") _WinAPI_InvalidateRect($hGUI, 0, True) Do Until Not Sleep(100) Func _WM_PAINT($hWnd, $iMsg, $wParam, $lParam) If $hWnd <> $hGUI Then Return $GUI_RUNDEFMSG Local $tPS = DllStructCreate($tagPAINTSTRUCT) Local $hDC = _WinAPI_BeginPaint($hWnd, $tPS) Local $hGfx = _GDIPlus_GraphicsCreateFromHDC($hDC) _GDIPlus_GraphicsSetCompositingMode($hGfx, $GDIP_COMPOSITINGMODESOURCECOPY) _GDIPlus_GraphicsSetSmoothingMode($hGfx, $GDIP_SMOOTHINGMODE_HIGHQUALITY) _GDIPlus_GraphicsDrawImageRect($hGfx, $hImage, 0, 0, $iW, $iH) _GDIPlus_GraphicsDispose($hGfx) _WinAPI_EndPaint($hWnd, $tPS) Return 0 EndFunc Func _Quit() GUIRegisterMsg($WM_PAINT, "") _GDIPlus_BitmapDispose($hImage) _GDIPlus_Shutdown() GUIDelete($hGUI) Exit EndFunc

Looks good now - no x64 crash and DPI seems to work, too.

Can somebody test if this works? SciTeTabHook (I create two small DLLs (x86/x64) to hook SciTE which is apparently not possible using Autoit due to Memory Barrier / Local Address limits) It should work with SciTE x86/x64. It is important to run AutoIt on the same architecture as SciTE! Tray icon can be used to close Autoit script. Thx. @ioa747 sorry for hijacking your thread, but this fits in well here.

I'm using the x64 version of SciTE -> Version 5.5.8 Scintilla:5.5.8 Lexilla:5.4.6 Jan 12 2026 12:26:07 Autoit: 3.3.18.0 Win: 24H2

I'm getting a crash AutoIt3 ended. rc:-1073740940 when starting it as x64 execution. x86 runs properly. I must add a Sleep(10) to the _ManageOverlay() function. I don't know why but the Tab blue rectangle was topmost painted althouth SciTE was in the background. Just wondering why SciTE doesn't have this feature already onboard...