Some output in command consoels spelled with speak typed characters enabled

[nvaccessAuto]

Reported by aleksey_s on 2009-12-17 16:39
Sometimes, NVDA is too verbose in console windows.
STR:

• open cmd
• run python interpreter
• type: print "hi"
  Currently, NVDA says
  h
  i
  hi
  It starts reading by letter and only then reads the entire message. This behaviour also exists in other console apps.
  Blocked by no key echo in some console windows #5027
  Blocking NVDA starts to read console output from some programs by character and becomes very unresponsive #2977, NVDA spells output from terminal windows #4127, Hi when using the commandline in windows I get mest up speach. #5328

[nvaccessAuto]

Comment 1 by aleksey_s on 2009-12-17 16:44
A simple script to demonstrate a bug:
s=raw_input("enter string: ")
print "you entered ",s
print "press enter to exit"
raw_input()

[nvaccessAuto]

Comment 2 by mdcurran on 2009-12-17 20:42
Sorry, could you please provide a little more information.

• What happens for you exactly?
• I assume that I save that code in a .py file and run it in a Windows CMD shell?

[nvaccessAuto]

Comment 3 by mdcurran on 2009-12-17 20:48
I apologize. I missed your first description. Sorry its very early morning.

Yes, I also get this problem quite a bit. However, only if Speak Typed characters is enabled.

I'm not sure how to fix it yet, but I can explain why it happens.

In XP and Vista, we are not aloud to hook window messages in dos consoles. So therefore we can not detect wm_char messages, and therefore not announce typed characters the normal way.
So, we detect, as part of our console diff code, when a single character seems to appear, in relation to where the caret is, and then we assume its a typed character and pass it through to speakTypedCharacters.
This happens quite a bit too often so it seems.
We need to stop doing this. However, what to replace it with?

[nvaccessAuto]

Comment 5 by jteh on 2014-05-07 19:21
We should be able to fix this for Windows 7 and later, since we get WM_CHAR there. We can't fix it this way for XP or Vista, but I don't see why we should disadvantage 7 and later because of a deficiency in earlier Windows versions.

[nvaccessAuto]

Comment 7 by jteh on 2014-05-07 19:23
Changes:
Changed title from "Incorrect console reading" to "Some output in command consoels spelled with speak typed characters enabled"

[nvaccessAuto]

Comment 8 by briang1 on 2014-05-07 20:00
Well, in XP I've never encountered this issue. I do have speak typed characters on as well. Under what conditions does it manifest itself?

[nvaccessAuto]

Comment 9 by jteh on 2014-09-09 07:44
Mick pointed out that WM_CHAR is problematic for password entry. We don't want the user's password to be echoed.

[nvaccessAuto]

Comment 11 by Michael Curran <mick@... on 2015-04-02 04:39
In [a0d15ab]:

Merge branch 't513' into next. Incubates #513

Changes:
Added labels: incubating

[nvaccessAuto]

Comment 12 by Michael Curran <mick@... on 2015-04-06 03:24
In [091a0e4]:

Merge branch 't513' into next. Incubates #513

[nvaccessAuto]

Comment 14 by jteh on 2015-05-01 12:26
It seems that some applications such as Cygwin disable the console's native key echo and use their own (#5027). One possibility is that when we handle a typedCharacter event (WM_CHAR), we could check whether the character typed is the same as the character just before the caret. If it is, we can assume key echo is enabled.

[nvaccessAuto]

Comment 15 by James Teh <jamie@... on 2015-07-15 07:41
In [c8a721b]:

Revert "Windows command consoles: support wm_char for announcing typed characters if it is available, and disable our older character handling code in win7 and above (wm_char is better). Also don't allow announcing of characters if the console's input echo mode is not on (e.g. password entry)."

It looks like Cygwin and probably other apps disable the console's native key echo and manage key echo themselves, so key echo stops working in those apps with this implementation. We'll need to rethink this approach, but it's better to revert it completely until someone has time.
This reverts commits daf65862f53f57aec99b115cc2ad4eb54dcf37d7 and 115be898d170b6461b92970239465607a9d2a6aa.
Fixes #5027. Re #513.

[nvaccessAuto]

Comment 16 by jteh on 2015-07-15 07:42
Changes:
Removed labels: incubating

[Adriani90]

I cannot reproduce this with NVDA 2018.2.1 on Windows 10.

[Adriani90]

@aleksey_s is this still an issue for you?

[Brian1Gaff]

It can happen with wsome command line programs outputs still but not as much as it used to, at least in windows 7 command prompt it can. Brian

[LeonarddeR]

I've seen it happening with Windows 10 as well

[codeofdusk]

Once #9771 is merged, this issue will be resolved on Windows 10 version 1803 and later due to the new typedCharacter implementation for UIA consoles. However, it is still not fixed on Windows Server and LTSC 2016 (Windows 10 1607), which will still be supported for many years to come. I've considered using keyboardHandler for legacy consoles (similar to UIA), but it is unsupported on 1607. I've also considered using NVDAHelper to receive wm_char messages, but they are unreliable (characters are sometimes doubled). Therefore, it seems that we cannot fix this bug on older Windows releases. Since the issue has either been resolved or resolution is impossible, I vote to close it. You are, of course, welcome to investigate further for legacy consoles and propose a solution if one exists!

[Adriani90]

What about People working on Windows 8.1 and Windows 7 in Consoles not using UIA?

[codeofdusk]

What about People working on Windows 8.1 and Windows 7 in Consoles not using UIA?

The above comment is outdated, see #9915. This is fixed on a few Windows versions without UIA, but any more isn't possible due to doubled wm_char messages.