Incorrect colors of wxCheckBox, wxRadioButton after pressing "ALT" key, when WX_MSW_DARK_MODE is active
Steps to reproduce:
Screenshot attached
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
This one is weird. I can reproduce it in the widgets sample but I couldn't reproduce it in a simple example so far and even in the widgets sample it doesn't always happen (and I can't manage to figure out when it does and when it doesn't) and stops happening once you switch to another page and then back to the same page with check/radio buttons twice.
No idea what's going on here, to be honest :-(
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
This probably has something to do with "UI state", i.e. WM_CHANGEUISTATE and related messages, because the problem can't be reproduced if another key is pressed before "Alt", e.g. I couldn't consistently reproduce it before because I used the arrow keys to change the selection in the tree -- you have to do it using the mouse to see the bug.
But I still have no idea how to actually fix it. Also, for once it's not wxStaticBox-related as moving the check/radio boxes out of the box doesn't help.
@marekr As you've reported other dark mode bugs, I wonder if KiCad is affected by this? If it is, I'll try to spend more time on this.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@marekr As you've reported other dark mode bugs, I wonder if KiCad is affected by this? If it is, I'll try to spend more time on this.
I see no difference when pressing ALT
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Thanks for testing! As I wrote, it's a bit tricky because if you had pressed any key in this window (or maybe even in the application?) before pressing Alt, the problem doesn't happen, so you have to do everything using the mouse before pressing it.
But if it doesn't affect KiCad, all the better.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
A smaller reproducing sample (on current master) is the following (obtained by starting with the layout sample program, adding some check boxes, and then throwing out as much code as possible while still preserving the bug):
#include "wx/wx.h" class MyApp : public wxApp { public: MyApp() {} bool OnInit() override; }; class MyFrame : public wxFrame { wxDialog d; public: MyFrame(); }; class MyFrame2 : public wxFrame { public: MyFrame2(); }; wxIMPLEMENT_APP(MyApp); bool MyApp::OnInit() { if ( !wxApp::OnInit() ) return false; SetAppearance(Appearance::Dark); MyFrame *frame = new MyFrame; frame->Show(true); MyFrame2* frame2 = new MyFrame2; frame2->Show(true); return true; } MyFrame::MyFrame() : wxFrame(nullptr, wxID_ANY, "wxWidgets Layout Demo") , d(this, wxID_ANY, "A dialog", wxDefaultPosition, wxSize(200, 200)) { wxPanel* p = new wxPanel(this, wxID_ANY); new wxCheckBox(p, wxID_ANY, "A checkbox in a panel"); new wxCheckBox(&d, wxID_ANY, "A checkbox in a dialog"); d.Show(); } MyFrame2::MyFrame2() : wxFrame(nullptr, wxID_ANY, "wxWidgets Layout Demo") { new wxCheckBox(this, wxID_ANY, "A checkbox directly in a frame"); }
The "checkbox in a panel" and "checkbox in a dialog" get a white background when focusing the respective window (e.g. by clicking the top bar), while the "checkbox directly in a frame" does not. In fact, the dialog will also flash white when focused. Whether or not sizers are used does not seem to affect this.
I wonder if KiCad is affected by this?
FWIW, this issue comes up in various places in Aegisub (specifically this experimental release that builds with wxWidgets master and adds a dark mode toggle). But I am only mentioning this since you asked for downstream effects above; I don't want to pressure anyone into working on this.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Thanks for the reproducer! I do see the problem, and it looks like the checkbox is painted in white background when the TLW containing it is activated, so maybe it's not UI-state-related, after all. I'll try to debug more when I can.
And thanks for the last part too, but I would genuinely like to fix this, it's just that I had no idea where to start, maybe this example will help me find something.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
I actually have a very dumb fix:
diff --git a/src/msw/control.cpp b/src/msw/control.cpp index 70a51b2bffe..594d8440aba 100644 --- a/src/msw/control.cpp +++ b/src/msw/control.cpp @@ -136,7 +136,10 @@ bool wxControl::MSWCreateControl(const wxChar *classname, wxMSWDarkMode::AllowForWindow(m_hWnd, support.themeName, support.themeId); if ( support.setForeground ) + { SetForegroundColour(wxSystemSettings::GetColour(wxSYS_COLOUR_LISTBOXTEXT)); + SetBackgroundColour(wxSystemSettings::GetColour(wxSYS_COLOUR_LISTBOX)); + } if ( const int msgTT = MSWGetToolTipMessage() ) {
i.e. just setting the background colour is enough to prevent it from turning to white.
But I still have no idea why does this happen, there must be some place where we don't handle the absence of explicitly set background colour correctly, but I don't see where...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Finally found the real culprit, thanks again for the simple reproducer!
I'm almost sure that #26087 is correct and it does fix the problem for me, but please let me know if you notice any other problems after applying it. If not, I'll merge it soon.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
I can confirm that #26087 fixes all instances of this problem on the sample and in Aegisub for me. Thank you for fixing this so quickly!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()