GUIDarkTheme UDF

[argumentum]

Is it a plane? Is it a bird? No, it's Superman. 
Is it light mode? Is it dark mode? No. It's custom mode.  

[argumentum]

Nitpicking: The UpDown control covers the lower part very well, but the upper part, the mouse does not work on the whole area. 
Reporting from a scale of 175%, argumentum.  

[WildByDesign]

8 minutes ago, argumentum said:

Nitpicking: The UpDown control covers the lower part very well, but the upper part, the mouse does not work on the whole area. 

I noticed this for the upper part as well. I will definitely have to look into it.

I noticed it a few weeks ago. The first thing I tried, for comparison sake, was to disable the UpDown subclassing so that Windows would handle the UpDown as it normally would. I found that by default, even Microsoft has some cursor coverage issue with the top half of the smaller sized vertical UpDown buttons.

But the good thing is that we have control over the math and measurements here. So it is quite possible that we can change the math and measurements slightly and do better than Microsoft with this.

 

Edited Saturday at 02:30 PM by WildByDesign

[WildByDesign]

I have to remember to test a ListView with $LVS_NOCOLUMNHEADER to make sure nothing explodes. I should probably check for it in the header subclassing because I don’t need to do all of the drawing in that case. Even if there is no crash, it can be more efficient to not draw what isn’t needed at the time.

A ListView header window still exists in that case but is simply hidden.

Edited Saturday at 03:20 PM by WildByDesign

[argumentum]

8 minutes ago, WildByDesign said:

I have to remember to test ...

..resize, full screen, etc.
Those are not tested in the example, so it would be good to add just to see 🧐

[WildByDesign]

1 hour ago, argumentum said:

..resize, full screen, etc.
Those are not tested in the example, so it would be good to add just to see 🧐

I agree with you. I do personally test adding resize to the Sample Controls GUI because I needed to do that to resolve previous issues.

Sample Controls GUI is not the most resize-friendly GUI though because of the amount of controls makes it sluggish in general.

Do you think that we should enable resize in that main Sample Controls GUI? Or possibly a menu option to enable/disable resize on-the-fly for testing purposes but not enable by default?

Or another more efficient testing GUI?

[argumentum]

35 minutes ago, WildByDesign said:

Sample Controls GUI is not the most resize-friendly GUI though because of the amount of controls makes it sluggish in general.

Well, if you think that a real graphic interface is always just a few controls, welcome to reality.
Sluggish or not, do as much as you can to showcase everything there is in the UDF. 
The idea is not to hide the flaws, but to present them, so people can see what they can actually get done in contrast to something else. 
Do you remember when 800x600 was a big screen? Those are the times when this "sample controls GUI" was put together. Now we have 4K screens. Big difference. 
So don't be afraid of building your own sample controls GUI, even if it doesn't match the pre-existing one, because it's just a sample. 
If the sample end up being OnEvent, then that's that. After all AutoIt is single-threaded, so we have to make the most of it. 

Most people are on Windows 10 or 11 and have bigger monitors too.
So if you come up with a nice looking "sample GUI", the MVPs may end up using yours in the next release. Who knows !  

Also, if Microsoft Compiler does not support Windows 7 by the time of the next compilation, then the next release of AutoIt is not going to support Windows 7 either.  ...just saying. Code for today's hardware in today's operating systems. 
If the GUI is bigger, then GUI is bigger, and if the UDF cannot support older than ...something, then that's that. 🤷‍♂️

P.S.: ( off-topic )
Handy it's quite handy for those of us that type slow. 😅
So I'm not "posting" right now. I'm "just talking" to you ( and whomever reads it. )  

Edited Saturday at 05:14 PM by argumentum

[xuankhanh1982]

@WildByDesign

In version 2.0.0.0, the labels displayed the colors correctly. After updating to version 2.1.0.0, the label colors are incorrect. Can you fix this error?

 

 

Edited Monday at 01:35 AM by xuankhanh1982

[xuankhanh1982]

@WildByDesign

I'm sorry, my English isn't very good.

Edited Sunday at 08:28 AM by xuankhanh1982

[WildByDesign]

3 hours ago, xuankhanh1982 said:

I'm sorry, my English isn't very good.

That is OK.

The screenshot that you attach and the code helped me understand very good. This is a bug and I will have to find a fix.

For now, you can work around the bug by adding GUICtrlSetColor(-1, 0xFFFFFF) after your labels:

$lb = _HiDpi_GUICtrlCreateLabel("Label1", 50, 150, Default, 15)
GUICtrlSetColor(-1, 0xFFFFFF)

$Label2 = _HiDpi_GUICtrlCreateLabel("Label2", 104, 48, Default, 15)
GUICtrlSetColor(-1, 0xFFFFFF)

This should work for now until I can fix the bug. Thank you for reporting it.

[WildByDesign]

20 hours ago, argumentum said:

Nitpicking: The UpDown control covers the lower part very well, but the upper part, the mouse does not work on the whole area.

So I went into a bit of a deep dive on this one. I was looking into possible causes. For example, was is DPI-related? Was is something to do with how the UDF moves the UpDown control over by 1-2 pixels? Something else?

Well, I was almost out of ideas. It turns out that the bug for that UpDown control issue is not in the UDF. The bug is in the GUI and is passed down from the original SampleControls.au3 file that comes with every AutoIt install. You can test it right now.

The bug was really quite simple. The UpDown label was cutting over the top 10-12 pixels of the UpDown and the Edit control also.

I have a tendency to spend time looking into more difficult possibilities first. I need to save time and consider simple possibilities first. 🤣

How should I go about fixing it?

I could, of course, move the label up 10 pixels. But it looks a little bit off. I tried using WS_CLIPSIBLINGS which has helped me with some things before. But it did not help for this problem.

[WildByDesign]

GUIDarkTheme 2.1.1:

• Improved logic behind Static control text color and backgroud brush swapping
• Removed subclassing for WM_CTLCOLORLISTBOX as it was not required
• Fixed issue with text color swapping for Static controls
• Fixed bug in SampleControls-Demo where UpDown label was clipping top of UpDown control

This is just a bug fix release. But it does have some important logic improvements in the Static control subclassing where it determines which text colors and brushes to swap during theme changes and material changes.

@xuankhanh1982 This should fix your label issue.

 

[argumentum]

1 hour ago, WildByDesign said:

So I went into a bit of a deep dive on this one. I was looking into possible causes. For example,.. 
How should I go about fixing it?

At this point I'm more of a beta tester than a developer 😅
...I wish I had time to play with it, look at the code, and thinker. But all this is a little bit like an exam. You first answer the questions that you know, and when you found a way around it, you answer the ones that you didn't know at the time. 🤷‍♂️

But not because I've been around longer, I know more or better. But as long as the issue is exposed, maybe someone will come around with a solution ?  

15 minutes ago, WildByDesign said:

GUIDarkTheme 2.1.1:

..ok, nice. Thanks  

[WildByDesign]

19 hours ago, argumentum said:

Do you remember when 800x600 was a big screen? Those are the times when this "sample controls GUI" was put together. Now we have 4K screens. Big difference. 

Yes I remember those days. I remember my dad teaching me to build computers from parts when I was very young. Empty case, lots of parts. Good times.

19 hours ago, argumentum said:

So don't be afraid of building your own sample controls GUI, even if it doesn't match the pre-existing one, because it's just a sample. 
If the sample end up being OnEvent, then that's that. After all AutoIt is single-threaded, so we have to make the most of it. 

Most people are on Windows 10 or 11 and have bigger monitors too.
So if you come up with a nice looking "sample GUI", the MVPs may end up using yours in the next release. Who knows !  

I think you have a good point. Converting the original SampleControls GUI is just not ideal and was definitely from past times. Check the screenshot in the win32-darkmodelib project README page. That is a good, modern approach to showing a sample controls GUI since it shows the controls in various states and is resizable.

The thing that I lack right now is time. I think that is the best idea (creating a new sample controls GUI) but I simply just don't have the time, unfortunately. If anybody else wants to attempt to do it, that would be great. But I'm just way too nitpicky when it comes to GUI perfection things and I will drive myself bananas. 🍌

19 hours ago, argumentum said:

Handy it's quite handy for those of us that type slow. 😅
So I'm not "posting" right now. I'm "just talking" to you ( and whomever reads it. )  

The name suits it perfectly. I am definitely testing this out right now. I like it.

Also from their README: 

Quote

Accessibility tooling belongs in everyone's hands, not behind a paywall

I wholeheartedly agree. I respect that greatly. I've seen children's speech devices that are simplistic yet are something like $17,000 and sometimes higher. Or children's speech apps that are like $600 and higher for a licence.

So developers who bring accessibility tools to anyone and everyone, they absolutely have my respect and admiration.

49 minutes ago, argumentum said:

But as long as the issue is exposed, maybe someone will come around with a solution ?  

For now, I have just moved the UpDown label up about 5 pixels if I remember correctly.

Edited Sunday at 01:03 PM by WildByDesign

[xuankhanh1982]

@WildByDesign

In version 2.0.0
The color of "GUICtrlCreateInput" is correct when disabled.

In version 2.1.1
The color of "GUICtrlCreateInput" is incorrect when disabled.

expandcollapse popup

#include <ButtonConstants.au3>
#include <GUIConstantsEx.au3>
#include <TabConstants.au3>
#include <WindowsConstants.au3>
#include <GuiCtrls_HiDpi.au3>
#include <GUIDarkTheme.au3>
a()
Func a()
$Form1 = _HiDpi_GUICreate("Form1", 615, 437, -1, -1, $ws_sysmenu)
$input = _HiDpi_GUICtrlCreateInput(@SystemDir, 65, 5, 340, 20)
GUICtrlSetState(-1, 128)
$disable_input = _HiDpi_GUICtrlCreateButton("Disable Input", 60, 40, 100, 35)
$emable_input = _HiDpi_GUICtrlCreateButton("Emable Input", 180, 40, 100, 35)
$Button1 = _HiDpi_GUICtrlCreateButton("Button1", 168, 264, 89, 49)
$Radio1 = _HiDpi_GUICtrlCreateRadio("Radio1", 360, 112, 121, 41)
$lb = _HiDpi_GUICtrlCreateLabel("Label1", 50, 150, Default, 15)
$Group1 = _HiDpi_GUICtrlCreateGroup("Group1", 350, 40, 113, 49)
_HiDpi_GUICtrlCreateGroup("", -99, -99, 1, 1)
$Tab1 = _HiDpi_GUICtrlCreateTab(352, 240, 153, 80)
$TabSheet1 = GUICtrlCreateTabItem("config")
$Checkbox1 = _HiDpi_GUICtrlCreateCheckbox("Checkbox1", 360, 270, 100, 15)
$TabSheet2 = GUICtrlCreateTabItem("TabSheet1")
GUICtrlCreateTabItem("")
;~ _GUIDarkTheme_ApplyDark($Form1, True)
_GUIDarkTheme_ApplyLight($Form1)
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 $Button1
            b()
    EndSwitch
WEnd
EndFunc

Func b()
$Form2 = _HiDpi_GUICreate("Form2", 389, 188, 192, 124)
$Button2 = _HiDpi_GUICtrlCreateButton("Button2", 152, 120, 73, 33)
$Label2 = _HiDpi_GUICtrlCreateLabel("Label2", 104, 48, Default, 15)
$Checkbox2 = _HiDpi_GUICtrlCreateCheckbox("Checkbox2", 248, 48, 65, 25)
$Radio2 = _HiDpi_GUICtrlCreateRadio("Radio2", 288, 128, 57, 25)
$List2 = _HiDpi_GUICtrlCreateList("6556565", 24, 88, 97, 45)
;~ _GUIDarkTheme_ApplyDark($Form2, True)
_GUIDarkTheme_ApplyLight($Form2)
GUISetState(@SW_SHOW)
While 1
    $nMsg = GUIGetMsg()
    Switch $nMsg
        Case $GUI_EVENT_CLOSE
            Exit
        Case $Button2
            Local $sMsg = "GUIDarkTheme UDF" & @CRLF
            $sMsg &= "Version: " & @TAB & _GUIDarkTheme_Version()
            _GUIDarkTheme_MsgBox(64+262144, "About", $sMsg, 0, $Form2)
    EndSwitch
WEnd
EndFunc

Edited Monday at 01:37 AM by xuankhanh1982

[argumentum]

please use the "code" button and paste your code there @xuankhanh1982

[WildByDesign]

1 hour ago, xuankhanh1982 said:

In version 2.0.0
The color of "GUICtrlCreateInput" is correct when disabled.

In version 2.1.1
The color of "GUICtrlCreateInput" is incorrect when disabled

Thank you for reporting this bug. I can reproduce the problem. I will make a fix today. 

[WildByDesign]

GUIDarkTheme 2.1.2

• Fixed bug affecting disabled Edit controls

 

This bug was the difference between an Or and an And. Oops. 😁☕

 

@xuankhanh1982 This release fixes your issue with Input/Edit control disabled color.

By the way, if you are using the GuiCtrls_HiDpi UDF, you need to initialize the DPI to get sharp controls:

#include "GUIDarkTheme.au3"

_HiDpi_Ctrl_LazyInit() ; this here
a()
Func a()
$Form1 = _HiDpi_GUICreate("Form1", 615, 437, -1, -1, $ws_sysmenu)
$input = _HiDpi_GUICtrlCreateInput(@SystemDir, 65, 5, 340, 20)
GUICtrlSetState(-1, 128)

 

Edited Sunday at 11:30 PM by WildByDesign

[xuankhanh1982]

@WildByDesign

Thanks

[WildByDesign]

GUIDarkTheme 2.1.3

• Applied high DPI scaling to SampleControls-Demo GUI and controls directly
• Removed GuiCtrls_HiDpi UDF to avoid any confusion (not required for GUIDarkTheme UDF)
• For anyone interested in GuiCtrls_HiDpi UDF: "GuiCtrls_HiDpi" (UDF in progress) by @argumentum

I highly recommend the GuiCtrls_HiDpi UDF because it makes scaling controls much easier. I just did not want to give the impression that GuiCtrls_HiDpi.au3 was required to use GUIDarkTheme UDF.