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.