This sort of seems to work (just extracting a color from the 64-bit numbers) but I’m not sure if it’s really “correct”. I’m worried that it will disable blending, etc. that the semantic colors are supposed to have because I wasn’t able to include the first part of the 64-bit value. The resulting colors more or less “look” pretty close though…
[code]dim bg as color
dim fg as color
dim bgValue as color
if IsDarkMode() then
bg = &c252525
fg = &cFFFEFE
bgValue = &c252525
bg = &cE7E7E7
fg = &c000000
bgValue = &cE7E7E7
TextColor, FillColor, and the like are available globally even outside the Paint event. I’m reluctant to share this information as many people abuse drawing. However, there are needs for it - watch TextArea fail during a light/dark switch.
When I tried to correct this issue by taking advantage of the AppearanceChanged event (a workaround I should not have to do) I discovered the same issue Isaac has. <https://xojo.com/issue/54616>
The issue you guys are running into is that the underlying system color (which is where we pull these colors from) is not guaranteed to have changed until a graphics context is painted, even though the system notifies you that the user has changed the system appearance.
See the updated example project in <https://xojo.com/issue/54786>
In one Label, the current Text/Fill/…-Color is updated in a Timer. And there is a Canvas.Paint
The Canvas does update the Colors - the Timer (which is accessing the “global” one), never does.
This somehow contradicts with what you’re saying I would then expect the “global” one to change at least after the Canvas.Paint has fired when switching Dark/Light-Mode.