GUIDarkTheme UDF

[WildByDesign]

5 hours ago, WildByDesign said:

For some reason I cannot seem to get the handle for the SysShadow class window here. It could be because it’s not created quite yet. Or possibly I might have to try one of the WinAPI window enumeration functions to get the handle.

Two problems here. The first problem is that  SysShadow windows don’t seem to have a parent and therefore run under the Desktop thread from what I can tell. But I found a way to get the handle and the first problem is solved.

The second problem is that they are created just after DTN_DROPDOWN which is why I was having trouble getting the handle. To solve the second problem, I need to create a timer to check every 5ms until the SysShadow handle becomes available after DTN_DROPDOWN is triggered. Then I can move it and kill the timer.

I am not good with timers yet though so I have to figure it out still.

23 minutes ago, bladem2003 said:

I have a new little problem for you. 😉

When you change the tab height, a white box appears above the up/down controls.

Thanks for reporting. I will get this fix in the next release. Thanks for script to reproduce the issue as well. That is helpful.

 

Edited Saturday at 06:50 PM by WildByDesign

[WildByDesign]

GUIDarkTheme 2.4.3

• Fixed issue with positioning of drop shadow (SysShadow class) of SysMonthCal32 control
• Fixed issue with white showing on tab control when larger tab height is used
• Fixed another occurrence where white would show on tab control

We now have a dark mode calendar (SysMonthCal32) that is about as perfect as we can make it. This covers the calendar drop down from a SysDateTimePick32 control. I still haven't colored a standalone SysMonthCal32 yet but I will do that next.

@bladem2003 This release should fix your issue with larger tab height. I tested without GUIDarkTheme UDF just to see how Windows handles the larger tab height and it seems to handle it the same now.

[mLipok]

Please take a look on:

https://www.autoitscript.com/trac/autoit/ticket/4095

as you are creator of ths function I would like to ask you to give your opinion on that sugestion/feature request to the UDF.

Edited Sunday at 10:54 AM by mLipok

[WildByDesign]

2 minutes ago, mLipok said:

as you are creator of ths function I would like to ask you to give your opinion on that sugestion/feature request to the UDF.

I appreciate that and I do strongly believe that the DarkMode API functions should absolutely be added to the standard UDFs.

Please keep in mind that the majority of them are undocumented by Microsoft. Even though the API has been used reliably for many, many years by big projects such as Notepad++ and others. But I don't know what the rules are (or not) when it comes to accepting undocumented API into standard UDF.

Note: The added API would likely be _WinAPI_* and not __DM_WinAPI_* since the "__DM" part is just added to separate the GUIDarkThemeUDF functions in case of clashes with other user created function names.

Also important to clarify, I did not create any of the _WinAPI_* dark mode functions. I'm not very good with DllCall API stuff. I believe they were initially created by @NoNameCode and @argumentum but I don't recall the full history of those functions. I should also mention that @UEZ has created additional dark mode API functions that were not part of the original set. His recent work has the most extensive dark mode API functions available right now in AutoIt. Check his most recent dark mode functions here nicely together in the DarkMode API #Region.

[mLipok]

As long as you remember... please add standard header generated by SciTE (CTRL + ALT + H) to each Func __DM_WinAPI_ and fullfill the 
; Author ........: ????? information

You can keep all others information not changed (as SciTE generate them).

 

Edited Sunday at 11:30 AM by mLipok

[WildByDesign]

3 hours ago, mLipok said:

As long as you remember... please add standard header generated by SciTE (CTRL + ALT + H) to each Func __DM_WinAPI_ and fullfill the 
; Author ........: ????? information

Just to clarify, do you want me to add Author to all 100 or so functions or just the dark mode (UxTheme.dll) specific functions?

I don’t use SciTE so I’m not sure if VSCode/VSCodium has the ability to auto-generate function headers.

I have Authors (credits) at the top of that file in the main/top header for that DarkAPI* add-on UDF. My intention there was just to limit hundreds of extra comment lines in the UDF and reduce overall file size.

[argumentum]

Every day we're changing the UDF because every day we're discovering things. Every day we're having requests. It's too soon right now to think of this as to incorporate it into the standard distribution. Whenever this becomes stable because there is no changes, not because it's better or worse, then we remove the duplicate functions and incorporate it. But I believe that is some time away from now. My two cents. 

[mLipok]

Thanks to you both for answers.
Ok.

6 minutes ago, argumentum said:

then we remove the duplicate functions and incorporate it

do you mean for example:

__DM_WinAPI_GetDeviceCaps() which is currently in UDF as _WinAPI_GetDeviceCaps() and acts exactly the same way ?

or __DM_WinAPI_GetTextExtentPoint32() >> _WinAPI_GetTextExtentPoint32()

 

Edited Sunday at 02:58 PM by mLipok

[argumentum]

Most of them are verbatim the same function, just renamed to not to collide with the standard UDFs. 

[WildByDesign]

36 minutes ago, argumentum said:

Most of them are verbatim the same function, just renamed to not to collide with the standard UDFs. 

This is correct, for sure.

To clarify some more, the only real change for these functions is to keep the loaded DLL handles in memory for performance purposes. That is the main intent. As opposed to have the DLLs open and close over and over again in busy subclass procedures.

Performance improvements are minimal, however, when we are thinking about the sheer amount of subclassing going on in this UDF, every small amount of performance gain adds up. A little bit here, a little bit there. Overall adds up and I have created many functions to perf test all of the functions that I use. Kind of like a dollar store. You get a few things, then a few more. Next thing you know it really adds up at the cash register.

Also with AutoIt being single threaded. We have to do whatever we can to stay as efficient as possible. Efficiency is something that I think about a lot. First, I get things to just work. Then I go over a few iterations of “How can I improve this?”. 

Edited Sunday at 03:36 PM by WildByDesign

[jpm]

Do you know what the cost of the open close dll is 4microseconds in my system

Quote

#include <WinAPISysWin.au3>

Global $__g_hUser32Dll = DllOpen("user32.dll")
Example()

Func Example()
    Local $nLoopMax = 1000
    Local $hTimer = TimerInit()
    For $i = 1 To $nLoopMax
        _WinAPI_GetDesktopWindow()
    Next
    Local $fTimer = TimerDiff($hTimer)
    $hTimer = TimerInit()
    For $i = 1 To $nLoopMax
        _WinAPI_GetDesktopWindow_()
    Next
    Local $fTimer_ = TimerDiff($hTimer)
    LOcal $fDiff = ($fTimer - $fTimer_) / $nLoopMax
    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $fDiff = ' & $fDiff & @CRLF & '>Error code: ' & @error & '    Extended code: ' & @extended & ' (0x' & Hex(@extended) & ')' & @CRLF) ;### Debug Console
EndFunc   ;==>Example

Func _WinAPI_GetDesktopWindow_()
    Local $aCall = DllCall($__g_hUser32Dll, "hwnd", "GetDesktopWindow")
    If @error Then Return SetError(@error, @extended, 0)

    Return $aCall[0]
EndFunc   ;==>_WinAPI_GetDesktopWindow_

so I think the optimisation is not really needed

[WildByDesign]

2 hours ago, jpm said:

so I think the optimisation is not really needed

This is a nice perf test. It was about 3 microseconds here so that is reassuring. Thank you for sharing.

I just did a test here locally by removing all of the custom DLL loaded __DM-related WinAPI functions and used all from standard UDFs unmodified to get a "real-world" feel for it. Everything worked really well. I did not notice any flicker or any issues.

So I think next release will switch back to all standard UDF libraries. This way, it will also benefit from future updates/fixes in those standard UDF libraries.

[argumentum]

2 hours ago, jpm said:

so I think the optimisation is not really needed

#include <WinAPISysWin.au3>

;~ Global $__g_hUser32Dll = "user32.dll"                        ; @@ Debug(20) : $fDiff = 3.6814 - 0.00016
Global $__g_hUser32Dll = DllOpen(@SystemDir & "\user32.dll")    ; @@ Debug(20) : $fDiff = 1.3211 - 0.002404
Example()

Func Example()
    Local $nLoopMax = 1000
    Local $hTimer = TimerInit()
    For $i = 1 To $nLoopMax
        _WinAPI_GetDesktopWindow()
    Next
    Local $fTimer = TimerDiff($hTimer)
    $hTimer = TimerInit()
    For $i = 1 To $nLoopMax
        _WinAPI_GetDesktopWindow_()
    Next
    Local $fTimer_ = TimerDiff($hTimer)
    LOcal $fDiff = Round(($fTimer - $fTimer_) / $nLoopMax, 6)
    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $fDiff = ' & $fTimer_ & ' - ' & $fDiff & @CRLF & '>Error code: ' & @error & '    Extended code: ' & @extended & ' (0x' & Hex(@extended) & ')' & @CRLF) ;### Debug Console
EndFunc   ;==>Example

Func _WinAPI_GetDesktopWindow_()
    Local $aCall = DllCall($__g_hUser32Dll, "hwnd", "GetDesktopWindow")
    If @error Then Return SetError(@error, @extended, 0)

    Return $aCall[0]
EndFunc   ;==>_WinAPI_GetDesktopWindow_

...it is much slower. Not OMG! slower, but it is.

Does it deserve attention ?
That depends on the security point of view ( were a "dll" is in the same folder, the "downloads folder" likely, waiting for a program to load it ) and how slow is the PC.
...so, change every UDF better ( that is a lot of work ), probably not.

Should try it in the demo script and feel the difference.
But if is going with the standard UDFs, what it feels like or not, won't matter.

P.S.: I guess I wrote all this not to sway one way or another but to clarify the trade offs.

[WildByDesign]

38 minutes ago, argumentum said:

That depends on the security point of view ( were a "dll" is in the same folder, the "downloads folder" likely, waiting for a program to load it ) and how slow is the PC.
...so, change every UDF better ( that is a lot of work ), probably not.

Should try it in the demo script and feel the difference.
But if is going with the standard UDFs, what it feels like or not, won't matter.

P.S.: I guess I wrote all this not to sway one way or another but to clarify the trade offs.

This is actually a pretty fascinating perspective. So this, I assume, related to how Windows does is DLLSearchOrder or whatever they call it where it searches local Dir first, then System dir?

Very, very neat. You've got me thinking more now.

Perf, perf, perf!!! 😁

Edited yesterday at 12:38 PM by WildByDesign

[WildByDesign]

This is so weird, the emoji thingies break the forum. It is impossible to press the Enter key after an emoji to make another line. Hmm... even editing the previous post, I cannot press Enter after that last smiling emoji. Anyway... back to more important things. ☕

[xuankhanh1982]

On 5/15/2026 at 11:06 PM, argumentum said:

#include <GUIConstantsEx.au3>
#include <StaticConstants.au3>
#include <WindowsConstants.au3>
#include "GUIDarkTheme.au3"

#Region ### START Koda GUI section ### Form=
$Form1 = GUICreate("Form1", 300, 200, -1, -1)
GUICtrlCreateLabel("", 0, 120, 300, 200 - 120); , $SS_GRAYRECT)
GUICtrlSetBkColor(-1, 0x202020)
GUICtrlSetState(-1, $GUI_DISABLE)
GUICtrlCreateLabel("Hello there !", 40, 40)
$id_Bttn_Ok = GUICtrlCreateButton("&OK", 150, 150, 75, 21)
_GUIDarkTheme_ApplyDark($Form1)
GUISetBkColor(0x363636)
GUISetState(@SW_SHOW)
#EndRegion ### END Koda GUI section ###

While 1
    Switch GUIGetMsg()
        Case $GUI_EVENT_CLOSE, $id_Bttn_Ok
            GUIDelete()
            Exit

    EndSwitch
WEnd

..hope it helps

Thank you, you're amazing!
I tried it and the results were as I expected.

[WildByDesign]

GUIDarkTheme 2.5.0

• Added dark mode support for standalone month calendar (SysMonthCal32 class) control
• Added initial dark mode support for toolbars (ToolbarWindow32 class)
  • No support for Rebar controls yet
• Switched all __DM_WinAPI_ functions back to original _WinAPI_ standard libraries
  • Removed all loaded DLL handles
• Added basic function header with Author to all functions
  • More function header details to add later

[jpm]

Remarks

GUIDarkAPI.au3 require just

Quote

#include "SendMessage.au3"
#include "WinAPISysWin.au3"
#include "WinAPIGdiDC.au3"
 

 

[WildByDesign]

10 minutes ago, jpm said:

GUIDarkAPI.au3 require just

Thank you, I will fix this.

I don't think we need to include SendMessage.au3 though because it is already included by including WinAPISysWin.au3.