Don't use UIATextInfo for DevExpress UIA Elements with Text Pattern without Document range#10918
Conversation
See test results for failed build of commit 2a5c75052e |
|
This would certainly cause one extra cross-process call. Probably not too important for most scenarios, but as Microsoft moves more things to technologies such as Windows Defender Application Guard, it will be very important to limit the amount of cross-proc calls to the smallest number possible. Though to be honest, in order to do this, I think some significant restructuring of NVDA's UIA support is needed anyway. My personal view is that if a control is really broken like this, we should just try and log some useful technical info and leave it for the app developers to fix. I'm assuming here that even with this pr, the control in question doesn't really become any more functional? |
|
I think you have a fair point here. I will try to come up with an alternative approach that's more specific to the erroneous control. |
057bb40 to
7f4f867
Compare
|
I just changed this to be specific to the DevExpress Rich Edit. |
Link to issue number:
None
Summary of the issue:
In a broken UIA Text Control by DevExpress, the control exposes a text pattern with a NULL DocumentRange. This causes all sorts of trace backs in NVDA on focus, entering with the navigator object and viewing the log.
It looks like implementing the DocumentRange property is mandatory according to the docs.
Description of how this pull request fixes the issue:
When checking what TextInfo class to use for a DevExpress rich edit control UIA object, also check whether the DocumentRange has a True boolean value.
Testing performed:
Tested that regular UIA text controls still behave as expected, and that the broken controls use NVDAObjectTextInfo instead. Note that's not a viable solution for these controls, but they are broken in many ways and don't expose a cursor using the native Win32 APIs either.
Known issues with pull request:
None
Change log entry: