Visual Studio adapts to high-contrast mode just fine, but SciTE still keeps the original colors when it is turned on.
This should be changed to integrate with the rest of the system (Windows 7).
I doubt there is anything reasonable that can be done for this. I won't be working on it.
The is no reasonable thing to be done?
I have eye disablitities and I wonder why there isn't anything reasonable to be done!
Since high-contrast is an accessibility utility Microsoft defines the usage of system colors as mandatory!
So - if high-contrast-mode is switched on, the control background should be COLOR_WINDOW and the text should be COLOR_WINDOWTEXT or something different if the contrast to the background is high enough.
Even syntax highlighting is not that important, because the high-contrast-mode should enable people like me to be able to work with the computer and less disturbing noise keeping us from working with the computer.
The edit control I built in in the application I develope with my colleagues is themed and the theming visual manager cares automatically for high-contrast-mode, why not Scintilla?
Your application can respond to WM_SYSCOLORCHANGE for high-contrast mode by setting the colours as you desire. Scintilla just follows the settings made by the application. WM_SYSCOLORCHANGE is sent to top-level windows so Scintilla does not detect that this has occurred, unless the message is resent by the application.
Having Scintilla override application settings in high-contrast mode would mean that applications would not be able to choose different ways to respond. For example, an application may decide to impose a minimum font weight in high contrast mode or turn italics off.
I understand your point about seeing the application in the duty to react on activating the high contrast mode.
I see, too, that Scintilla is not like any other edit control switching automatically.
So … why not:
This would lower the barrier for applications to react on switching on/off hight-contrast-mode, choosing a high-contrast-theme and raises the chance for people like me to have more usable UIs, since the application developers won't need to do "too" much?
Other edit widgets that do not change automatically when high-contrast is set or modified include text editing areas in Firefox, Qt Creator, WinMerge, Idle, and Sublime Text 2.
The application should still process/forward WM_SYSCOLORCHANGE since it is only sent to top-level windows. Other approaches like checking if high-contrast mode or the system colours have changed during repaints or clock ticks are less robust.
It would be OK to have an API that performed a set of colour changes that could then be overridden by specific application choices.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.