NVDA reports selection incorectly in VS 2008 code editor #1358

Open
nvaccessAuto opened this Issue Feb 8, 2011 · 4 comments

1 participant

@nvaccessAuto

Reported by aleksey_s on 2011-02-08 08:37
STR:

  • open vs 2008
  • file->new->file
  • choose a c++ file template
  • type something like
#include <iostream>
  • press "enter" to create new line
  • navigate up to place cursor on the first line
  • press shift+end Actual results: NVDA announces "#include "
@nvaccessAuto

Comment 1 by aleksey_s on 2011-02-08 08:43
There also is another issue with reporting selection in that editor. when you adjust already existing selection, NVDA reports it twice: firstly the new selection, then the old one.

This raises a question whether !EditableTextWithoutAutoselectDetection was correctly chosen as a base class for the control. What events object is expected to fire for auto select detection to work?

I contacted original author of the app module without any response.

@nvaccessAuto

Comment 2 by jteh (in reply to comment 1) on 2011-02-08 09:40
Replying to aleksey_s:

This raises a question whether !EditableTextWithoutAutoselectDetection was correctly chosen as a base class for the control.

This means that NVDA just detects selection changes when you press selection keys. Events are not used. If this is reporting double changes, there is most likely a bug in the !TextInfo implementation somewhere. You should debug this before addressing the following question.

What events object is expected to fire for auto select detection to work?

See the NVDAObjects.behaviors.!EditableTextWithAutoSelectDetection class. We now know it fires valueChange, so generally, you'd make valueChange call textChange.

@nvaccessAuto

Comment 3 by aleksey_s (in reply to comment 2) on 2011-02-08 11:06
Replying to jteh:

This means that NVDA just detects selection changes when you press selection keys. Events are not used.

So it will not be able to detect selection if done with mouse, or programmatically, right?

If this is reporting double changes, there is most likely a bug in the !TextInfo implementation somewhere. You should debug this before addressing the following question.

There definitely are bugs in !TextInfo implementation, e.g. seems that in vs API offsets are calculated from 1, not from 0, but !TextInfo code isn't always aware of it. Finally, I think that !VsTextEditPaneTextInfo doesn't need to be derived from !OffsetsTextInfo, since it can expand to word by using vs API and so on, with lesser number of calls to the API. However, I am not so good with understanding the basic !TextInfo. Currently, !OfssetsTextInfo is easier to understand for me.

Anyway, I am not sure how this can affect select detection so that it reports twice. the !VsTextEditPaneTextInfo doesn't manage when to report selection changes, it just informs about selection offsets when requested by !OffsetsTextInfo.

@nvaccessAuto

Comment 4 by jteh (in reply to comment 3) on 2011-02-08 18:38
Replying to aleksey_s:

Anyway, I am not sure how this can affect select detection so that it reports twice.

I'm not really sure either. The script you're interested in is editableText.!EditableTextWithoutAutoSelectDetection.script_caret_changeSelection. In short, it fetches the old selection, sends the key, fetches the new one and sends them off to be compared/spoken. If the old selection is somehow wrong or the offsets change, it can cause problems. I suggest you start debugging by looking at the offsets of the old and new selections.

@nvaccessAuto nvaccessAuto added the bug label Nov 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment