These changes address an issue with unreliable WM_SETTINGCHANGE "ImmersiveColorSet" messages upon switching between dark and light mode. See #26692.
Normally when the system switches between modes, Windows sends two WM_SETTINGCHANGE messages - one before the switch and one after. The problem addressed is that the second message never appears. The reason is unknown. It may be due to a timeout, since this message is broadcast using SendMessageTimeout().
The fix has two parts.
When the WM_SETTINGCHANGE is received, instead of immediately issuing a wxSysColourChangedEvent, we instead post WM_SYSCOLORCHANGE to defer that action until after the mode switch is finished. This guarantees we issue at least one wxSysColourChangedEvent after the mode switch.
The change above exposed a latent bug in the dark mode initialization. The variable gs_wasActiveOnStartup was not initialized correctly because ShouldAppsUseDarkMode() did not return an accurate value until a window was created. This problem was masked by having two WM_SETTINGCHANGE messages, one with IsActive() true and one false. This caused the comparison IsActive() != gs_wasActiveOnStartup to be true one time despite gs_wasActiveOnStartup begin wrong. The solution is to call the undocumented API RefreshImmersiveColorPolicyState() so that ShouldAppsUseDarkMode() returns the correct value.
https://github.com/wxWidgets/wxWidgets/pull/26698
(2 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.![]()