A question about dark mode, plugins, and an owner-draw ComboBox
-
I’m working on a plugin and I have a couple questions about dark mode. I’m hoping someone who reads this will know the answers. I have looked at the code, but I don’t really follow everything it’s doing.
My Settings dialog uses a ComboBox with style:
CBS_DROPDOWNLIST | CBS_OWNERDRAWFIXED | WS_VSCROLL | WS_TABSTOP
I’m sending an NPPM_DARKMODESUBCLASSANDTHEME message with wParam = NppDarkMode::dmfInit at the end of my WM_INITDIALOG process in the hopes of not antagonizing users who have dark mode enabled.
The ComboBox is fine in light mode but it is messed up in dark mode.
-
Am I correct in thinking that the dark mode subclass process does not support owner-draw combo boxes?
-
Is there a way to exempt just that one control from the processing and try to figure out myself how to set the right colors, or do I need to drop the NPPM_DARKMODESUBCLASSANDTHEME message and either stay in light mode or handle all of the dark mode processing in my code? (Staying in light mode is an option; it’s not like users have the Settings dialog open all the time. The main dialog, fortunately, doesn’t seem to have any controls the dark mode handler doesn’t like. Yet. But I may need to go to owner-draw buttons at some point, and perhaps they will have the same problem.)
-
-
@Coises said in A question about dark mode, plugins, and an owner-draw ComboBox:
The ComboBox is fine in light mode but it is messed up in dark mode.
Try passing the control’s handle to the
::SetWindowThemefunction provided by theuxthemeheader, usingL"DarkMode_CFD"as thepszSubAppName; to restore light mode, call it with the same arguments, but changepszSubAppNameto a null pointer.Credit goes to @klaus101 for identifying the (undocumented) dark theme’s name in this post.
P.S. The drop-down list background color may still need to be owner-drawn with an appropriate color. The only functional example I can provide is in Free Pascal, so YMMV.
-
@rdipardo said in A question about dark mode, plugins, and an owner-draw ComboBox:
Try passing the control’s handle to the
::SetWindowThemefunction provided by theuxthemeheader, usingL"DarkMode_CFD"as thepszSubAppName; to restore light mode, call it with the same arguments, but changepszSubAppNameto a null pointer.Thanks, Robert. At first attempt, this doesn’t appear to solve the problem.
The colors are right with just NPPM_DARKMODESUBCLASSANDTHEME; the problem is that the static control shows unknown text instead of the selected drop-down entry, and attempting to select from the drop-down produces bizarre highlighting and tracking instead of what is expected (and still doesn’t set the static control). Adding the SetWindowTheme call doesn’t change that. Removing NPPM_DARKMODESUBCLASSANDTHEME, of course, makes everything else light, and for the control in question, SetWindowTheme only seems to change the drop-down chevron. Interestingly, NPPM_DARKMODESUBCLASSANDTHEME does get all the colors right, including in the owner-drawn drop-down; it just breaks the functionality in the process.
The problem goes away entirely if I remove the CBS_OWNERDRAWFIXED style (but then, of course, it doesn’t display as intended, showing the color associated with each indicator that can be selected). That’s why I feel like the problem is most likely to do with the sub-classing. I can’t find any clear documentation on how all that works. I don’t even know why the controls are being sub-classed, and not just themed. Maybe there is a way to exempt that control from sub-classing, and do whatever it is that the sub-classing does in my own code?
A pointer to actual documentation on this design, how it works and how it is meant to be used would be wonderful, but I’m guessing no such thing exists. :-(