textpad - selection done using shift + arrow keys is not read

[nvaccessAuto]

Reported by manish on 2014-10-07 01:26
In the text pad app, NVDA doesn't read anything when text is selected or unselected using shift + arrow keys.
Blocking #4790

[nvaccessAuto]

Comment 1 by jteh on 2014-10-07 02:41
I'm pretty sure we can only access this using GDI hooking/display model. If so, the only way we can detect selection is using colour, so either we can't get correct colour information or it doesn't use the standard system highlight colours. Can you check whether the colour of selected text is different to unselected text according to NVDA?

[nvaccessAuto]

Comment 2 by manish (in reply to comment 1) on 2014-10-08 03:08
nvda + f reports unselected text as "black on white" and selected text as "white on navy blue".
Replying to jteh:

I'm pretty sure we can only access this using GDI hooking/display model. If so, the only way we can detect selection is using colour, so either we can't get correct colour information or it doesn't use the standard system highlight colours. Can you check whether the colour of selected text is different to unselected text according to NVDA?

[nvaccessAuto]

Comment 3 by jteh on 2014-10-08 04:00
Unless your system is different, navy blue isn't the standard highlight colour. You can fix this by subclassing EditableTextDisplayModelTextInfo for this control and setting backgroundSelectionColor to the appropriate colors.RGB object. (You'll need to get the values from getTextWithFields on the TextInfo using the Python console.)

Do you know if this works with other screen readers? If so, it'd be interesting to know how they're detecting selection. Maybe they're more tolerant of variances in the colour, they only use the foreground colour, etc.

[nvaccessAuto]

Comment 5 by manish (in reply to comment 3) on 2014-10-13 02:46
The backGroundSelection color is already set to the value returned by the getTextWithFields() method.
I did the following after selecting some text in textpad and pressing ctrl+nvda+z:
import textInfos
info=focus.makeTextInfo(textInfos.POSITION_SELECTION)
fields=info.getTextWithFields()
print fields

This returned the value
backgroundColor=rgb(red=10, green=36, blue=106)
Then I did:
info.backgroundSelectionColor
this also returned:
rgb(red=10, green=36, blue=106)

Also, creating an appmodule and assigning a textInfo class to the object that has the backgroundSelectionColor property set to anything else, e.g. rgb(0, 0, 128) for navy blue or rgb(25, 25, 112) for midnight blue causes makeTextInfo(POSITION_SELECTION) to fail every time with "cannot find display_rect". The makeTextInfo method succeeds only if the rgb value is set to 10,36,106.

Also, even if we don't make any of the above changes, the makeTextInfo method only succeeds only about half the times. At other times, it fails with the error cannot find display_rect in displayModel.py.

Jaws is able to pick up the selection correctly without any modification.

Replying to jteh:

Unless your system is different, navy blue isn't the standard highlight colour. You can fix this by subclassing EditableTextDisplayModelTextInfo for this control and setting backgroundSelectionColor to the appropriate colors.RGB object. (You'll need to get the values from getTextWithFields on the TextInfo using the Python console.)

Do you know if this works with other screen readers? If so, it'd be interesting to know how they're detecting selection. Maybe they're more tolerant of variances in the colour, they only use the foreground colour, etc.

[nvaccessAuto]

Comment 6 by jteh (in reply to comment 5) on 2014-10-13 03:09
Replying to manish:

The backGroundSelection color is already set to the value returned by the getTextWithFields() method.

Okay. That suggests the highlight colours are just different on your system.

The makeTextInfo method succeeds only if the rgb value is set to 10,36,106.

That suggests it only finds the selection in that case, which makes sense.

This all suggests it should be able to detect the selection at least some of the time. Does NVDA+shift+upArrow report the selection correctly?

[nvaccessAuto]

Comment 7 by manish (in reply to comment 6) on 2014-10-14 00:54
I am doing this on a laptop. NVDA + shift + up arrow takes me to the parent object.
NVDA+tab is able to read out the current selection correctly every time.

[nvaccessAuto]

Comment 8 by jteh on 2014-10-14 01:37
Oh. I think I understand why this isn't working.

Technical: NVDAObjects.window.DisplayModelEditableText inherits from NVDAObjects.behaviors.EditableText. Now that we support selection where possible, it should probably inherit from NVDAObjects.behaviors.EditableTextWithoutAutoSelectDetection instead.

[nvaccessAuto]

Comment 9 by manish (in reply to comment 8) on 2014-10-14 02:21
Doing this is some improvement. Now, even if I select a single word or character, the entire line containing the selection is spoken. Also, the first and last lines of selection seem to get silenced when using control+up and down arrows.

[nvaccessAuto]

Comment 10 by manish (in reply to comment 7) on 2014-10-19 02:58
Correction. nvda+tab also reports the entire line even if a single character or word is selected. When I was trying this, I had the entire line selected and didn't realise the difference.
Replying to manish:

I am doing this on a laptop. NVDA + shift + up arrow takes me to the parent object.

NVDA+tab is able to read out the current selection correctly every time.

[nvaccessAuto]

Comment 11 by jteh on 2015-01-06 06:59
When you select just a single word, does NVDA report the same colour for that word and for the rest of the words on that line?

[nvaccessAuto]

Comment 12 by manish (in reply to comment 11) on 2015-01-11 00:33
When selecting a single word and using nvda+f, nvda reads " Whaite on black" for the selected word and " black on white" for the not selected text.
Replying to jteh:

When you select just a single word, does NVDA report the same colour for that word and for the rest of the words on that line?

[bhavyashah]

Something similar happens in Excel as noted in another ticket also. Selection via Shift+arrow keys within Excel cells is not reported either. Are these related in any way?

[ruifontes]

Sorry, but here with Excel 2013 e last Next version of NVDA, selection with Shift+arrows is announced as expected. Rui Fontes

…

-----Mensagem Original----- De: bhavyashah Data: 18 de agosto de 2017 16:36 Para: nvaccess/nvda Cc: Subscribed Assunto: Re: [nvaccess/nvda] textpad - selection done using shift + arrow keys is not read (#4535) Something similar happens in Excel as noted in another ticket also. Selection via Shift+arrow keys within Excel cells is not reported either. Are these related in any way? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Adriani90]

cc: @LeonarddeR

[Adriani90]

@manish are you still able to reproduce the issue?

[Adriani90]

I am testing in NVDA 2019.1.1 and Textpad 8.1. The issue is still reproducible. Text selections are not reported at all.

cc: @LeonarddeR this seems to be yet another display model case.

[Adriani90]

With NVDA alpha-32879,41418d7a (2024.4.0.32879) and Textpad 9.5, the issue in #4535 (comment) is still reproducible.