Date   
Re: Important: if your development work targets 2020.1, please use Visual Studio 2019 to compile NVDA

Brian's Mail list account
 

Has the resulting code been tested on Windows 7 etc?
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: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Monday, February 17, 2020 4:43 AM
Subject: [nvda-devel] Important: if your development work targets 2020.1, please use Visual Studio 2019 to compile NVDA


Hi all,



Last week, NVDA source code was updated to require Visual Studio 2019. If
you are planning to send pull requests targeting NVDA 2020.1 (or later), you
must use Visual Studio 2019 (16.2 or later) and several additional
components to compile NVDA locally (and please, please, PLEASE perform lint
checks locally BEFORE sending your commits to NV Access so your PR log won't
get filled with all sorts of linting messages).



In case you are migrating from Visual Studio 2017 to 2019, do:



1. Uninstall Visual studio 2017.
2. Install Visual Studio 2019 (16.2) or later - any edition will do.
3. As part of VS2019 install, you must install Visual C++ tools for
x86/x64 and ARM64, Clang tools (9.0.0) required to build Liblouis, and ATL
tools for x86/x64 and ARM64 for Windows 10 components. Along with these, you
should install Windows 10 SDK version 10.0.18362 (May/November 2019 Update
release).



For people doing a git pull on NVDA master branch, you MUST do git submodule
update to update submodule commits.

Cheers,

Joseph



Add-on Updater will require NVDA 2019.3 starting March 10, 2020, a speicla change fro alpha snapshot users

 

Hi all,

 

A few weeks ago I announced to the NVDA community that Add-on Updater will be the last add-on from me to require NVDA 2019.3. This decision was made in consideration for people who may need to use 2019.2.1 and earlier a little longer.

 

But the countdown has begun: after March 10, 2020 (the day Add-on Updater 20.03 is scheduled to be released, which happens to be 30 days after 2019.3 is released), Add-on Updater will require NVDA 2019.3. No exceptions, no extensions.

 

Also, a special change will be implemented in consideration for people using alpha snapshots: starting from Add-on Updater 20.03, those using alpha snapshots (master branch) will no longer receive incompatibility prompts if trying to update add-ons in most cases. The only time you’ll get an incompatibility notice when updating add-ons through Add-on Updater will be when NV Access updates minimum API version for all add-ons (currently set at 2019.3) and the add-on in question does not cover the updated API version in the compatibility range (minimumNVDAVersion <= newAPIVersion <= lastTestedNVDAVersion). This change is destined for alpha snapshot users only – those using betas, RC’s, and stable releases will continue to receive incompatibility notices if an add-on update isn’t compatible with latest NVDA version as seen internally (versionInfo.version_*).

 

Cheers,

Joseph

Important: if your development work targets 2020.1, please use Visual Studio 2019 to compile NVDA

 

Hi all,

 

Last week, NVDA source code was updated to require Visual Studio 2019. If you are planning to send pull requests targeting NVDA 2020.1 (or later), you must use Visual Studio 2019 (16.2 or later) and several additional components to compile NVDA locally (and please, please, PLEASE perform lint checks locally BEFORE sending your commits to NV Access so your PR log won’t get filled with all sorts of linting messages).

 

In case you are migrating from Visual Studio 2017 to 2019, do:

 

  1. Uninstall Visual studio 2017.
  2. Install Visual Studio 2019 (16.2) or later – any edition will do.
  3. As part of VS2019 install, you must install Visual C++ tools for x86/x64 and ARM64, Clang tools (9.0.0) required to build Liblouis, and ATL tools for x86/x64 and ARM64 for Windows 10 components. Along with these, you should install Windows 10 SDK version 10.0.18362 (May/November 2019 Update release).

 

For people doing a git pull on NVDA master branch, you MUST do git submodule update to update submodule commits.

Cheers,

Joseph

Re: Helpf for 2019.3 and a dll

Brian's Mail list account
 

Subtle changes in how data should be presented seem to be quite common in the newer Python.

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: "Alberto Buffolino" <a.buffolino@...>
To: <nvda-devel@groups.io>
Sent: Friday, February 14, 2020 5:32 PM
Subject: Re: [nvda-devel] Helpf for 2019.3 and a dll


Brian's Mail list account via Groups.Io, il 14/02/2020 17.06, ha scritto:
Well, logically, it has to be the change to python version, unless you can find out that the code handing these ports had to be rewritten for the new nvda version.
Alberto:
obviously :) I just solved, anyway. The problem was the DLL accepts bytes string, as str was in Python 2, so I used bytes(strArg.encode(...)) as solution (encoding port in mbcs and cells in raw_unicode_escape, hoping this latter gives no problem).
Alberto

for IntelliJ with NVDA #3030-advice

Vinod kumar Gajula
 

Hi there!
i am vinod kumar gajula.
i am a developer at cognizant,recently i got placed in it.

I have a question for you all.

Does anybody use IntelliJ for coding python with NVDA?

Thank you!

Regards

Vinod gajula

Re: Helpf for 2019.3 and a dll

Alberto Buffolino
 

Brian's Mail list account via Groups.Io, il 14/02/2020 17.06, ha scritto:
Well, logically, it has to be the change to python version, unless you can find out that the code handing these ports had to be rewritten for the new nvda version.
Alberto:
obviously :) I just solved, anyway. The problem was the DLL accepts bytes string, as str was in Python 2, so I used bytes(strArg.encode(...)) as solution (encoding port in mbcs and cells in raw_unicode_escape, hoping this latter gives no problem).
Alberto

Re: Helpf for 2019.3 and a dll

Brian's Mail list account
 

Well, logically, it has to be the change to python version, unless you can find out that the code handing these ports had to be rewritten for the new nvda version. You need to somehow trace what is used to get the dll to output to the right place or get its input.
I'm out of my depth with this, just offering some logical thought processes, that is all.
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: "Alberto Buffolino" <a.buffolino@...>
To: <nvda-devel@groups.io>
Sent: Friday, February 14, 2020 11:18 AM
Subject: [nvda-devel] Helpf for 2019.3 and a dll


Hi all,
I'm trying to port an old Braille display driver to 2019.3. I packaged it in .nvda-addon, and under 2019.2 it works. Then, updating to 2019.3, even if there is apparently no error in code, it suddenly works bad.
If I understood correctly, it seems that the DLL, loaded with windll.LoadLibrary, now returns always 0, even if serial port and baud are correct.
Do you have any idea?
You can find repo here:
https://github.com/ABuffEr/mb408sl-driver
Thanks a lot.
Alberto

Helpf for 2019.3 and a dll

Alberto Buffolino
 

Hi all,
I'm trying to port an old Braille display driver to 2019.3. I packaged it in .nvda-addon, and under 2019.2 it works. Then, updating to 2019.3, even if there is apparently no error in code, it suddenly works bad.
If I understood correctly, it seems that the DLL, loaded with windll.LoadLibrary, now returns always 0, even if serial port and baud are correct.
Do you have any idea?
You can find repo here:
https://github.com/ABuffEr/mb408sl-driver
Thanks a lot.
Alberto

Re: NVDA 2019.3 and community add-ons: slowly making progress

Brian's Mail list account
 

I'd have thought the ones known to only need manifest edits could be listed here and on the add on list for those who feel happy to do this for themselves.
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: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Thursday, February 13, 2020 6:49 PM
Subject: [nvda-devel] 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



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?