#219 accessibility helper high-contrast-mode/theme ignored in edit control

[Martin Lemburg]

Sincerely the XML Copy Editor respects only party the high-contrast-mode or the chosen high-contrast-theme #1.
The edit control renders with white background and the normal font color(s), but in the black based high-contrast-mode or themes the system coloring is mandatory, so that the edit cotnrol should have COLOR_WINDOW color as background and as default text color simply the COLOR_WINDOWTEXT system color.
Any other color used for text coloring must meet high-contrast-rules, which means, that the difference to the background color must be very "big".

Is there any chance for a bug fix?

[Zane U. Ji]

The syntax highlighting is controlled by Scintilla. Unfortunately, the developer didn't want to fix it. https://sourceforge.net/p/scintilla/bugs/1274/

[Martin Lemburg]

I wonder why other applications using Scintilla are able to follow the mandatory windows accessibility guides ... e.g. high-contrast-mode colors.
So - are they using Scintilla the right way or did its developers fix anything without documenting?

"You" have the "power" to react on detecting high-contrast-mode to set up a control in the wanted, desired or mandatory way, to modify its visual representation, its colors!

So - even if Scintilla does not react automatically, you could for sure force it by redefining the colors to be used. couldn't you?

I understand you pointing on Scintilla, but I even would understand the Scinitalla developers pointing back to you, because here there could be hard-to-resolve conflict between application defined behavior and mandatory control behavior!
If there is a defined syntax highlighting, waht should Scintilla do?
Disable it? Invert the colors?
Or should Scintilla do nothing unless the application defines the way to behave? E.g. by disabling the syntax highlighting or re-defining the color scheme?