Date   

NVDA 2019.3 and community add-ons: slowly making progress

 

Hi all,

 

Another update on community add-ons and their readiness for NVDA 2019.3/2019.3.1:

 

Out of 70 add-ons hosted on community add-ons website:

 

  • Compatible: 54
  • Work in progress: 3
  • Planned: 1
  • Included in NVDA: 2
  • Incompatible: 10

 

Some add-ons require manifest edits, some will require more extensive edits, and one or two will take a long time to get them compatible.

Cheers,

Joseph


Re: make UIA object focusable and to a button #3030-advice

Christopher Pross
 

Hey Guys,
I had asked this for a while. Nobody has answered me, if the question is very stupid or I'm wrong here, sorry for that. But I didn't know that.
I have to know, whether this is a bug or this is a failure from my code.
If you need more information, ask here in the group or if it is to many, we can discus this private.

regards,
chriss


Issue using Outlook calendar, reported by spanish user

Noelia Ruiz
 

Hello:

A user from spanish community reports this on a mailing list for NVDA.
Here is part of the log. Should we open an issue? Maybe something
related to his system. What could be do to use Outlook Calendar?
Please feel free to request any information needed to identify this
problem to help this person.
Thanks

NVDA 2019.3 installed without add-ons, using OneCore:

NVDA version: 2019.3 without add-ons
Using Windows version 10.0.17763 workstation
...
Speaking ['Outlook', '13 de 26']
DEBUG - synthDrivers.oneCore.SynthDriver._callback (10:54:08.741) -
Dummy-1 (12480):
Done pushing audio
DEBUG - synthDrivers.oneCore.SynthDriver._processQueue (10:54:08.741)
- Dummy-1 (12480):
Calling idle on audio player
DEBUG - synthDrivers.oneCore.SynthDriver._processQueue (10:54:08.871)
- Dummy-1 (12480):
Begin processing speech
DEBUG - synthDrivers.oneCore.SynthDriver._callback (10:54:09.822) -
Dummy-1 (12480):
Done pushing audio
DEBUG - synthDrivers.oneCore.SynthDriver._processQueue (10:54:09.822)
- Dummy-1 (12480):
Calling idle on audio player
IO - inputCore.InputManager.executeGesture (10:54:09.871) -
winInputHook (13096):
Input: kb(desktop):enter
DEBUG - synthDrivers.oneCore.SynthDriver.cancel (10:54:09.891) -
MainThread (6540):
Cancelling
DEBUG - synthDrivers.oneCore.SynthDriver._processQueue (10:54:09.902)
- Dummy-1 (12480):
Queue empty, done processing
DEBUGWARNING - watchdog._watcher (10:54:10.730) - watchdog (10660):
Trying to recover from freeze, core stack:
File "nvda.pyw", line 215, in <module>
File "core.pyc", line 545, in main
File "wx\core.pyc", line 2134, in MainLoop
File "gui\__init__.pyc", line 1030, in Notify
File "core.pyc", line 514, in run
File "IAccessibleHandler.pyc", line 898, in pumpAll
File "IAccessibleHandler.pyc", line 772, in processForegroundWinEvent
File "IAccessibleHandler.pyc", line 539, in winEventToNVDAEvent
File "NVDAObjects\IAccessible\__init__.pyc", line 48, in
getNVDAObjectFromEvent
File "NVDAObjects\__init__.pyc", line 86, in __call__
File "NVDAObjects\IAccessible\__init__.pyc", line 426, in findOverlayClasses
File "baseObject.pyc", line 42, in __get__
File "baseObject.pyc", line 145, in _getPropertyViaCache
File "NVDAObjects\IAccessible\__init__.pyc", line 834, in _get_IAccessibleRole
File "comtypes\__init__.pyc", line 857, in __call__
File "comtypesMonkeyPatches.pyc", line 26, in __call__

DEBUGWARNING - core.CorePump.run (10:54:10.730) - MainThread (6540):
errors in this core pump cycle
Traceback (most recent call last):
File "core.pyc", line 514, in run
File "IAccessibleHandler.pyc", line 898, in pumpAll
File "IAccessibleHandler.pyc", line 772, in processForegroundWinEvent
File "IAccessibleHandler.pyc", line 539, in winEventToNVDAEvent
File "NVDAObjects\IAccessible\__init__.pyc", line 48, in
getNVDAObjectFromEvent
File "NVDAObjects\__init__.pyc", line 86, in __call__
File "NVDAObjects\IAccessible\__init__.pyc", line 426, in findOverlayClasses
File "baseObject.pyc", line 42, in __get__
File "baseObject.pyc", line 145, in _getPropertyViaCache
File "NVDAObjects\IAccessible\__init__.pyc", line 834, in _get_IAccessibleRole
File "comtypes\__init__.pyc", line 857, in __call__
File "comtypesMonkeyPatches.pyc", line 34, in __call__
core.CallCancelled: COM call cancelled
DEBUGWARNING - watchdog._watcher (10:54:11.300) - watchdog (10660):
Trying to recover from freeze, core stack:
File "nvda.pyw", line 215, in <module>
File "core.pyc", line 545, in main
File "wx\core.pyc", line 2134, in MainLoop
File "gui\__init__.pyc", line 1030, in Notify
File "core.pyc", line 514, in run
File "IAccessibleHandler.pyc", line 898, in pumpAll
File "IAccessibleHandler.pyc", line 672, in processFocusWinEvent
File "IAccessibleHandler.pyc", line 539, in winEventToNVDAEvent
File "NVDAObjects\IAccessible\__init__.pyc", line 42, in
getNVDAObjectFromEvent
File "IAccessibleHandler.pyc", line 347, in accessibleObjectFromEvent
File "oleacc.pyc", line 265, in AccessibleObjectFromEvent

DEBUG - IAccessibleHandler.accessibleObjectFromEvent (10:54:11.347) -
MainThread (6540):
oleacc.AccessibleObjectFromEvent with window 263810, objectID 6 and
childID 0: [WinError -2147467259] Error no especificado
IO - speech.speak (10:54:11.989) - MainThread (6540):
...


Re: NVDA 2019.3 now released

Brian's Mail list account
 

Yes I've been using the RC for over a week now and its more stable than the old stable was. Admittedly some add ons have had to be lost or tweaked, but generally it seems better.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Reef Turner" <reef@...>
To: <nvda-devel@groups.io>
Sent: Monday, February 10, 2020 11:37 AM
Subject: [nvda-devel] NVDA 2019.3 now released


Hello everyone,

NVDA 2019.3 stable has just been released. See the full post at: https://www.nvaccess.org/post/nvda-2019-3-released/

Thank you for all your contributions. The community is what makes NVDA what it is.

Reef (NV Access)


Re: NVDA crashes if non-ASCII characters are in the path

Reef Turner
 

Yes, that is essentially what happens already. However, in this particular case espeak calls exit() which instructs the OS to end the process. There are various ways we might get around that, but not on a short enough timeline for this release. My suggestion was a temporary work-around, a preventative measure to detect this known error condition before even loading espeak, and load a different synthesizer instead.

-----Original Message-----
From: nvda-devel@groups.io On Behalf Of Marlon Brandão de Sousa
Sent: Saturday, 8 February 2020 12:09 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] NVDA crashes if non-ASCII characters are in the path

Reef,


Shouldn't this be a standard behavior in any case? On startup, if for whatever reason (not only for this specific case, but for all cases), if something goes wrong trying to use a synthesizer, then all other available ones should be tried in sequence until one of them works and, if all of them fail, a recorded message should be played stating that NVDA can't use the installed synthesizers?


This would make the screen reader very resilient because failing to use a synthesizer is one of the conditions that let users in a very vulnerable situation.


Not asking you to do anything now, just checking if this thought makes sense.



On 06/02/2020 07:06, Reef Turner wrote:
One possible work-around (that I don't like very much) would be to detect the crash conditions on start up (espeak synth, path with non-ASCII), warn the user and set a different synth.

-----Original Message-----
From: nvda-devel@groups.io On Behalf Of Nikita
Sent: Wednesday, 5 February 2020 7:38 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] NVDA crashes if non-ASCII characters are in the path

Unfortunately, this is a rather serious problem, the danger of which is probably underestimated.
Because of this problem, it is impossible to run new NVDA if the path to unpacked version contains non-ASCII characters.
As a result, inexperienced users may not understand why the new NVDA portable does not start.
There are Non-ASCII characters in languages based on the Latin alphabet, for example, French, German, Spanish. The so-called diacritics.
It is also bad that the log of NVDA does not contain any errors. NVDA crashes before it has time to write something.
This is an old bug that manifested even in Python 2 versions. That is not a problem of Python 3 migration.

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Brian's Mail list account via Groups.Io
Sent: Wednesday, February 05, 2020 8:54 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] NVDA crashes if non-ASCII characters are in the path

I wonder how many people this might affect? If somebody likes espeak, one supposes this will be people who use other languages than the Latin based ones with this synth. I could not see the issue on the Espeak mail list, so suspect its been around for a while. Could an older version be used to temporarily fix this as it might make some people not want to switch, assuming of course the problem is not already in the current stable python 2. I'd not know.

Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "Reef Turner" <reef@...>
To: <nvda-devel@groups.io>
Sent: Wednesday, February 05, 2020 9:10 AM
Subject: Re: [nvda-devel] NVDA crashes if non-ASCII characters are in the
path


Hi Nikita,

Thanks for pointing this out. It is a known issue [1]. We are confident this
is caused by an issue in espeak and there is little we can do about it in
the short term. We hope that the espeak maintainers will fix this issue, but
unfortunately it is too late for a fix to be included in 2019.3.

[1] https://github.com/nvaccess/nvda/issues/10607















NVDA 2019.3 now released

Reef Turner
 

Hello everyone,

NVDA 2019.3 stable has just been released. See the full post at: https://www.nvaccess.org/post/nvda-2019-3-released/


Thank you for all your contributions. The community is what makes NVDA what it is.

Reef (NV Access)


Re: NVDA crashes if non-ASCII characters are in the path

Marlon Brandão de Sousa
 

Reef,


Shouldn't this be a standard behavior in any case? On startup, if for whatever reason (not only for this specific case, but for all cases), if something goes wrong trying to use a synthesizer, then all other available ones should be tried in sequence until one of them works and, if all of them fail, a recorded message should be played stating that NVDA can't use the installed synthesizers?


This would make the screen reader very resilient because failing to use a synthesizer is one of the conditions that let users in a very vulnerable situation.


Not asking you to do anything now, just checking if this thought makes sense.

On 06/02/2020 07:06, Reef Turner wrote:
One possible work-around (that I don't like very much) would be to detect the crash conditions on start up (espeak synth, path with non-ASCII), warn the user and set a different synth.

-----Original Message-----
From: nvda-devel@groups.io On Behalf Of Nikita
Sent: Wednesday, 5 February 2020 7:38 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] NVDA crashes if non-ASCII characters are in the path

Unfortunately, this is a rather serious problem, the danger of which is probably underestimated.
Because of this problem, it is impossible to run new NVDA if the path to unpacked version contains non-ASCII characters.
As a result, inexperienced users may not understand why the new NVDA portable does not start.
There are Non-ASCII characters in languages based on the Latin alphabet, for example, French, German, Spanish. The so-called diacritics.
It is also bad that the log of NVDA does not contain any errors. NVDA crashes before it has time to write something.
This is an old bug that manifested even in Python 2 versions. That is not a problem of Python 3 migration.

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Brian's Mail list account via Groups.Io
Sent: Wednesday, February 05, 2020 8:54 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] NVDA crashes if non-ASCII characters are in the path

I wonder how many people this might affect? If somebody likes espeak, one supposes this will be people who use other languages than the Latin based ones with this synth. I could not see the issue on the Espeak mail list, so suspect its been around for a while. Could an older version be used to temporarily fix this as it might make some people not want to switch, assuming of course the problem is not already in the current stable python 2. I'd not know.

Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "Reef Turner" <reef@...>
To: <nvda-devel@groups.io>
Sent: Wednesday, February 05, 2020 9:10 AM
Subject: Re: [nvda-devel] NVDA crashes if non-ASCII characters are in the
path


Hi Nikita,

Thanks for pointing this out. It is a known issue [1]. We are confident this
is caused by an issue in espeak and there is little we can do about it in
the short term. We hope that the espeak maintainers will fix this issue, but
unfortunately it is too late for a fix to be included in 2019.3.

[1] https://github.com/nvaccess/nvda/issues/10607














Re: problems opening the task manager

Noelia Ruiz
 

In case this is useful, here the problem not always persist. Maybe
useful info provided by NVDA+f1?
I have got isCocusable True and False in different presses of the
keystroke. Now:

Developer info for navigator object:
name: 'Lista de elementos'
role: ROLE_DATAGRID
roleText: None
states: STATE_FOCUSABLE, STATE_FOCUSED, STATE_READONLY
isFocusable: True
hasFocus: True
Python object: <NVDAObjects.UIA.UIA object at 0x07054A30>
Python class mro: (<class 'NVDAObjects.UIA.UIA'>, <class
'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class
'documentBase.TextContainerObject'>, <class
'baseObject.ScriptableObject'>, <class
'baseObject.AutoPropertyObject'>, <class 'object'>)
description: ''
location: RectLTWH(left=35, top=159, width=663, height=410)
value: ''
appModule: <'taskmgr' (appName 'taskmgr', process ID 8396) at address 680b390>
appModule.productName: 'Sistema Operativo Microsoft® Windows®'
appModule.productVersion: '10.0.17763.802'
TextInfo: <class 'NVDAObjects.NVDAObjectTextInfo'>
windowHandle: 3605710
windowClassName: 'DirectUIHWND'
windowControlID: 0
windowStyle: 1442840576
extendedWindowStyle: 0
windowThreadID: 6304
windowText: ''
displayText: 'Aplicaciones (2)Firefox (3) 0% 274,9 MB 0 MB/s 0 Mbps
MAdministrador de tareas 44,8% 21,5 MB 0 MB/s 0 Mbps AlProcesos en
segundo plano (51)Aislamiento de gráficos de disp... 0% 8,2 MB 0 MB/s
0 Mbps MAntimalware Service Executable 0,3% 57,2 MB 0 MB/s '
(truncated)
UIAElement: <POINTER(IUIAutomationElement) ptr=0x58eb7a8 at 52d0260>
UIA automationID: ScrollViewer
UIA frameworkID: DirectUI
UIA runtimeID: (8396, 1812311296, 343)
UIA providerDescription: [pid:8396,providerId:0x0 Main(parent
link):Unidentified Provider (unmanaged:Taskmgr.exe)]
UIA className: TmScrollViewer
UIA patterns available: ValuePattern, ScrollPattern,
LegacyIAccessiblePattern, GridPattern, SelectionPattern, TablePattern


2020-02-06 23:47 GMT+01:00, ChrisLM <@Christianlm>:

Hi Cyrille, I did my tests without any addons installed, the problem
persists.

thanks,



Chris.

Cyrille via Groups.Io ha scritto il 06/02/2020 alle 23:36:
At home with 2019.3rc3, disabling ColumnReview add-on fixes this issue.




Re: problems opening the task manager

ChrisLM
 

Hi Cyrille, I did my tests without any addons installed, the problem persists.

thanks,



Chris.

Cyrille via Groups.Io ha scritto il 06/02/2020 alle 23:36:

At home with 2019.3rc3, disabling ColumnReview add-on fixes this issue.


Re: problems opening the task manager

Cyrille
 

Hello

At home with 2019.3rc3, disabling ColumnReview add-on fixes this issue.

Cheers,

Cyrille

-----Message d'origine-----
De : nvda-devel@groups.io <nvda-devel@groups.io> De la part de ChrisLM
Envoyé : jeudi 6 février 2020 23:26
À : nvda-devel@groups.io
Objet : Re: [nvda-devel] problems opening the task manager

Hi,

I'm trying to understand more its behavior.
In practice, after open the task manager and press down arrow the speech synthesis stops speaking. All screen reader commands do not work, and often NVDA needs to be restarted.
When I press ctrl+TAB to switch tabs NVDA announces unknown, sometimes NVDA says nothing.
I'm testing the latest alpha versions and running NVDA from source, on Windows 10Ver1909 (64-bit) build 18363.592.

Cheers,


Chris.

James Scholes ha scritto il 06/02/2020 alle 22:22:
...the purpose of this thread isn't really clear. @ChrisLM, could you
expand on the problems you're experiencing with the Task Manager, or
opening it, or whatever specific area of functionality isn't working?
I've just pressed Ctrl+Shift+Escape, the Task Manager opened, so what
next?


Re: problems opening the task manager

ChrisLM
 

Hi,

I'm trying to understand more its behavior.
In practice, after open the task manager and press down arrow the speech synthesis stops speaking. All screen reader commands do not work, and often  NVDA needs to be restarted.
When I press ctrl+TAB to switch tabs NVDA announces unknown, sometimes NVDA says nothing.
I'm testing the latest alpha versions and running NVDA from source,
on Windows 10Ver1909 (64-bit) build 18363.592.

Cheers,


Chris.

James Scholes ha scritto il 06/02/2020 alle 22:22:

...the purpose of this thread isn't really clear. @ChrisLM, could you expand on the problems you're experiencing with the Task Manager, or opening it, or whatever specific area of functionality isn't working?  I've just pressed Ctrl+Shift+Escape, the Task Manager opened, so what next?


Re: problems opening the task manager

James Scholes
 

The task manager in Windows 10 is completely different to the one in Windows 7. It has some significant problems, and many people would probably say it was worse than the previous incarnation (myself included).

With that said, though, the purpose of this thread isn't really clear. @ChrisLM, could you expand on the problems you're experiencing with the Task Manager, or opening it, or whatever specific area of functionality isn't working? I've just pressed Ctrl+Shift+Escape, the Task Manager opened, so what next?

@Noelia, the Task Manager isn't written in Java, so I'm not sure what any Java issues have to do with it.

Regards,

James Scholes

On 06/02/2020 at 2:37 pm, Brian's Mail list account via Groups.Io wrote:
How come it works so well in Windows 7, though?
Brian
bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message ----- From: "Noelia Ruiz" <nrm1977@...>
To: <nvda-devel@groups.io>
Sent: Thursday, February 06, 2020 3:20 AM
Subject: Re: [nvda-devel] problems opening the task manager
Hi, me too. Maybe related to recent Java support?
This is listened and shown in speech viewer:
C:\Program Files\Java\jre1.8.0_211\bin\jabswitch.exe  terminal
The Java Access Bridge has been
If you run source master, not an installed copy, though Java support
is not enabled from NVDA itself, maybe affected by a previous try if
you didn't restart the computer?
David is mentioning some previous issues, but I think this can be different.
Also, years ago NV Access worked on performance issues also related to
task viewer:
https://github.com/nvaccess/nvda/issues/5293
https://github.com/nvaccess/nvda/commit/020e3f63349357f06ac1bf7f1c62ac4dd66e99d1 Hope this helps
2020-02-05 23:40 GMT+01:00, ChrisLM <@Christianlm>:
Hi,

before open a issue, can someone else try to open the windows task
manager with control+shift+escape, or run taskmgr?

I have encountered serious problems in the task manager dialog using
last NVDA rc3, last alpha and running the source master...


cheers,



--
Chris.





Re: problems opening the task manager

Brian's Mail list account
 

How come it works so well in Windows 7, though?
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Noelia Ruiz" <nrm1977@...>
To: <nvda-devel@groups.io>
Sent: Thursday, February 06, 2020 3:20 AM
Subject: Re: [nvda-devel] problems opening the task manager


Hi, me too. Maybe related to recent Java support?
This is listened and shown in speech viewer:
C:\Program Files\Java\jre1.8.0_211\bin\jabswitch.exe terminal
The Java Access Bridge has been

If you run source master, not an installed copy, though Java support
is not enabled from NVDA itself, maybe affected by a previous try if
you didn't restart the computer?
David is mentioning some previous issues, but I think this can be different.
Also, years ago NV Access worked on performance issues also related to
task viewer:

https://github.com/nvaccess/nvda/issues/5293
https://github.com/nvaccess/nvda/commit/020e3f63349357f06ac1bf7f1c62ac4dd66e99d1

Hope this helps


2020-02-05 23:40 GMT+01:00, ChrisLM <@Christianlm>:
Hi,

before open a issue, can someone else try to open the windows task
manager with control+shift+escape, or run taskmgr?

I have encountered serious problems in the task manager dialog using
last NVDA rc3, last alpha and running the source master...


cheers,



--
Chris.





make UIA object focusable and to a button #3030-advice

Christopher Pross
 

Hey guys,
at the moment I have a problem with some add-on code.
I have a element, wich is type "unknown", it is in fact a button, but also it isn't focusable.
The problem is, that I can't change the type or make it focusable. I don't know why, maybe I do somethink wrong?

First of all, the devInfo:

["name: ''", 'role: ROLE_UNKNOWN', 'roleText: None', 'states: ', 'isFocusable: False', 'hasFocus: False', 'Python object: <NVDAObjects.UIA.UIA object at 0x03D6B5F0>', "Python class mro: (<class 'NVDAObjects.UIA.UIA'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <class 'object'>)", "description: ''", 'location: RectLTWH(left=730, top=133, width=15, height=15)', 'value: None', "appModule: <'nordvpn' (appName 'nordvpn', process ID 11136) at address 758ae30>", "appModule.productName: 'NordVPN'", "appModule.productVersion: '6.26.15.0'", "TextInfo: <class 'NVDAObjects.NVDAObjectTextInfo'>", 'windowHandle: 66774', "windowClassName: 'HwndWrapper[NordVPN.exe;;39c90ffe-7554-4757-a831-d0403c1908a7]'", 'windowControlID: 0', 'windowStyle: 382664704', 'extendedWindowStyle: 262400', 'windowThreadID: 11140', "windowText: 'NordVPN '", "displayText: ''", 'UIAElement: <POINTER(IUIAutomationElement) ptr=0x81a3a20 at d9cacb0>', 'UIA automationID: Sign', 'UIA frameworkID: WPF', 'UIA runtimeID: (7, 11136, 9930698)', 'UIA providerDescription: [pid:11136,providerId:0x0 Main(parent link):Unidentified Provider (managed:MS.Internal.Automation.ElementProxy, PresentationCore, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35)]', 'UIA className: CloseSign', 'UIA patterns available: LegacyIAccessiblePattern, SynchronizedInputPattern']

My add-on code was active in this case already..
In the event_NVDAObject_init, in some if-statements, I have this code:

ch.role = controlTypes.ROLE_BUTTON
ch.states.add(controlTypes.STATE_FOCUSABLE)
ch.isFocusable = True

In the protocol of nvda, is no traceback or exception, no warning or somethink else.
I don't know, why this element don't change his type and the state.
If I try to force to set the focus, I get a traceback, but I think because it isn't focuable:

>>> nav.next.setFocus() Traceback (most recent call last): File "<console>", line 1, in <module> File "NVDAObjects\UIA\__init__.pyc", line 1094, in setFocus File "comtypesMonkeyPatches.pyc", line 26, in __call__ _ctypes.COMError: (-2146233079, None, (None, None, None, 0, None))

Maybe you know what is wrong here?

all the best,
Christopher


Re: Where is CapsLock management?

Alberto Buffolino
 

Noelia Ruiz, il 06/02/2020 12.31, ha scritto:
Hi, I think you may look at keyboardHandler.py in different functions
including internal_keyDownEvent, internal_keyUpEvent and
_reportToggleKey, since there are things that maybe common to other
modifiers, not just capsLoc.
Alberto:
Yeah, found. Thanks Noelia, I forgot the other toggle keys, so I have no results in search previously.
Alberto


Re: Where is CapsLock management?

Noelia Ruiz
 

Hi, I think you may look at keyboardHandler.py in different functions
including internal_keyDownEvent, internal_keyUpEvent and
_reportToggleKey, since there are things that maybe common to other
modifiers, not just capsLoc.
Also you can use git grep -i -n capslock or toggle, etc, for a wider
context and get an idea about where to search.
Cheers

2020-02-06 9:41 GMT+01:00, Alberto Buffolino <a.buffolino@...>:

Hi,
I'm talking about NVDA sources and capsLock status management.
I'm quite sure to have seen it years ago, but I cannot find it today.
Where is it?
Thanks.
Alberto




Re: NVDA crashes if non-ASCII characters are in the path

zvonimir stanečić, 9a5dsz
 

Btw, can you merge all translations from beta to master?
Rc3 has no problems with them

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Reef Turner
Sent: Thursday, February 6, 2020 11:07 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] NVDA crashes if non-ASCII characters are in the path

One possible work-around (that I don't like very much) would be to detect the crash conditions on start up (espeak synth, path with non-ASCII), warn the user and set a different synth.

-----Original Message-----
From: nvda-devel@groups.io On Behalf Of Nikita
Sent: Wednesday, 5 February 2020 7:38 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] NVDA crashes if non-ASCII characters are in the path

Unfortunately, this is a rather serious problem, the danger of which is probably underestimated.
Because of this problem, it is impossible to run new NVDA if the path to unpacked version contains non-ASCII characters.
As a result, inexperienced users may not understand why the new NVDA portable does not start.
There are Non-ASCII characters in languages based on the Latin alphabet, for example, French, German, Spanish. The so-called diacritics.
It is also bad that the log of NVDA does not contain any errors. NVDA crashes before it has time to write something.
This is an old bug that manifested even in Python 2 versions. That is not a problem of Python 3 migration.

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Brian's Mail list account via Groups.Io
Sent: Wednesday, February 05, 2020 8:54 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] NVDA crashes if non-ASCII characters are in the path

I wonder how many people this might affect? If somebody likes espeak, one supposes this will be people who use other languages than the Latin based ones with this synth. I could not see the issue on the Espeak mail list, so suspect its been around for a while. Could an older version be used to temporarily fix this as it might make some people not want to switch, assuming of course the problem is not already in the current stable python 2. I'd not know.

Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "Reef Turner" <reef@...>
To: <nvda-devel@groups.io>
Sent: Wednesday, February 05, 2020 9:10 AM
Subject: Re: [nvda-devel] NVDA crashes if non-ASCII characters are in the path


Hi Nikita,

Thanks for pointing this out. It is a known issue [1]. We are confident this is caused by an issue in espeak and there is little we can do about it in the short term. We hope that the espeak maintainers will fix this issue, but unfortunately it is too late for a fix to be included in 2019.3.

[1] https://github.com/nvaccess/nvda/issues/10607


Re: NVDA crashes if non-ASCII characters are in the path

zvonimir stanečić, 9a5dsz
 

No, the second possible solution is to use original non modified espeak (last version from Jonathan Duddington.
The developer of espeak NG only uses Linux and all things are getting only worse.
As a workaround, I would like to try the oldest version possible, as it can also affect the user account paths that are written with accented characters or in other script.The problem is in espeak NG, but not on other synths like codefactory vocalizer or acapela.

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Reef Turner
Sent: Thursday, February 6, 2020 11:07 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] NVDA crashes if non-ASCII characters are in the path

One possible work-around (that I don't like very much) would be to detect the crash conditions on start up (espeak synth, path with non-ASCII), warn the user and set a different synth.

-----Original Message-----
From: nvda-devel@groups.io On Behalf Of Nikita
Sent: Wednesday, 5 February 2020 7:38 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] NVDA crashes if non-ASCII characters are in the path

Unfortunately, this is a rather serious problem, the danger of which is probably underestimated.
Because of this problem, it is impossible to run new NVDA if the path to unpacked version contains non-ASCII characters.
As a result, inexperienced users may not understand why the new NVDA portable does not start.
There are Non-ASCII characters in languages based on the Latin alphabet, for example, French, German, Spanish. The so-called diacritics.
It is also bad that the log of NVDA does not contain any errors. NVDA crashes before it has time to write something.
This is an old bug that manifested even in Python 2 versions. That is not a problem of Python 3 migration.

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Brian's Mail list account via Groups.Io
Sent: Wednesday, February 05, 2020 8:54 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] NVDA crashes if non-ASCII characters are in the path

I wonder how many people this might affect? If somebody likes espeak, one supposes this will be people who use other languages than the Latin based ones with this synth. I could not see the issue on the Espeak mail list, so suspect its been around for a while. Could an older version be used to temporarily fix this as it might make some people not want to switch, assuming of course the problem is not already in the current stable python 2. I'd not know.

Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "Reef Turner" <reef@...>
To: <nvda-devel@groups.io>
Sent: Wednesday, February 05, 2020 9:10 AM
Subject: Re: [nvda-devel] NVDA crashes if non-ASCII characters are in the path


Hi Nikita,

Thanks for pointing this out. It is a known issue [1]. We are confident this is caused by an issue in espeak and there is little we can do about it in the short term. We hope that the espeak maintainers will fix this issue, but unfortunately it is too late for a fix to be included in 2019.3.

[1] https://github.com/nvaccess/nvda/issues/10607


Re: NVDA crashes if non-ASCII characters are in the path

Reef Turner
 

One possible work-around (that I don't like very much) would be to detect the crash conditions on start up (espeak synth, path with non-ASCII), warn the user and set a different synth.

-----Original Message-----
From: nvda-devel@groups.io On Behalf Of Nikita
Sent: Wednesday, 5 February 2020 7:38 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] NVDA crashes if non-ASCII characters are in the path

Unfortunately, this is a rather serious problem, the danger of which is probably underestimated.
Because of this problem, it is impossible to run new NVDA if the path to unpacked version contains non-ASCII characters.
As a result, inexperienced users may not understand why the new NVDA portable does not start.
There are Non-ASCII characters in languages based on the Latin alphabet, for example, French, German, Spanish. The so-called diacritics.
It is also bad that the log of NVDA does not contain any errors. NVDA crashes before it has time to write something.
This is an old bug that manifested even in Python 2 versions. That is not a problem of Python 3 migration.

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Brian's Mail list account via Groups.Io
Sent: Wednesday, February 05, 2020 8:54 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] NVDA crashes if non-ASCII characters are in the path

I wonder how many people this might affect? If somebody likes espeak, one supposes this will be people who use other languages than the Latin based ones with this synth. I could not see the issue on the Espeak mail list, so suspect its been around for a while. Could an older version be used to temporarily fix this as it might make some people not want to switch, assuming of course the problem is not already in the current stable python 2. I'd not know.

Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "Reef Turner" <reef@...>
To: <nvda-devel@groups.io>
Sent: Wednesday, February 05, 2020 9:10 AM
Subject: Re: [nvda-devel] NVDA crashes if non-ASCII characters are in the
path


Hi Nikita,

Thanks for pointing this out. It is a known issue [1]. We are confident this
is caused by an issue in espeak and there is little we can do about it in
the short term. We hope that the espeak maintainers will fix this issue, but
unfortunately it is too late for a fix to be included in 2019.3.

[1] https://github.com/nvaccess/nvda/issues/10607


Where is CapsLock management?

Alberto Buffolino
 

Hi,
I'm talking about NVDA sources and capsLock status management.
I'm quite sure to have seen it years ago, but I cannot find it today.
Where is it?
Thanks.
Alberto