GUIDarkTheme UDF

[argumentum]

2 hours ago, WildByDesign said:

I assume some sort of messaging would need to be presented to the user such as a MsgBox to mention incompatibility. In that case, MsgBox and then disengage the UDF?

Never use a MsgBox in a UDF. A UDF is for the coder, not the end user. If the UDF returns an @error, or something, the one using the UDF will code accordingly.
I, as a coder using this UDF, would have a menu where the modes can be selected, but if not available, I would gray them out because they are just not available

2 hours ago, WildByDesign said:

Speaking of Case 0, what should I do in that case?

...there is a good example. The coder runs _AvailableDarkModes() and the function returns any of 0,1,2 that it can return.
Then the coder has a choice of 0,1,2 when it returns 2, a choice of 0,1 when it returns 1, and no choice when it returns 0.
Then the one coding knows what the OS has as options and code/execute, based on that.

In the case of blindly "apply dark mode", the function will apply the highest available or the one selected. Maybe:

Func myFunc($vDoThis = True)
    Local Static $i_AvailableDarkModes = _AvailableDarkModes()
    Local $iError = 0
    If $vDoThis == True Then $vDoThis = $i_AvailableDarkModes
    If $vDoThis > $i_AvailableDarkModes Then 
        $iError = 1
        $vDoThis = $i_AvailableDarkModes
    EndIf
    Switch Int($vDoThis) ; if False, make it 0
        Case 2
            ; code, code, code..
        Case 1
            ; code, code, code..
        Case 0
            ; code, code, code..
    EndSwitch
    Return SetError($iError, $i_AvailableDarkModes, "something ?")
EndFunc

...the UDF executes the highest available and returns an error if the highest expected is not the highest available. That way, the user that coded their scripts are not left hanging because the exact expected mode is not available when the coder didn't first ask what is available. It also makes it easier when you automatically want to apply the highest available dark mode when wanting dark mode.

The idea is to make the UDF as flexible as possible for the one coding with the UDF.

In regards to true or false, they are basically 0 and 1. So in AutoIt, as a language, it's the same as 0 and 1.
When people are familiar with other coding languages, they might have a preference. Mine is always an integer. Unless I have to flip it, and then it's easier true or false, because you can "not true" or "not false", and that is quite handy. Then again one could:

ConsoleWrite(Int(Not 2) & @CRLF) ; 0
ConsoleWrite(Int(Not 1) & @CRLF) ; 0
ConsoleWrite(Int(Not 0) & @CRLF) ; 1

...so it's a matter of practicality and/or personal preference.

Edit:
In some languages and/or devices true and false can be a bit, while an integer is a byte. 
In AutoIt3, I have no idea what it is, but to me it's all the same  

Edited Monday at 04:44 PM by argumentum

[WildByDesign]

19 hours ago, argumentum said:

n the case of blindly "apply dark mode", the function will apply the highest available or the one selected. Maybe:

Func myFunc($vDoThis = True)
    Local Static $i_AvailableDarkModes = _AvailableDarkModes()
    Local $iError = 0
    If $vDoThis == True Then $vDoThis = $i_AvailableDarkModes
    If $vDoThis > $i_AvailableDarkModes Then 
        $iError = 1
        $vDoThis = $i_AvailableDarkModes
    EndIf
    Switch Int($vDoThis) ; if False, make it 0
        Case 2
            ; code, code, code..
        Case 1
            ; code, code, code..
        Case 0
            ; code, code, code..
    EndSwitch
    Return SetError($iError, $i_AvailableDarkModes, "something ?")
EndFunc

...the UDF executes the highest available and returns an error if the highest expected is not the highest available. That way, the user that coded their scripts are not left hanging because the exact expected mode is not available when the coder didn't first ask what is available. It also makes it easier when you automatically want to apply the highest available dark mode when wanting dark mode.

This has got me thinking. The automatic functions for applying GUIDarkTheme UDF (_GUIDarkTheme_ApplyAuto, _GUIDarkTheme_ApplyDark and _GUIDarkTheme_ApplyLight) are all automated because they use the _GUIDarkTheme_GUICtrlAllSetDarkTheme. Personally, I feel like these should remain simple and apply the best theming choices possible (as supported by OS) for the best possible theme in the end. Generally, they automatically use the DarkMode_DarkTheme if it is available but some controls I still set to DarkMode_Explorer because in some cases it is better. For example, TreeView and ListView new styles in DarkMode_DarkTheme are worse in my opinion. Header is better though and most are better. MS is still tweaking these styles in recent builds because I check the aero.msstyles and uxtheme.dll binaries for certain changes each month.

Anyway... if someone wants to apply a specific theme choice to each control in their GUI on their own without the automated approach, maybe we could adapt _GUIDarkTheme_GUICtrlSetDarkTheme to allow specific choice in theme (DarkMode_DarkTheme or DarkMode_Explorer), depending on availability per OS, of course.

Something that can give more "granular" control over theme choices, basically. For those who want to be specific.

Or, for example, maybe someone wants to use the automated functions but then override the theme on one specific control after the automated function.

What do you think about this?

[argumentum]

2 hours ago, WildByDesign said:

This has got me thinking. ...
...What do you think about this?

Default windows is light mode.
Dark mode is a niche thing. If you're writing code, it's nice to have. If you're writing a letter in Word, let's say, now that's a different story altogether, because if you ever try to write a letter in a dark background, you don't feel the same. It's very awkward.
So yes, you either prefer light mode or dark mode, and if you chose dark mode, then the best available dark mode for that version of Windows is the one that there is.
The Buuf theme that I like so much:

It's a light mode that is not so bright, that in my case hurts. But Windows theming is not there yet, if ever.

2 hours ago, WildByDesign said:

Personally, I feel like these should remain simple and apply the best theming choices possible (as supported by OS) for the best possible theme in the end.

Yes. No question about that.

21 hours ago, argumentum said:

The coder runs _AvailableDarkModes() and the function returns any of 0,1,2 that it can return.

If it returns 0, it's false. If it returns a positive integer, it's true.
The only difference in this "true" return, is that you can see "how true"/"degree of darkness" there is, if the coder facies to know 😅
It might make other functions irrelevant because all the information that you need comes from just one function. 🤔
...but that refactoring is up to you.

2 hours ago, WildByDesign said:

Something that can give more "granular" control over theme choices, basically. For those who want to be specific.

Nah, the user either chooses light more or dark more. That's it.

On 5/11/2026 at 10:10 AM, argumentum said:

 It's just an idea. 🧐

...that's all it was, just an idea, something for you to see if you like or not.

 

[WildByDesign]

GUIDarkTheme 2.4.0

• Added modern tab control using DarkMode_DarkTheme - (Thanks to @UEZ and @Nine)
  • Improved overall efficiency of tab control procedure
  • Fixed some bugs related to tab control
• Determine with certainty if the newer DarkMode_DarkTheme is available
  • Added testing of operating system theme capabilities - (Thanks to @argumentum)
• Improved contrast between GUI background and control background colors
• Updated control border color to improve contrast

 

The overall design has been improved in this release. Subtle changes to improve contrast between GUI background and control background colors made a big difference. Especially if you run 2.3.2 side by side with 2.4.0 to see the nice difference. Lots of improvements to tab controls as well.

[bladem2003]

@WildByDesign

Excellent work.

Can we have the blue selection marker on the modern tabs, like in the old tab?

[WildByDesign]

7 minutes ago, bladem2003 said:

Can we have the blue selection marker on the modern tabs, like in the old tab?

Thanks. Yes, that sounds like a good idea. I’ll try to add that next.

Speaking of that, I was thinking of having it read the Windows AccentColor value and possibly have all areas of blue change when user changes AccentColor.

[bladem2003]

2 hours ago, WildByDesign said:

Speaking of that, I was thinking of having it read the Windows AccentColor value and possibly have all areas of blue change when user changes AccentColor.

 

Yes, that sounds good, but it would also be nice if you could choose your own color.

[xuankhanh1982]

@WildByDesign

expandcollapse popup

#include <ButtonConstants.au3>
#include <ComboConstants.au3>
#include <GUIConstantsEx.au3>
#include <TabConstants.au3>
#include <WindowsConstants.au3>
#include <GUIDarkTheme.au3>
#Region
#AutoIt3Wrapper_Compression=4
#AutoIt3Wrapper_UseX64=y
#AutoIt3Wrapper_AU3Check_Parameters=-q -d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6 -w 7
#AutoIt3Wrapper_Run_Au3Stripper=y
#Au3Stripper_Parameters=/rm /sv /sf
#EndRegion
Global $g_DpiRatio = _ApplyDpiScaling()
a()
Func a()
$Form1 = GUICreate("Form1", 615*$g_DpiRatio, 437*$g_DpiRatio, -1, -1, $ws_sysmenu)
GUISetIcon("shell32.dll", -278)
$input = GUICtrlCreateInput(@SystemDir, 65, 5, 340, 20)
GUICtrlSetState(-1, 128)
$disable_input = GUICtrlCreateButton("Disable Input", 60, 40, 100, 35)
$emable_input = GUICtrlCreateButton("Emable Input", 180, 40, 100, 35)
$Combo1 = GUICtrlCreateCombo("None", 168, 168, 129, 25, BitOR($CBS_DROPDOWN,$CBS_AUTOHSCROLL))
GUICtrlSetData(-1, "Combo1|Combo2|Combo3", "Combo1")
$Button1 = GUICtrlCreateButton("Button1", 168, 264, 89, 49)
$light = GUICtrlCreateRadio("Mode Light", 360, 110, Default, 15)
$dark = GUICtrlCreateRadio("Mode Dark", 360, 135, Default, 15)
$lb = GUICtrlCreateLabel("Label1", 50, 150, Default, 15)
$Group1 = GUICtrlCreateGroup("Group1", 350, 40, 113, 49)
GUICtrlCreateGroup("", -99, -99, 1, 1)
$Tab1 = GUICtrlCreateTab(352*$g_DpiRatio, 240*$g_DpiRatio, 153*$g_DpiRatio, 80*$g_DpiRatio)
$TabSheet1 = GUICtrlCreateTabItem("config")
$Checkbox1 = GUICtrlCreateCheckbox("Checkbox1", 360, 270, 100, 15)
;~ GUICtrlSetBkColor(-1, 0xFF0000)
$TabSheet2 = GUICtrlCreateTabItem("TabSheet1")
GUICtrlCreateTabItem("")
_GUIDarkTheme_ApplyDark($Form1)
;~ _GUIDarkTheme_ApplyLight($Form1)
;~ GUICtrlSetBkColor($Combo1, $__DM_g_iCtrlBkColor)
GUISetState(@SW_SHOW)
While 1
    $nMsg = GUIGetMsg()
    Switch $nMsg
        Case $GUI_EVENT_CLOSE
            Exit
        Case $disable_input
            GUICtrlSetState($input, 128)
        Case $emable_input
            GUICtrlSetState($input, 64)
        Case $light
            _GUIDarkTheme_SwitchTheme($Form1)
        Case $dark
            _GUIDarkTheme_SwitchTheme($Form1)
        Case $Button1
            b()
    EndSwitch
WEnd
EndFunc
Func b()
$Form2 = GUICreate("Form2", 389*$g_DpiRatio, 188*$g_DpiRatio, 192, 124)
GUISetIcon("shell32.dll", -155)
$Button2 = GUICtrlCreateButton("Button2", 152, 120, 73, 33)
$Label2 = GUICtrlCreateLabel("Label2", 104, 48, Default, 15)
$Checkbox2 = GUICtrlCreateCheckbox("Checkbox2", 248, 48, 65, 25)
$Radio2 = GUICtrlCreateRadio("Radio2", 288, 128, 57, 25)
$List2 = GUICtrlCreateList("6556565", 24, 88, 97, 45)
;~ _GUIDarkTheme_ApplyDark($Form2)
;~ _GUIDarkTheme_ApplyLight($Form2)
GUISetState(@SW_SHOW)
While 1
    $nMsg = GUIGetMsg()
    Switch $nMsg
        Case $GUI_EVENT_CLOSE
            ExitLoop
        Case $Button2
            Local $sMsg = "GUIDarkTheme UDF" & @CRLF
            $sMsg &= "Version: " & @TAB & _GUIDarkTheme_Version()
            _GUIDarkTheme_MsgBox(64+262144, "About", $sMsg, 0, $Form2)
    EndSwitch
WEnd
GUIDelete($Form2)
EndFunc
Func _ApplyDpiScaling()
    Local Const $DPI_AWARENESS_CONTEXT_SYSTEM_AWARE = - 2
    __DM_WinAPI_SetProcessDpiAwarenessContext($DPI_AWARENESS_CONTEXT_SYSTEM_AWARE)
    Local $iDPI = Round(__DM_WinAPI_GetDpiFromDpiAwarenessContext($DPI_AWARENESS_CONTEXT_SYSTEM_AWARE)/96, 2)
    If @error Then $iDPI = 1
    Return $iDPI
EndFunc   ;==>_ApplyDpiScaling

After using Au3Stripper with the parameters (/rm /sv /sf) as shown in the image, and then running the file: "test_stripped.au3", GUICtrlCreateTab shows an error as in the image.

https://ibb.co/8Ld74TPd

[mLipok]

3 hours ago, xuankhanh1982 said:

After using Au3Stripper with the parameters (/rm /sv /sf) as shown in the image, and then running the file: "test_stripped.au3", GUICtrlCreateTab shows an error as in the image.

give us your example before stripping

[xuankhanh1982]

@WildByDesign

The original code is in the post above, and this is the file after using Au3Stripper. It has an error as shown in the image.

test_stripped.rar

[mLipok]

4 hours ago, xuankhanh1982 said:

GUICtrlCreateTab shows an error as in the image.

works for me with: GUIDarkTheme-2.4.0.7z

Edited 17 hours ago by mLipok

[WildByDesign]

5 hours ago, xuankhanh1982 said:

After using Au3Stripper with the parameters (/rm /sv /sf) as shown in the image, and then running the file: "test_stripped.au3", GUICtrlCreateTab shows an error as in the image.

I can reproduce the issue with the tab control background not getting filled in.

I will take a look and see how to fix.

[xuankhanh1982]

@mLipok

After using Au3Stripper with the parameters (/rm /sv /sf), and then running the file: "test_stripped.au3", GUICtrlCreateTab shows an error

[WildByDesign]

2 minutes ago, xuankhanh1982 said:

After using Au3Stripper with the parameters (/rm /sv /sf), and then running the file: "test_stripped.au3", GUICtrlCreateTab shows an error

It is interesting. Before Au3Stripper, it works good. After Au3Stripper, it causes problem with filling background of tab control, leaving area white.

I am not very familiar with Au3Stripper.

Does anyone know what I can do to prevent this problem?

[xuankhanh1982]

@WildByDesign

In version "2.3.2.0", after installing Au3Stripper, the program no longer has the 'GUICtrlCreateTab' color error that occurred in version "2.4.0.0".

Possible Parameters: 
/tl : Create Au3Stripper.Log with a trace of all actions.
/debug: add Debug information to Au3Stripper.Log.
/pe : Replace any reference to a Global Const variable with its actual value.
/so : This is the default when no parameters are provided. same as /sf + /sv
/sf : Strip all unused Func's
/sv : Strip unused Global and Local variable declarations.
/mo : Just merges the Include files into the source and strips the Comments.
      This is similar to aut2exe and helps finding the errorline.
/mi : Sets the maximum Iterations Au3Stripper will perform. Default is 5.
/rm : Rename Variables and Functions to a shorter name.
/rsln: Replace @ScriptLineNumber with the actual line number.
/Beta: Use Beta Includes.

I use the parameters: /rm /sv /sf

My goal is to remove unused functions, rename functions to shorter versions, etc., after using Au3Stripper to reduce file size.

Edited 16 hours ago by xuankhanh1982

[mLipok]

to be fine with Au3Stripper

DllCallbackRegister() should not use function names as string 

Local $hMsgProc = DllCallbackRegister("__DM_CBTHookProc", "int", "uint;wparam;lparam")

just use functions:

Local $hMsgProc = DllCallbackRegister(__DM_CBTHookProc, "int", "uint;wparam;lparam")

and here:

Local $sTabProcName = $__DM_g_b24H2Plus ? __GUIDarkTheme_ModernTabProc : __GUIDarkTheme_TabProc
$__DM_g_hTabProc = DllCallbackRegister($sTabProcName, "lresult", "hwnd;uint;wparam;lparam;uint_ptr;dword_ptr")

but this will still fires warnings

so better solutions is to use:

If $__DM_g_b24H2Plus Then
                    $__DM_g_hTabProc = DllCallbackRegister(__GUIDarkTheme_ModernTabProc, "lresult", "hwnd;uint;wparam;lparam;uint_ptr;dword_ptr")
                Else
                    $__DM_g_hTabProc = DllCallbackRegister(__GUIDarkTheme_TabProc, "lresult", "hwnd;uint;wparam;lparam;uint_ptr;dword_ptr")
                EndIf

fixed version in attached zip

 

GUIDarkTheme.zip

Edited 16 hours ago by mLipok

[water]

1 hour ago, xuankhanh1982 said:

After using Au3Stripper with the parameters (/rm /sv /sf), and then running the file: "test_stripped.au3", GUICtrlCreateTab shows an error

Can you please post the console output of Au3Stripper? Most of the time the messages tell you which statements might cause a problem.

[mLipok]

46 minutes ago, water said:

Can you please post the console output of Au3Stripper? Most of the time the messages tell you which statements might cause a problem.

Quote

>Running Au3Stripper (25.205.1420.3)  from:Z:\AutoItPortable\App\SciTE\Au3Stripper cmdline:
-### StripOnly/StripFunc Error: Found DllCallbackRegister() statement using unsolvable Func, which will/could lead to removal of Funcs that are used by this Function.
>### current Func: _1bm     Original_Func_Name:_guidarktheme_guictrlsetdarktheme
z:\!!!_svn_au3\_test_not_related_to_udf\guidarktheme.au3(1934,1): Warning for line:$__DM_g_hTabProc = DllCallbackRegister($sTabProcName, "lresult", "hwnd;uint;wparam;lparam;uint_ptr;dword_ptr") 

It is fixed with my mod to the UDF.

Edited 15 hours ago by mLipok

[water]

22 minutes ago, water said:

Can you please post the console output of Au3Stripper? Most of the time the messages tell you which statements might cause a problem.

My post was meant for user xuankhanh1982 (hence I quoted his post).
Just telling us that "it doesn't work" is not very helpful. He should at least post the information that is at his fingertips  

[xuankhanh1982]

@water

The output file "test_stripped.au3" is attached in the post above.

Edited 15 hours ago by xuankhanh1982