Some ansi RichEdit window classes return unicode text when asking for a range

[nvaccessAuto]

Reported by mdcurran on 2007-11-29 05:04
Some windows that have a class such as RichEdit20 (registered as ansi, not unicode) give back unicode text when sending them an EM_GETTEXTRANGE message.
It doesn't seem to matter whether you use sendMessageW or sendMessageA, they both still end up returning unicode text.
The problem with this is that NVDA assumes that if a RichEdit window class is not unicode, then the text returned will be ansi. But, not all window classes seem to follow this rule.
This problem is evident in the Jarte text editor, where its RichEdit20 (ansi) control gives back unicode text, therefore when reading by word or line (anything else other than character) only the first character is announced as the second character usually will be 0x0, as the text is really unicode, not ansi.
To fix this, we could just assume all richEdit controls give back unicode text, though I'm sure this is not the case for some.
Certainly RichEdit20A gives back ansi, so we could just make an exception for RichEdit20 itself. Though I also have a feeling that its not actually the fault of the window class, but the fault of the application that wrongly implements the handlers for the control.
More research needs to be done on this problem, I have seen mention of it around on the net before.
Perhaps we could make a Jarte appModule which forces that particular control to be treeted as unicode, though this would get rather silly if other apps started also showing this problem.

[nvaccessAuto]

Comment 1 by mdcurran on 2007-11-29 11:16
Fixed in r1371. We firstly retreave the text as a byte array. If there is a non-0 byte value where the ansi NULL character should be, this is clearly unicode text so treet it as so. This could break with some double-byte ansi character sets, however until we can correctly identify a window's locale, we can't do anything about this anyway.
Changes:
State: closed