i’m currently working on the update of our plugin to support Rhino 8. But i’m struggeling with the colors in dark mode. So i have some questions how it is done properly.
Where can i get the current theme mode (dark/light) and the correct content background color via C++ API?
I use panels which are derived from CRhinoTabbedDockBarDialog, but it seems it does not set correctly the font color. In my case all static text fields are always black.
I Just compiled the Developer Samples and started SampleUserInterface and there is the same problem. I added a static text to the dialog and it’s also black but should be white same as in the Modeless Dialog:
Some more info: OnCtlColor in CRhinoTabbedDockBarDialog derived classes does not get called, which seems weird, In CRhinoDialog derived classes OnCtlColor gets called
Are there any further changes needed to implement fully support for Dark Theme?
Thanks @dale for the answer, but this is only half of the battle.
This workaround results in a lot of work in our project
AND we still struggle to react correctly in dark theme in our owner drawn controls. Therefore we would need to know if dark theme is on and which colors are used? Any hints on that?
Further:
So is there already an open incident? Are there plans to fix this?
First, I’ll expose all of the theme colors in a way that’s easy-to-use way. I’ve been dragging my feet on this.
Also, although I thought my days of writing owner-drawn MFC controls were over, I can (try to) take a run at what you need. I need a list of what controls are needed.
I’d prefer, however, you do this yourself, which will be made easier with my first comment.
Finally, I don’t hold out much hope of forwarding WM_CTLCOLOR messages to docking dialogs in DLLs. I’ve make a few unsuccessful runs at this.
Sounds great! Do you also expose the current state (dark/light)? Can you give me any rough timeline?
I don’t think it’s necessary for you to create owner drawn MFC controls. But as CRhinoUiStaticEx does correctly set the colors, it would be very interesting how this is done? Are they totally owner drawn?
But to color our controls depending on the correct theme we need the colors and of course WM_CTLCOLOR messages.
Ok, i can imagine it’s difficult to forward those messages. But is there a way to create a virtual method which get’s called instead of sending a WM_CTLCOLOR message? Maybe this could solve all the troubles?
Rhino 8.7 will be released this week, so I’m too late for that. It’s reasonable to expect this in Rhino 8.8.
Yes. I am happy to share the code with you, although you won’t be able to build it as it uses some internal classes. After my SDK additions, you’ll be able to build with some minor edits.
ok, this is something i do not understand. As far as i understood the windows message handling for the WM_CTLCOLOR is that the control (e.g. the button control) sends a windows message to the parent window to provide different brushes. (also explained here TN062: Message Reflection for Windows Controls (MFC))
As far as i understood the messages should be there, the question is who receives them?
@dsw - I’ve added a new CRhinoUiPaintColorSettings::RunningInDarkMode method to the Rhino 8.7 C++ SDK. I’m hoping this and the colors found on this class are enough for C++ developers.
