Comment 1 by jteh on 2014-09-30 02:04
I suspect AutoHotkey is using the backspace key to erase text. The problem is that NVDA intercepts the backspace key so it can speak the erased character, but it does not intercept every other key for performance reasons. This means that the backspace key gets handled later than the other keys; i.e. the intended order is messed up, which causes the kind of weirdness you are seeing. Some other screen readers run almost entirely within the application (so they "block" the application while they do their work), which is why you don't see this there.

I'd like to fix this, but I'm not really sure how we could.

Comment 2 by jteh on 2014-09-30 02:12
Technical: One possible solution I just thought of is to intercept all keys and queue sending them if there's a pending script which sends a gesture (such as backspace). Mick noted that such scripts shouldn't have a docstring, so we can test for that. It's not an ideal solution from a performance perspective, but it's probably better than jumbled characters. This may also fix some other issues.

Comment 3 by Palacee_hun (in reply to comment description) on 2014-09-30 15:53
Please try unchecking the "Intercept application keystrokes" option in NVDA keyboard settings. For me that fixes all missing and mangled characters with your first abbreviation example, and it works perfectly everywhere I've tried it. Please also remember that you can apply this setting just for certain apps using NVDA profiles, if you need that.
[to [ticket:4499 andrewd]([BR]]
Replying):

If abbreviation-expansion is coded as follows:

::ad::My name is Andrew

the expanded text is usually missing character(s). If coding:

:b0:ad::My name is Andrew

is used the abbreviation characters, are not deleted and the presence of NVDA does not result in lost characters. It is then necessary to delete the characters manually, which somewhat defeats the purpose of the facility.

I use an AutoHotKey script to put HTML tags into a file. This involves opening and closing tags with an intervening blank line and this exacerbates the problem. The following works on my machine:

:b0:pg::

Send, {home}

Sleep 200

Send,

nn

Sleep, 300

Send,

`n

Sleep, 300

Send, {del 3}

Send, {up 2}

Return

If selecting from a menu or hotkey instead of using the abbreviation, the following works well:

Send,

nn

`n{up 2}

Return

Other screen readers don't have this issue. Turning off speech or turning on sleep mode does not help.

Unless this has wider implications, it is a very minor issue.

Comment 4 by andrewd (in reply to comment 3) on 2014-09-30 22:08
Thanks. Yes, that fixes the issue completely for me. Unless there are wider implications (a) the problem is resolved and (b) I should have thought of the fix. As it happens, I have an NVDA profile for the text editor used when running the script.
Replying to Palacee_hun:

Please try unchecking the "Intercept application keystrokes" option in NVDA keyboard settings. For me that fixes all missing and mangled characters with your first abbreviation example, and it works perfectly everywhere I've tried it. Please also remember that you can apply this setting just for certain apps using NVDA profiles, if you need that.

[Replying to [ticket:4499 andrewd]([BR]]

):

If abbreviation-expansion is coded as follows:

::ad::My name is Andrew

the expanded text is usually missing character(s). If coding:

:b0:ad::My name is Andrew

is used the abbreviation characters, are not deleted and the presence of NVDA does not result in lost characters. It is then necessary to delete the characters manually, which somewhat defeats the purpose of the facility.

I use an AutoHotKey script to put HTML tags into a file. This involves opening and closing tags with an intervening blank line and this exacerbates the problem. The following works on my machine:

:b0:pg::

Send, {home}

Sleep 200

Send,

nn

Sleep, 300

Send,

`n

Sleep, 300

Send, {del 3}

Send, {up 2}

Return

If selecting from a menu or hotkey instead of using the abbreviation, the following works well:

Send,

nn

`n{up 2}

Return

Other screen readers don't have this issue. Turning off speech or turning on sleep mode does not help.

Unless this has wider implications, it is a very minor issue.

Comment 5 by jteh on 2015-06-22 05:15
The solution I mentioned in comment:2 has been implemented in #2953 and will be in the "next" snapshot for 22 June. It'd be good if someone could test this with "Handle keys from other applications" disabled to see if this change solves the problem.

Comment 7 by andrewd (in reply to comment 5) on 2015-06-22 22:12
Jamie, not sure if I have misconstrued your request. My original issue was fixed by unchecking "Handle keys from other applications as suggested by Palacee_hun . You asked for a check "with "Handle keys from other applications" disabled" which I take to mean unchecked.

Testing with the snapshot produces the same results as previously. With "Handle keys" unchecked it still works fine and when checked characters still get corrupted.

Replying to jteh:

The solution I mentioned in comment:2 has been implemented in #2953 and will be in the "next" snapshot for 22 June. It'd be good if someone could test this with "Handle keys from other applications" disabled to see if this change solves the problem.

Comment 8 by jteh (in reply to comment 7) on 2015-06-22 23:39
Replying to andrewd:

Jamie, not sure if I have misconstrued your request. My original issue was fixed by unchecking "Handle keys from other applications as suggested by Palacee_hun . You asked for a check "with "Handle keys from other applications" disabled" which I take to mean unchecked.

Err, my bad. I meant enabled, not disabled. So I wanted you test with it checked, not unchecked. Sorry for the confusion.

Testing with the snapshot produces the same results as previously. With "Handle keys" unchecked it still works fine and when checked characters still get corrupted.

Hmm. Just to confirm, which exact snapshot was this? Was it next-12152,46d0a2e?

Comment 9 by andrewd (in reply to comment 8) on 2015-06-23 00:23
Now it's me bad. I used nvda_snapshot_master-11150,eedcef5 previously. Just tried with next-12152,46d0a2e and it worked perfectly with the checkbox checked.

Replying to jteh:

Replying to andrewd:

Jamie, not sure if I have misconstrued your request. My original issue was fixed by unchecking "Handle keys from other applications as suggested by Palacee_hun . You asked for a check "with "Handle keys from other applications" disabled" which I take to mean unchecked.

Err, my bad. I meant enabled, not disabled. So I wanted you test with it checked, not unchecked. Sorry for the confusion.

Testing with the snapshot produces the same results as previously. With "Handle keys" unchecked it still works fine and when checked characters still get corrupted.

Hmm. Just to confirm, which exact snapshot was this? Was it next-12152,46d0a2e?

Comment 10 by gmhtml (in reply to comment 8) on 2015-06-23 00:25
Replying to jteh:

Replying to andrewd:

Jamie, not sure if I have misconstrued your request. My original issue was fixed by unchecking "Handle keys from other applications as suggested by Palacee_hun . You asked for a check "with "Handle keys from other applications" disabled" which I take to mean unchecked.

Err, my bad. I meant enabled, not disabled. So I wanted you test with it checked, not unchecked. Sorry for the confusion.

Testing with the snapshot produces the same results as previously. With "Handle keys" unchecked it still works fine and when checked characters still get corrupted.

Hmm. Just to confirm, which exact snapshot was this? Was it next-12152,46d0a2e?

I'll add my two cents in just to be sure.
Indeed it is the snap shot as mentioned above.
When I tick the box "handle keys from other applications" the problem of text none expansion/corruption returns.
If I then untick the box, the problem persists with a NVDA restart (ctrl+alt+n) required to fix the problem and thus make things work again for the expander.

Comment 11 by jteh (in reply to comment 10) on 2015-06-23 00:37
Replying to gmhtml:

When I tick the box "handle keys from other applications" the problem of text none expansion/corruption returns.

Interesting. So you're seeing different results to comment:9, where the correct snapshot (next-12152,46d0a2e) works as expected even with the box checked.

If I then untick the box, the problem persists with a NVDA restart (ctrl+alt+n) required to fix the problem and thus make things work again for the expander.

Hmm. I don't understand this. Even without the fix, a restart shouldn't be necessary to make a change to this setting take effect. That suggests there is another problem here.

Comment 12 by James Teh <jamie@... on 2015-07-10 04:26
In [7b7823c]:

Fix garbled text when typing in Outlook with braille enabled and with text expansion functionality (e.g. in AutoHotkey).

InputGesture.execute: if an intercepted command script (script that sends the gesture it intercepts) is queued and or has not yet completed its execution, queue any further gestures that do not have a script via a fake script that just sends the gesture. this ensures that input stays in order even if it was delayed by NVDA.
Fixes #2953, #4499.

Changes:
State: closed

Comment 13 by jteh on 2015-07-10 05:29
Changes:
Milestone changed from None to 2015.3

Comment 14 by gmhtml (in reply to comment 13) on 2015-07-11 03:42
Replying to jteh:
I have tested this with auto hot key, and I am still having trouble with expansions particularly if they are expansions with more than one word after they are presented.
The current fix seems to work for small words, but for larger sentences, or even blocks of text larger than one word, the result is random as to what will actually expand if I try this with the handle keys from other applications check box checked.
I am using the latest master post:
Version: master-11184,85bd3c4

Comment 15 by andrewd (in reply to comment 14) on 2015-07-13 00:42
I can confirm both that short expansions (which is what I normally use) work well but long ones as often as not do not. For example:
::pg::This should insert a paragraph of meaningless text. Let's see what happens.
sometimes works but often produces jumbled text.
Sorry about that.

Replying to gmhtml:

Replying to jteh:

I have tested this with auto hot key, and I am still having trouble with expansions particularly if they are expansions with more than one word after they are presented.

The current fix seems to work for small words, but for larger sentences, or even blocks of text larger than one word, the result is random as to what will actually expand if I try this with the handle keys from other applications check box checked.

I am using the latest master post:

Version: master-11184,85bd3c4

Comment 16 by jteh on 2015-07-13 02:17
Oh dear. I can confirm this.

Technical: The problem is that NVDA can't tell the difference between keys injected by NVDA and keys injected by other applications. This solution queues keys to ensure correct order, but that means we have to inject them, and while we're doing that, we must ignore injected keys to prevent loops. Unfortunately, that may also cause us to ignore keys that happen to arrive from other apps at the same time. Unless there's some way of detecting who injected a key, I don't know if/how we can fix this.
Changes:
Milestone changed from 2015.3 to None
State: reopened

Comment 17 by James Teh <jamie@... on 2015-07-15 08:59
In [35a682a]:

Merge branch 't4499' into next

Incubates #4499.

Changes:
Added labels: incubating

Comment 18 by jteh on 2015-07-15 09:01
Okay. Can you both please try the "next" snapshot for 15 July (which should be available in about 20 minutes) to see if this new fix solves the problem even with "Handle keys from other applications" enabled?

Comment 19 by andrewd (in reply to comment 18) on 2015-07-15 22:46
Unfortunately no difference with nvda_snapshot_next-12286,35a682a.exe. As mentioned many moons ago, it is the auto-backspacing that trips it up. That is:
::pg::This should insert a paragraph of meaningless text. Let's see what happens.
produces jumbled characters when the script is run with Handle Keys checked. On the other hand:
:b0:pg::This should insert a paragraph of meaningless text. Let's see what happens
produces perfect text but leaves the pg at the beginning. Lucky I proofread before sending - forgot to kill the script before writing pg
My suggestion, as I suspect there are much bigger fish to fry, is that you add a sentence at least in the interim suggesting that people uncheck the checkbox if encountering problems with scripts.

Replying to jteh:

Okay. Can you both please try the "next" snapshot for 15 July (which should be available in about 20 minutes) to see if this new fix solves the problem even with "Handle keys from other applications" enabled?

Comment 20 by jteh on 2015-07-15 23:00
Wow. That's weird. I expected that the characters at least wouldn't be jumbled, as the fix should now be able to detect the difference between NVDA injected keystrokes and keystrokes injected by other apps. I do still see some weird issues with the shift key, but no character jumbling here. Hmm.

Comment 21 by andrewd (in reply to comment 20) on 2015-07-15 23:52
I usually use this sort of script to drop HTML code into NoteTab, a text editor. Results are similar with Notepad. I just tried with MS Word. There is occasionally an error, but usually accurate. Also seems accurate when dropping into this edit field. Yes, weird.

Replying to jteh:b

Wow. That's weird. I expected that the characters at least wouldn't be jumbled, as the fix should now be able to detect the difference between NVDA injected keystrokes and keystrokes injected by other apps. I do still see some weird issues with the shift key, but no character jumbling here. Hmm.

Comment 22 by James Teh <jamie@... on 2015-07-16 03:42
In [171a430]:

Revert "When using text expansion functionality in software such as AutoHotkey, expanded text is no longer garbled when NVDA is configured to handle keys from other applications."

Even this solution doesn't seem to work reliably, so let's revert it until we can figure out something better.
Re #4499.
This reverts commit 9f05e88a1732c9b6ed46a995a3f0e11781759d83.

Comment 23 by jteh on 2015-07-16 03:42
I give up for now. :(
Changes:
Removed labels: incubating

Comment 24 by dkager on 2015-07-31 10:43
Saw this ticket in the changelog for master and am thinking it shouldn't be.

Comment 25 by jteh on 2015-07-31 11:06
If you mean the What's New document, I don't see this. It was there, but i reverted it in b6a4273.

Comment 26 by dkager (in reply to comment 25) on 2015-07-31 16:55
Replying to jteh:

If you mean the What's New document, I don't see this. It was there, but i reverted it in b6a4273.

Yeah, turns out my pretty HTML userdocs weren't in sync for some reason. Oops.

@michaelDCurran's #4499 (reference) and @jcsteh's #4499 (reference) include commits. Are they indicators of further progress on this ticket, or has all of Jamie's earlier work been reverted due to problems? Also, should we give up in case of this ticket and close as cantfix, or do @LeonarddeR, @derekriemer, @josephsl, @dkager and others have further thoughts/inputs? If implementation cost is too high for what this ticket's worth, we may wish to mark as a P4.

I think this is fixed, but we need @jcsteh or @michaelDCurran to confirm.

No. The fix for this was reverted in 171a430, since it didn't actually work. Setting as p4, since this affects few users, has a work around (disable Handle keys from other applications) and appears to be very difficult to even diagnose.

just to be sure, @AndrewD are you still having this issue with the last NVDA version?

I use the latest NVDA version in 22.4, which prevents any of text expansion apps. I tried espanso, text-expander, when triggering the text replacement under the NVDA, it just replaces the abbreviation into space rather than the correct replaced text.