This PR introduces an architecture for adding dark mode support to the common dialogs, wxColourDialog, wxFindReplaceDialog, wxFontDialog, wxPageSetupDialog, wxPrintDialog. The initial implementation is for only the two simplest dialogs, wxColourDialog and wxFindReplaceDialog.
A new function wxMSWDarkMode::DialogHookProc() encapsulates the implementation. This function can be called from an existing dialog hook procedure, or can be set as the dialog hook procedure if there is none already. This hook handles dialog messages to enable dark mode on the dialog window and children. For configuring the children, there are two basic methods. If the theme DarkMode_DarkTheme is available, that is used and the appearance is quite good. For older Windows versions, the various classes of controls need special handling. There is currently special handling for Button and Edit controls. More complicated controls such as ComboBox will need to be subclassed and owner-drawn, but that is not implemented yet.
See #26599.
https://github.com/wxWidgets/wxWidgets/pull/26780
(4 files)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@stevecor pushed 1 commit.
—
View it on GitHub or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
The appearance of wxColourDialog:
The appearance of wxFindReplaceDialog with and without DarkMode_DarkTheme below:
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@vadz commented on this pull request.
Thanks, it's rather amazing that the results are so good with only relatively few changes.
Do you understand why wxButton looks fine in dark mode (with the appropriate theme) while the buttons in the dialogs do not? It's also a bit weird to use a different workaround for the buttons here and in src/msw/taskdlg.cpp but I guess we can live with it as long as it's simple enough.
> + }
+ return true;
+}
+
+UINT_PTR CALLBACK DialogHookProc(HWND hwnd, UINT uiMsg, WPARAM wParam,
+ LPARAM WXUNUSED(lParam))
+{
+ if ( !IsActive() )
+ return 0;
+
+ // Window background brush. There is only one handle instance which is
+ // adequate if there is only one common dialog shown at a time. In the
+ // unlikely event more than one is shown at a time, the only problem is
+ // some dark/light drawing inconsistencies, which is an acceptable
+ // trade-off for the simplicity of managing this handle locally.
+ static HBRUSH s_bgBrush = nullptr;
Why not use wxTheBrushList? Chances are this brush is already used elsewhere anyhow in dark mode and like this we don't need to bother with not leaking it.
> + // adequate if there is only one common dialog shown at a time. In the
+ // unlikely event more than one is shown at a time, the only problem is
+ // some dark/light drawing inconsistencies, which is an acceptable
+ // trade-off for the simplicity of managing this handle locally.
+ static HBRUSH s_bgBrush = nullptr;
+
+ switch ( uiMsg )
+ {
+ case WM_INITDIALOG:
+ // Enable dark for dialog window.
+ wxMSWDarkMode::ConfigureTLW(hwnd);
+ s_bgBrush = CreateSolidBrush(
+ wxSystemSettings::GetColour(wxSYS_COLOUR_BTNFACE).GetPixel());
+
+ // Enable dark mode for children.
+ EnumChildWindows(hwnd, EnableDialogChild, 0);
This is very minor but we usually use :: to show that we're calling global Win32 functions, not wx ones, i.e.
- EnumChildWindows(hwnd, EnableDialogChild, 0); + ::EnumChildWindows(hwnd, EnableDialogChild, 0);
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@stevecor pushed 1 commit.
—
View it on GitHub or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
Do you understand why
wxButtonlooks fine in dark mode (with the appropriate theme) while the buttons in the dialogs do not?
I used the wrong background color (wxSYS_COLOUR_BTNFACE instead of wxSYS_COLOUR_WINDOW).
It's also a bit weird to use a different workaround for the buttons here and in
src/msw/taskdlg.cppbut I guess we can live with it as long as it's simple enough.
I cannot understand the code in taskdlg.cpp. I search through it on "button" but I cannot follow how it works.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@stevecor pushed 1 commit.
—
View it on GitHub or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
I cannot understand the code in
taskdlg.cpp. I search through it on "button" but I cannot follow how it works.
AFAIR it just does it pixel-by-pixel in TDPaintPixelSwap(). It's not the most elegant approach, but it works (under Windows 10).
OTOH an even better question might be how does it work there under Windows 11, with its native dark theme: could we perhaps apply DarkMode_DarkTheme::TaskDialog to the other dialogs too?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@PBfordev commented on this pull request.
> + switch ( uiMsg )
+ {
+ case WM_INITDIALOG:
+ // Enable dark for dialog window.
+ wxMSWDarkMode::ConfigureTLW(hwnd);
+ // Enable dark mode for children.
+ ::EnumChildWindows(hwnd, EnableDialogChild, 0);
+ break;
+
+ case WM_CTLCOLORBTN:
+ case WM_CTLCOLORDLG:
+ return (INT_PTR)GetBackgroundBrush();
+
+ case WM_CTLCOLOREDIT:
+ case WM_CTLCOLORSTATIC:
+ SetBkColor((HDC)wParam,
Nitpick as usual
⬇️ Suggested change- SetBkColor((HDC)wParam, + ::SetBkColor((HDC)wParam,
You use the global scope resolution operator for Win32 API everywhere else except here and SetTextColor() and GetBackgroundBrush() below.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@stevecor pushed 2 commits.
—
View it on GitHub or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
Here is how the dialogs look on current Windows 11 (left) and old Windows 10 (right). For older Windows versions, check box tick marks are still light mode. I don't have any good idea how to handle that. In wxFontDialog, the Sample is not a control, and therefore I did not try to fix that. I did not address the wxPrintDialog class. The wxPrinter class already supports dark mode.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@stevecor pushed 1 commit.
—
View it on GitHub or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
Check boxes are implemented for old Windows versions.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@vadz commented on this pull request.
Thanks, this clearly looks very nice (and incomparably better than the current appearance), but it bothers me that we duplicate all this code between the "main" part of the library and dark mode code. Could you please reuse the existing code, possibly after refactoring it? If it's really impossible or too difficult, we can live with having 2 versions of the code but I'd at least like to be sure that you considered doing it. TIA!
> LPARAM lParam)
{
if ( uiMsg == WM_INITDIALOG )
{
CHOOSEFONT *pCH = (CHOOSEFONT *)lParam;
wxFontDialog * const
dialog = reinterpret_cast<wxFontDialog *>(pCH->lCustData);
-
- ::SetWindowText(hwnd, dialog->GetTitle().t_str());
+ auto title = dialog->GetTitle();
+ if ( title.length() != 0 )
Very minor, but
⬇️ Suggested change- if ( title.length() != 0 ) + if ( !title.empty() )
> LPARAM lParam)
{
if ( uiMsg == WM_INITDIALOG )
{
CHOOSEFONT *pCH = (CHOOSEFONT *)lParam;
wxFontDialog * const
dialog = reinterpret_cast<wxFontDialog *>(pCH->lCustData);
-
- ::SetWindowText(hwnd, dialog->GetTitle().t_str());
+ auto title = dialog->GetTitle();
Minor, but could avoid copying the string unnecessarily:
⬇️ Suggested change- auto title = dialog->GetTitle(); + auto const& title = dialog->GetTitle();
> + wchar_t className[16] = { };
+ ::GetClassNameW(hwnd, className, sizeof(className) / sizeof(wchar_t));
Could use wxGetWindowClass() which resizes the buffer if it's not big enough, but I don't know if it could ever be a concern here.
> + // Disable theme rendering and instead rely on the colors set by
+ // handling WM_CTLCOLORSTATIC.
+ auto bs = style & BS_TYPEMASK;
+ if ( bs == BS_AUTOCHECKBOX || bs == BS_AUTORADIOBUTTON ||
+ bs == BS_GROUPBOX || bs == BS_RADIOBUTTON )
+ {
+ ::SetWindowTheme(hwnd, L"", L"");
+ }
+
+ // Custom draw check boxes.
+ if ( bs == BS_AUTOCHECKBOX )
+ ::SetWindowSubclass(hwnd, CommonDialogCheckBoxProc, 1, 0);
+ }
+ else if ( wcscmp(className, L"Edit") == 0 )
+ {
+ // The border looks bad. Change it to a simple border.
I think we should extract it to a function that would be used by wxTextCtrl too because the border used here and for normal text controls should be (and remain in the future) the same.
> @@ -849,6 +849,233 @@ void NotifySysColorChange()
gs_hasChanged = true;
}
+// This subclass procedure draws check box controls.
+static LRESULT CALLBACK CommonDialogCheckBoxProc(HWND hwnd, UINT uMsg,
+ WPARAM wParam, LPARAM lParam, UINT_PTR uIdSubclass,
+ DWORD_PTR WXUNUSED(dwRefData))
+{
+ switch (uMsg)
+ {
+ case WM_PAINT:
It would be really nice to find a way to reuse the code from wxMSWOwnerDrawnButtonBase::MSWDrawButton() here. Having 2 different ways of drawing checkboxes in the same library is one too many.
> + rcBox.right = boxSize;
+ rcBox.bottom = rcBox.top + boxSize;
+ AutoHBRUSH hFgBrush(wxSystemSettings::GetColour(wxSYS_COLOUR_BTNTEXT).GetPixel());
+ ::FrameRect(hdc, &rcBox, hFgBrush);
+
+ // Set the font.
+ HFONT hFont = (HFONT)::SendMessage(hwnd, WM_GETFONT, 0, 0);
+ HFONT hOldFont = (HFONT)::SelectObject(hdc, hFont);
+
+ // Draw check mark, if checked.
+ ::SetBkMode(hdc, TRANSPARENT);
+ ::SetTextColor(hdc, wxSystemSettings::GetColour(wxSYS_COLOUR_BTNTEXT).GetPixel());
+ if ( ::SendMessage(hwnd, BM_GETCHECK, 0, 0) == BST_CHECKED )
+ {
+ // Draw a Unicode check mark character.
+ ::DrawTextW(hdc, L"\x2713", -1, &rcBox, DT_CENTER | DT_VCENTER | DT_SINGLELINE);
In particular, we should either use this in wxRendererNative::DrawCheckBox() or (preferably) reuse that function here.
> + wchar_t text[64]; + ::GetWindowTextW(hwnd, text, sizeof(text) / sizeof(wchar_t));
Could use wxGetWindowText(), even if it seems unlikely that the label is going to be greater than 64 characters in any language — but why risk it.
> + // Clear background.
+ AutoHBRUSH hBgBrush(wxSystemSettings::GetColour(wxSYS_COLOUR_WINDOW).GetPixel());
+ ::FillRect(hdc, &rcClient, hBgBrush);
+
+ // Draw the box.
+ const LONG boxSize = 13;
+ RECT rcBox = { };
+ rcBox.top = (rcClient.bottom - boxSize) / 2;
+ rcBox.right = boxSize;
+ rcBox.bottom = rcBox.top + boxSize;
+ AutoHBRUSH hFgBrush(wxSystemSettings::GetColour(wxSYS_COLOUR_BTNTEXT).GetPixel());
+ ::FrameRect(hdc, &rcBox, hFgBrush);
+
+ // Set the font.
+ HFONT hFont = (HFONT)::SendMessage(hwnd, WM_GETFONT, 0, 0);
+ HFONT hOldFont = (HFONT)::SelectObject(hdc, hFont);
Could/should use SelectInHDC instead of deselecting it manually below.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@stevecor commented on this pull request.
> + // Disable theme rendering and instead rely on the colors set by
+ // handling WM_CTLCOLORSTATIC.
+ auto bs = style & BS_TYPEMASK;
+ if ( bs == BS_AUTOCHECKBOX || bs == BS_AUTORADIOBUTTON ||
+ bs == BS_GROUPBOX || bs == BS_RADIOBUTTON )
+ {
+ ::SetWindowTheme(hwnd, L"", L"");
+ }
+
+ // Custom draw check boxes.
+ if ( bs == BS_AUTOCHECKBOX )
+ ::SetWindowSubclass(hwnd, CommonDialogCheckBoxProc, 1, 0);
+ }
+ else if ( wcscmp(className, L"Edit") == 0 )
+ {
+ // The border looks bad. Change it to a simple border.
I think we should extract it to a function that would be used by
wxTextCtrltoo because the border used here and for normal text controls should be (and remain in the future) the same.
I would like to defer this issue to a future PR. Note that this code is a fallback for old Windows versions. For current and future Windows versions, the EDIT controls in common dialogs are themed and so appear the same as wxTextCtrl.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@stevecor pushed 4 commits.
—
View it on GitHub or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@stevecor pushed 1 commit.
—
View it on GitHub or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@stevecor pushed 1 commit.
—
View it on GitHub or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
I wanted to merge this, but testing this under Windows 10 found a serious bug in the first dialog I tried: "Match case" doesn't appear disabled (as it should be) in the dialog shown by the "dialogs" sample. Also, while less serious, but the size of the checkbox is way too small (and I suspect that if we used wxRendererNative for drawing it, it would look right). Could you please check this and, perhaps, retest other dialogs under Windows 10? TIA!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@stevecor pushed 1 commit.
—
View it on GitHub or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@stevecor pushed 1 commit.
—
View it on GitHub or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
Sorry, the sizes of checkboxes are still very different, compare
and
Why can't we reuse the code from wxRenderer? Have you already tried and it didn't work?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
(Tested in a VirtualBox VM)
I think this is because the checkboxes do not scale with DPI, they seem to look correct at 100% DPI.
If we were to nitpick (still MUCH better than being light IMO), they also do not look native, see the background colour and checkmark character (they also do not hilight blue on mouse over and focus):
The radio buttons scale, but they are jaggy:
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@stevecor pushed 1 commit.
—
View it on GitHub or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
Why can't we reuse the code from
wxRenderer? Have you already tried and it didn't work?
Yes I tried. The main issue is in this context, we have only an HWND. There is no wxWindow.
I committed a fix for high DPI, shown here at 175%:
The check box drawing is only for old Windows versions and is intended to be a simple implementation and good enough. I do not think it is worth the effort to match the native dark mode appearance, shown below.
The radio buttons scale, but they are jaggy:
We only custom draw check boxes. The radio buttons are drawn by the system.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@stevecor pushed 1 commit.
—
View it on GitHub or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
The check box drawing is only for old Windows versions and is intended to be a simple implementation and good enough. I do not think it is worth the effort to match the native dark mode appearance, shown below.
I'm not convinced that factoring out a reusable global function from wxRendererXP::DoDrawXPButton() is such a huge deal, but ok, it does look acceptable now, thanks, and we really should merge this so I'll do it soon.
"Print" dialog is still white, but I didn't look into whether it was possible to customize it in the same way.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
"Print" dialog is still white, but I didn't look into whether it was possible to customize it in the same way.
The wxPrintDialog class already supports dark mode. It looks like below, which can be seen in the printing sample.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
Probably under Windows 11 only, I've tested under Windows 10.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
I cannot understand the code in
taskdlg.cpp. I search through it on "button" but I cannot follow how it works.AFAIR it just does it pixel-by-pixel in
TDPaintPixelSwap(). It's not the most elegant approach, but it works (under Windows 10).OTOH an even better question might be how does it work there under Windows 11, with its native dark theme: could we perhaps apply
DarkMode_DarkTheme::TaskDialogto the other dialogs too?
TDPaintPixelSwap() is only for the internal DirectUI panels of the TaskDialog — TDLG_PRIMARYPANEL, TDLG_SECONDARYPANEL, and the separator lines. These are not real HWNDs; they are drawn by the DirectUI compositor and cannot be retrieved individually via UI Automation. On Windows 10, where no native dark TaskDialog theme exists, the only way to darken them is to capture the buffered paint and swap the pixels. On Windows 11, we simply call SetWindowTheme(hwnd, L"DarkMode_Explorer") and the OS renders them dark natively.
TDPaintPixelSwap() has nothing to do with child controls. The child controls (buttons, radio buttons, etc.) are separate HWNDs hosted inside the dialog, and their background is handled differently.
In a regular wxDialog, a button is a direct child of the dialog HWND. When Windows paints the button, it sends WM_CTLCOLORBTN to the dialog, which returns a dark brush. The button background is filled correctly.
In TaskDialog, the HWND hierarchy is different:
Dialog HWND
└── TaskDialog Page (HWND, class="TaskDialog", FrameworkId="DirectUI", AutomationId ="Window")
└── CtrlNotifySink (HWND, class="CtrlNotifySink", FrameworkId="Win32") immediate parent
└── CCPushButton (HWND, class="CCPushButton", FrameworkId="DirectUI, AutomationId ="CommandButton_*") the button
::GetParent(hBtn) returns the CtrlNotifySink, not the dialog. CtrlNotifySink is a COMCTL32 container window that does not know about dark mode. Its default WM_ERASEBKGND paints the area around the button in the system light color — this is the 1px (or more) gap around the button.
This is exactly what the code at this location does:
// In TDApplyToChildren(), inside the UIA tree walk:
else if ( id.find(L"CommandLink_") == 0 || id.find(L"CommandButton_") == 0 )
{
wxMSWDarkMode::SetTheme(hBtn, L"DarkMode_Explorer"); // Darkens the button itself
TDSubclassContainer(hwndParent, TDDarkCol::kSecondary); // Darkens the CtrlNotifySink container
}
TDSubclassContainer() subclasses this CtrlNotifySink to handle WM_ERASEBKGND and fill the container with kSecondary (#2C2C2C).
Note: The WM_CTLCOLORBTN handler inside TDCtrlContainerSubclassProc is actually a no-op for TaskDialog — CCPushButton does not rely on it. It is only present so that the same subclass procedure can be reused for regular dialogs too, where WM_CTLCOLORBTN is the standard mechanism. For TaskDialog, the darkening of the button itself comes entirely from SetWindowTheme(hBtn, L"DarkMode_Explorer"), and the surrounding gap is fixed by subclassing CtrlNotifySink for WM_ERASEBKGND only.
| Component | Windows 10 | Windows 11 |
|---|---|---|
| Dialog panels (primary, secondary, separators) | TDPaintPixelSwap() |
SetWindowTheme() |
Button container (CtrlNotifySink) |
TDSubclassContainer() for WM_ERASEBKGND only |
TDSubclassContainer() for WM_ERASEBKGND only |
| Button itself | SetWindowTheme(hBtn, L"DarkMode_Explorer") |
SetWindowTheme(hBtn, L"DarkMode_Explorer") |
The pixel swap is only for the non-HWND DirectUI areas of the TaskDialog. The CtrlNotifySink is a real HWND that needs real subclassing to stop it from painting a light background around the button.
could we perhaps apply
DarkMode_DarkTheme::TaskDialogto the other dialogs too?
No — DarkMode_DarkTheme::TaskDialog is not a general-purpose theme. It is a control-specific theme that only applies to the internal TaskDialog DirectUI class.
In the Windows UXTheme system, theme names follow the format: [AppName]::[ClassName] TaskDialog is the internal class name of the native TaskDialog DirectUI control.
DarkMode_DarkTheme::TaskDialog literally means: "the dark variant of the TaskDialog theme".
It only defines visual parts (fill colors, text colors, margins, glyphs) for the TaskDialog-specific parts: TDLG_PRIMARYPANEL, TDLG_SECONDARYPANEL, TDLG_MAININSTRUCTIONPANE, etc.
Other dialogs use completely different class names and the OS does not provide a DarkMode_DarkTheme variant for them.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()