GUIDarkTheme UDF

[WildByDesign]

GUIDarkTheme 2.6.0

• Improved Toolbar subclassing significantly
  • Implemented rounded toolbar buttons
  • Still no Rebar control subclassing yet (W.I.P.)
• Created SampleControls-Demo2.au3 for demo of dark mode toolbar
  • Combined Statusbar-Demo.au3 into SampleControls-Demo2.au3
• Cleaned up and reorganized Include files - thanks to @argumentum
• Updated and improved the Dark Mode API (GUIDarkAPI.au3)
  • It can probably be used on its own now separately from project

Edited May 21 by WildByDesign

[WildByDesign]

I was expecting the next release to have less changes. But I’ve got a lot of nice things going into the next release to improve lots of things.

I also discovered a fundamental flaw in my methods used for coloring the background and text of some controls. This absolutely must be fixed.

[WildByDesign]

GUIDarkTheme 2.7.0

• Improved the handling of transparent toolbars
  • Added new function _GUIDarkTheme_ToolbarSetTrans to enable/disable transparency
  • Added button to SampleControls-Demo2 for testing _GUIDarkTheme_ToolbarSetTrans
• Added initial dark mode support for Rebar controls
  • Added new internal function __GUIDarkTheme_SetBandColor for Rebar band coloring - thanks to Nine
    • This removes the need to subclass the Rebar control
• Improved handling of WM_CTLCOLOR* messages
• Sorted function lists alphabetically
• Pass GUI handle instead of using Global variable
  • This is important in situations with multiple GUIs
• Added checks to __GUIDarkTheme_WM_SIZE to ensure sizebox exists and confirm GUI
• Miscellaneous bugfixes

While I have added initial dark mode support for Rebar controls, I am not quite ready to add Rebar controls to the SampleControls-Demo2.au3 script. I still have a few more fixes that I need to add for Rebar, but in general it is working quite well.

Rebar dark mode support got some important help from @Nine and @pixelsearch who made it much better.

I'm going to share a test script below if you want to test Rebar in GUIDarkTheme UDF. Please keep in mind that there is a crash regarding the DateProc (DateTimePicker) subclassing when you click on one of the rebar bands that changes the size of the DTP control. I have to address that crash.

Rebar testing script:

Spoiler

expandcollapse popup

#include <GuiComboBox.au3>
#include <GuiEdit.au3>
#include "GUIDarkTheme.au3"

; Initialize System DPI awareness
DllCall("user32.dll", "bool", "SetProcessDpiAwarenessContext", @AutoItX64 ? "int64" : "int", -2)

Example()

Func Example()
    Local $hGui = GUICreate("Rebar Create (v" & @AutoItVersion & ")", 400, 396, -1, -1, $WS_OVERLAPPEDWINDOW)

    ; create the rebar control
    Local $g_hReBar = _GUICtrlRebar_Create($hGui, BitOR($CCS_TOP, $RBS_VARHEIGHT))

    ; create a toolbar to put in the rebar
    Local $hToolbar = _GUICtrlToolbar_Create($hGui, BitOR($TBSTYLE_FLAT, $CCS_NORESIZE, $CCS_NOPARENTALIGN))

    ; Add standard system bitmaps
    _GUICtrlToolbar_AddBitmap($hToolbar, 1, -1, $IDB_STD_LARGE_COLOR)

    ; Add strings
    Local $aStrings[4]
    $aStrings[0] = _GUICtrlToolbar_AddString($hToolbar, "&New")
    $aStrings[1] = _GUICtrlToolbar_AddString($hToolbar, "&Open")
    $aStrings[2] = _GUICtrlToolbar_AddString($hToolbar, "&Save")
    $aStrings[3] = _GUICtrlToolbar_AddString($hToolbar, "&Help")

    ; Add buttons
    Local Enum $e_idNew = 1000, $e_idOpen, $e_idSave, $e_idHelp
    _GUICtrlToolbar_AddButton($hToolbar, $e_idNew, $STD_FILENEW, $aStrings[0])
    _GUICtrlToolbar_AddButton($hToolbar, $e_idOpen, $STD_FILEOPEN, $aStrings[1])
    _GUICtrlToolbar_AddButton($hToolbar, $e_idSave, $STD_FILESAVE, $aStrings[2], $BTNS_CHECK)
    _GUICtrlToolbar_AddButtonSep($hToolbar)
    _GUICtrlToolbar_AddButton($hToolbar, $e_idHelp, $STD_HELP, $aStrings[3])

    ; create a combobox to put in the rebar
    Local $hCombo = _GUICtrlComboBox_Create($hGui, "", 0, 0, 120)

    _GUICtrlComboBox_BeginUpdate($hCombo)
    _GUICtrlComboBox_AddDir($hCombo, @WindowsDir & "\*.exe")
    _GUICtrlComboBox_EndUpdate($hCombo)

    ; create a date time picker to put in the rebar
    Local $hDTP = _GUICtrlDTP_Create($hGui, 0, 0, 190)

    ; create a input box to put in the rebar
    Local $hInput = _GUICtrlEdit_Create($hGui, "Input control", 0, 0, 120, 20, 0)

    ; add band with control
    _GUICtrlRebar_AddBand($g_hReBar, $hCombo, 120, 200, "Dir *.exe")

    ; add band with date time picker
    _GUICtrlRebar_AddBand($g_hReBar, $hDTP, 120)

    ; add band with toolbar to beginning of rebar
    _GUICtrlRebar_AddToolBarBand($g_hReBar, $hToolbar, "", 0)

    ;add another control
    _GUICtrlRebar_AddBand($g_hReBar, $hInput, 120, 200, "Name:")

    _GUIDarkTheme_ApplyDark($hGui)
    GUISetState(@SW_SHOW)

    While 1
        Switch GUIGetMsg()
            Case $GUI_EVENT_CLOSE
                Exit
        EndSwitch
    WEnd
EndFunc   ;==>Example

 

 

[WildByDesign]

I finally mastered subclassing the GUI itself (in my local testing script) with SetWindowSubclass() for busy messages such as WM_SIZE and WM_NOTIFY. I had previously failed at this multiple times before. So I was happy about the success.

But very quickly, I realized that the performance of SetWindowSubclass() is nowhere near the performance of GUIRegisterMsg(). At least when it comes to busy messages such as WM_SIZE and WM_NOTIFY.

But it seems the great @LarsJ had already pointed this out half a decade ago in this post:

Quote

If the same subclassing is performed with GUIRegisterMsg(), GUIRegisterMsg20() and SetWindowSubclass() then the message filtering speed will be this (fastest first): GUIRegisterMsg(), SetWindowSubclass() and GUIRegisterMsg20().

GUIRegisterMsg() is fastest because message filtering is done in internal compiled code.

Clearly, I still need to use SetWindowSubclass() for individual controls. However, for subclassing the GUI itself, I am definitely sticking with GUIRegisterMsg() for obvious performance reasons.

[xuankhanh1982]

@WildByDesign

In version 2.7.0

The color of "GUICtrlCreateInput" is incorrect when disabled.

[WildByDesign]

GUIDarkTheme 2.7.1

• Fixed issue with Input/Edit boxes showing white background when disabled

 

9 hours ago, xuankhanh1982 said:

The color of "GUICtrlCreateInput" is incorrect when disabled.

This should be fixed now in 2.7.1 release. Thanks for reporting.

[jpm]

Hi, I was wondering why 

Quote

    ; remove focus highlight from initial combobox selection
    _WinAPI_SetFocus(GUICtrlGetHandle($idCombo))
    _WinAPI_SetFocus(GUICtrlGetHandle($idTabOne))
 

is needed? The relationship with the tabone is not evident

I suppose that the blue line above the selected Tab is an improvement

[WildByDesign]

30 minutes ago, jpm said:

is needed? The relationship with the tabone is not evident

I suppose that the blue line above the selected Tab is an improvement

No, this is not needed at all and there is no relationship with the tab control.

It was just a trick to remove the initial focus/highlight from the ComboBox that basically simulated selecting the ComboBox and tabbing off of it onto another control to remove the highlight. It didn't matter which control, any would have worked. I just happened to use the tab control for that purpose.

Since I am using $CBS_DROPDOWNLIST style on ComboBox now, there is no focus/highlight on the ComboBox and therefore that silly trick is not needed. I will remove those lines. Thanks for letting me know.

The blue line above selected Tab in not related to the silly trick I was using. But yes, it is an improvement for visibility of selected tab and helpful for accessibility.

[argumentum]

Spoiler

expandcollapse popup

#include <ButtonConstants.au3>
#include <DateTimeConstants.au3>
#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include "GUIDarkTheme.au3"

#Region ### START Koda GUI section ### Form=
$Form1 = GUICreate("Form1", 615, 437, 192, 124, BitOR($GUI_SS_DEFAULT_GUI,$WS_MAXIMIZEBOX,$WS_SIZEBOX,$WS_THICKFRAME,$WS_TABSTOP))

$Checkbox1 = GUICtrlCreateCheckbox("ENABLE", 16, 8, 97, 17)
GUICtrlSetResizing(-1, $GUI_DOCKLEFT+$GUI_DOCKTOP+$GUI_DOCKWIDTH+$GUI_DOCKHEIGHT)

$Checkbox2 = GUICtrlCreateCheckbox("ENABLE", 208, 8, 97, 17)
GUICtrlSetResizing(-1, $GUI_DOCKLEFT+$GUI_DOCKTOP+$GUI_DOCKWIDTH+$GUI_DOCKHEIGHT)

$Date1 = GUICtrlCreateDate("2026/05/27 12:31:14", 16, 40, 186, 21)
GUICtrlSetResizing(-1, $GUI_DOCKLEFT+$GUI_DOCKTOP+$GUI_DOCKWIDTH+$GUI_DOCKHEIGHT)
GUICtrlSetState(-1, $GUI_DISABLE)

$Date2 = GUICtrlCreateDate("2026/05/27 12:31:21", 208, 40, 186, 21)
GUICtrlSetResizing(-1, $GUI_DOCKLEFT+$GUI_DOCKTOP+$GUI_DOCKWIDTH+$GUI_DOCKHEIGHT)
GUICtrlSetState(-1, $GUI_DISABLE)

$Date3 = GUICtrlCreateDate("2026/05/27 12:31:25", 400, 40, 186, 21)
GUICtrlSetResizing(-1, $GUI_DOCKLEFT+$GUI_DOCKTOP+$GUI_DOCKWIDTH+$GUI_DOCKHEIGHT)

_GUIDarkTheme_ApplyDark($Form1)
GUISetState(@SW_SHOW)
#EndRegion ### END Koda GUI section ###

While 1
    $nMsg = GUIGetMsg()
    Switch $nMsg
        Case $GUI_EVENT_CLOSE
            Exit

        Case $Checkbox1
            Switch GUICtrlRead($Checkbox1)
                Case 1
                    GUICtrlSetState($Date1, $GUI_ENABLE )
                Case Else
                    GUICtrlSetState($Date1, $GUI_DISABLE )
        EndSwitch

        Case $Checkbox2
            Switch GUICtrlRead($Checkbox2)
                Case 1
                    GUICtrlSetState($Date2, $GUI_ENABLE )
                Case Else
                    GUICtrlSetState($Date2, $GUI_DISABLE )
        EndSwitch
    EndSwitch
WEnd

The GUICtrlCreateDate() don't behave well in 25H2, and in 24H2 is worse, with the GUICtrlCreateCheckbox() not changing the text color.

( from my project in 24H2 )

Edit: also "!>13:11:54 AutoIt3 ended. rc:-1073740771" on x86 and x64

Edited May 27 by argumentum

[WildByDesign]

18 minutes ago, argumentum said:

The GUICtrlCreateDate() don't behave well in 25H2, and in 24H2 is worse, with the GUICtrlCreateCheckbox() not changing the text color.

Thanks for reporting. The reproducible code is great too, I appreciate it. That saves me time.

I see the problem with the SysDateTimePick32 because I never did end up making it support multiple SysDateTimePick32 controls in the same GUI. So I expected this issue would come up some day. I will look into this and add support for multiple controls.

24 minutes ago, argumentum said:

24H2 is worse, with the GUICtrlCreateCheckbox() not changing the text color.

( from my project in 24H2 )

Now this is interesting. Thanks for the screenshot also because I don't have a 24H2 VM right now. I think I know what the problem is.

My initial guess is that 24H2 and older seem to require the _WinAPI_SetThemeAppProperties that I believe you had initially came up with that idea. For some reason, 25H2 did not require that and was working well with just using SetWindowTheme to remove the theme.

This should be easy to fix but I'll need you to test it later since I don't have 24H2 access at the moment.

[WildByDesign]

2 hours ago, WildByDesign said:

I see the problem with the SysDateTimePick32 because I never did end up making it support multiple SysDateTimePick32 controls in the same GUI.

I’ve successfully got the multiple DTP controls working in the subclass. I just have to keep an array with DTP handles in it. The reason for that is cleanup. The DTP subclass only works with the SetWindowLong subclass method, so for proper cleanup and theme switching, I will have to implement an array for it.

The SetWindowSubclass method is much easier cleanup but it won’t work with the way that the DTP subclass has to work.

I should have a nice release ready tonight or tomorrow morning.

[WildByDesign]

GUIDarkTheme 2.8.0

• Set titlebar color to match GUI background color on Windows 11 builds 22000+
• Brand new tab control subclass procedure that supports more Windows OS builds
• Added support for multiple SysDateTimePick32 controls
• Added some constants and includes to support AutoIt v3.3.16.1
• Switched release archives from 7z to ZIP - suggested by argumentum
• Improved contrast of UpDown button borders
• Improved contrast of Tab controls and the controls within them
• Improved overall GUI and control contrast
• Fixed an issue with the SysMonthCal32 control theming on 24H2 and earlier

Latest download available in the first post of the topic.

This release focuses on the overall dark mode theme cohesiveness, particularly the contrast between GUI background and controls. In previous releases, I had a lot of difficulty in detecting which controls were within a tab control and set different background colors for controls that were in tab controls. It worked fine but it added a lot of complexity. So I spent hours figuring out the right tones of dark colors. Now, with the brand new tab control subclass procedure, it is much more improved and I no longer have to set different background colors for controls that are inside tab controls. I was able to remove the extra complexity from the UDF.

All colors can be customized anyway.

@argumentum Please let me know if I fixed your issues related to the multiple SysDateTimePick32 controls and also the theming of the SysMonthCal32 dropdown. By the way, I had to darken the background of the SysDateTimePick32 control. I had no choice because the pixel hack combined with the InvertRect function that inverts the colors of that control causes unwanted artifacts around the white text if I use any brighter background color. 0x191919 seems to be the max that it can handle.

[argumentum]

 

ok, 1 down, 2 to go.
The date controls as you can see are good but the drop down and the checkbox are not there yet for 24H2 ( but the example I gave you works 🤔 )
In 25H2 it is all working beautifully.

Edit: only the checkbox still needs fixing for 24H2.
I'll have to see what is doing what in my project. 😭

Edited May 28 by argumentum

[WildByDesign]

16 hours ago, argumentum said:

in 24H2 is worse, with the GUICtrlCreateCheckbox() not changing the text color.

7 hours ago, argumentum said:

Edit: only the checkbox still needs fixing for 24H2.

Sorry, I had missed this or just jumped straight into the other issue. You were very clear about GUICtrlCreateCheckbox() and I missed it.

I know exactly what you mean. I remember having to make a few GUIs on older Win11 releases and having the nice new checkbox but the text wasn't white. I remember a few GUI projects where I used a label with white text placed right beside the checkbox and even made the label so it clicked along with the checkbox to simulate it. 🤣

I found a 24H2 ISO in my collection and extracted the aero.msstyles file from it directly and compared it to 25H2 to see why. 25H2 has the DarkMode_Explorer::Button  declaration with TEXTCOLOR 255, 255, 255 while 24H2 does not. So that explains the problem.

I will take a look into this checkbox issue with 24H2 and earlier builds to see how we can handle it. If we remove the theme with SetWindowTheme, we can change the text color but then we get an antique looking checkbox. So I'll look into subclassing methods.

[xuankhanh1982]

@WildByDesign

In version 2.8.0

The color of "GUICtrlCreateInput" is incorrect when disabled.

[WildByDesign]

7 minutes ago, xuankhanh1982 said:

In version 2.8.0

The color of "GUICtrlCreateInput" is incorrect when disabled.

You are right, it looks like I managed to break the input/edit box with disabled state again. Sorry about that. I will fix later today.

[bladem2003]

If you prefix text in a tab with &1 to produce an underlined 1, it is not displayed correctly in the dark theme.

Edit: it works in 2.7.0.0

 

 

#include <GUIConstantsEx.au3>
#include <GuiTab.au3>
#include "GUIDarkTheme.au3"

Example()

Func Example()
    ; Create GUI
    Local $hGUI = GUICreate("Tab Control Insert Item (v" & @AutoItVersion & ")", 450, 300, 100, 100)
    Local $idTab = GUICtrlCreateTab(2, 2, 446, 266)

    _GUIDarkTheme_ApplyDark($hGUI)
    GUISetState(@SW_SHOW)

    ; Add tabs
    _GUICtrlTab_InsertItem($idTab, 0, "&1 Tab 0")
    _GUICtrlTab_InsertItem($idTab, 1, "&2 Tab 1")
    _GUICtrlTab_InsertItem($idTab, 2, "&3 Tab 2")

    While 1
        Sleep(10)
        $msg = GUIGetMsg()
        If $msg = $GUI_EVENT_CLOSE Then Exit
    WEnd
EndFunc   ;==>Example

 

 

Edit2: I think I've found it  In __GUIDarkTheme_TabProc($hWnd, $iMsg, $wParam, $lParam, $iID, $pData)

DllCall("user32.dll", "int", "DrawTextW", "handle", $hMemDC, "wstr", $sText, "int", -1, "struct*", $tTextRect, "uint", BitOR($DT_CENTER, $DT_VCENTER, $DT_SINGLELINE, $DT_NOPREFIX, $DT_NOCLIP))

if you delete $DT_NOPREFIX then it works

 

Edited Thursday at 06:27 PM by bladem2003

[WildByDesign]

4 hours ago, bladem2003 said:

if you delete $DT_NOPREFIX then it works

That is funny because I just discovered this right now. So you beat me to it by 5 minutes.

Thanks, I will have this fixed in the next release.

By the way, why is the accent color painting on the bottom of the tab? Was it like that on 2.7.0 release? Is it related to the ampersand?

Edited Thursday at 06:34 PM by WildByDesign

[bladem2003]

6 minutes ago, WildByDesign said:

By the way, why is the accent color painting on the bottom of the tab? Was it like that on 2.7.0 release? Is it related to the ampersand?

@WildByDesign

This is my change for one of my projects.

[WildByDesign]

GUIDarkTheme 2.8.1

• Fixed regression with disabled edit/input box showing wrong color
• Fixed an issue where tab control was not handling ampersand correctly
• Fixed an issue caused by _WinAPI_SetThemeAppProperties
• Fixed an issue with SysShadow timer if user has "Show shadows under windows" disabled
• Added padding around SysMonthCal32 dropdown window to prevent clipping
• Minor contrast improvements

Latest download available in the first post of the topic.