Comment 1 by jteh on 2013-06-20 01:55
Mick, are there any COM events to detect caret/selection changes in Word or do we have to implement scripts for this?

Comment 2 by mdcurran (in reply to comment 1) on 2013-06-20 04:01
Replying to jteh:

Mick, are there any COM events to detect caret/selection changes in Word or do we have to implement scripts for this?

I'm really not sure off the top of my head. We certainly don't use any MS Word COM events right now. Also, based on experiences with PowerPoint and Protected mode etc, I'm thinking that scripts, as long as they do the trick are quicker to code and have more chance of working in high-security situations such as protected mode.

Comment 3 by falinn.onda (in reply to comment 2) on 2013-06-21 05:18
Thanks for the quick response, word is such a commonly used editor, people expect you to be able to work with it in most jobs.

I would like to add that undo is not the only case that creates synchronization issues, while braille is thathered to focus. Examples include:

• redo
• CTRL+backspace : the delete is reported on voice but braille is not updated.
• CTRL+DELETE: braille is not updated and also there is no voice indication of delete.
• user macros: I have added a SIFT+DELETE command that delete current line. similarly delete paragraph can be also useful. If i use those macros by pressing keyboard shortcuts, braille is not updated.

For some reason when braille tathered to review it is synchronized a bit differently. In this case CTRL+DELETE updates braille display.

If If you think that that there is a way for word to notify NVDA upon change, in general, i think it might solve many braille synchronization issues.

Either way of fixing synchronization on the above mentioned cases will be welcomed.

Could Braille experts please test and report whether these Braille synchronization issues (particularly with MS Word's Undo and Redo, Ctrl+Backspace and Ctrl+Delete) still occur?

@falinn.onda is this issue still reproducible?
cc: @bramd the initial author seems not to be available on Github anymore. Do you have any possibility to test if this issue is still reproducible?

I can still reproduce this with Word 2016, non-UIA. It isn't specific to a particular braille display.

@dkager how is this now with NVDA 2023.1 RC1 or NVDA 2022.4?

I tried locally to add braille.handler.handleUpdate to source\NVDAObjects\iaccessible\winword.py and there to event_caret function.

It worked almost. If there is for example: "12345", and then ctrl-z is pressed 5 times, there is not necessarily blank display. If pressing and holding ctrl-z it seems to work or if pressing ctrl-z with long delay between presses, it seems to work also. But if something between these, it may not work.

@LeonarddeR what do you think about this? Is my approach wrong?

@burmancomp is this with or without UIA enabled in Word?

Do you mean this setting: "Use UI Automation to access Microsoft Word document controls"? It is currently " Default (Where suitable)".

In blank document typing q then ctrl-z. Quite often q remains in braille line. If there are more characters like qwerty, others y, t ... seems to be removed correctly. It seems that event_caret would not be always executed.

Do you mean this setting: "Use UI Automation to access Microsoft Word document controls"? It is currently " Default (Where suitable)".

BB

It may work better with UIA set to always, and when NVDAObjects\UIA\wordDocument.py also includes event_caret.

I have understood that UIA does not work properly in ms word before Windows 11. I have not Windows 11 installed.

I'm considering if it would be worth of opening draft pull request. I suppose that braille.handler.handleUpdate should be enough in most cases but when document contains only 1 character and then ctrl-z is pressed to undo this does not work always. As if caret event would not be fired every time, but why it is happening (if this is the case), I do not know.

I added event_textChange, event_textInsert and event_textRemove functions to WordDocument class which just write a log line. It seems that any of these events were never fired because there was no log line they should have written.

I should have time to test so let me know what you think I could try.

It seems that this is larger issue because display is not necessarily updated when using ctrl+x.

I have also noticed that when in blank document, repeating following steps may cause situation where entered character is not updated to braille display:

• type character
• press control+z

Log lines are attached. Version is current main branch source.
no_updates.txt