NVDA is not always moving the cursor during SayAll. #418

Closed
nvaccessAuto opened this Issue Jan 1, 2010 · 7 comments

1 participant

@nvaccessAuto

Reported by oaron on 2009-09-18 21:38
When reading longer texts (tested in microsoft word and notepad), NVDA is not moving the system cursor properly. The bug occurs after several minutes of reading, using the SayAll function of NVDA. (tested with the built in Espeak and the Sapi5 speech drivers)

@nvaccessAuto

Comment 1 by jteh on 2009-09-21 07:54
Please provide exact steps to reproduce and results with built-in eSpeak using Notepad. For example, how big does the document need to be? How long do you have to run say all before this becomes a problem? How many lines were read (roughly) before the problem occurred? What actually hapens incorrectly; i.e. does the cursor move to the start of the document or does it just stop following after a certain point?
Changes:
Milestone changed from 2009.1 to 2009.2

@nvaccessAuto

Comment 2 by oaron (in reply to comment 1) on 2009-09-21 14:50
When the document is small (e.g. The Key Commands for NVDA), it stops following the cursor after a certain amount. In the example of the Key Commands, it stops following the text when NVDA reaches the html navigation commands.
In large texts (such as a book), the cursor stays where the SayAll command was issued, sometimes it goes down by a few lines.
In other programs, such as a free text editor called Metapad, NVDA works fine when the SayAll command is active.

@nvaccessAuto

Comment 3 by mdcurran on 2009-12-03 03:17
Fixed the issue in standard edit controls (Notepad). It seems that telling the edit control to set its caret position does so but doesn't scroll the window to follow the caret. And therefore when after sayAll pressing an arrow key, the edit control jumps the caret back on to the screen, rather than either leaving it where it was or scrolling the screen to where the caret is.
The MS Word bug I'm pretty sure is totally unrelated, as from the tests I have done, the caret never really moves from the start location.
Edit control Fix committed in r3408.

@nvaccessAuto

Comment 4 by mdcurran on 2009-12-03 04:13
After further investigation, the situation in Microsoft Word is identical in that once the caret moves off the screen, the screen does not scroll to follow. Pressing the arrow keys at this point shoots the caret up to the the top of the first screen.

However, I can not find any method in the Word object model to scroll the window/document to the caret (insertion point). If anyone knows of how to possibly do this, please reply to this ticket.

@nvaccessAuto

Comment 5 by mdcurran on 2010-01-05 03:22
Seems to be fixed in r3453.
Now when setting the caret in Microsoft Word, we call ScrollInToView on the Winword Window object, giving it the range we wish to set the caret to.
This works fine in Word 2007. Not yet tried in 2003.
Please report any strange side affects like the document seeming to jump all over the place due to scrolling.
Will close after its proven that this works ok both in 2003, and that there's no strange visual jumping.

@nvaccessAuto

Comment 6 by mdcurran on 2010-01-05 03:36
Seems to work in Word 2003 for me.

@nvaccessAuto

Comment 7 by mdcurran on 2010-01-06 04:02
I'll close for now as fixed. Though we can always reopen if someone notices a problem.
Changes:
State: closed

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