Date   

Re: Caret movement in Android studio

mohammad suliman
 

Hello Pieter 
I will suggest to perform the same steps with the swingset2 application and see what happens. If you encounter the same issue, I think it’ s safe to assume that this is a NVDA bug, if not, then this will be a Studio one IMO.
Let us know how things goes for you.
All the best!
Mohammad

On Fri, 21 Feb 2020 at 15:40 Peter <lecky_lists@...> wrote:
Hello all,
I am using Android studio and it seems that it is not possible to move
caret to review cursor in edits. Is this a bug of nvda or the problem in
accessibility implementation of edit in studio, or may be somewhere in
JAB? Steps to reproduce:
1. open Android Studio and and focus code editor with some code.
2. Move review cursor to some place in the edit, which is different than
caret position, e.g. 5 lines down
3. Try to move caret to review cursor (press twice nvda+shift+bckspc).
Nvda says the character under the review cursor but caret does not move.
I tested also function nvda+shift+f9 (move cursor to saved selection
position) with same results.
I can submit a bug to tracker if this  is a nvda's bug.
Any ideas?
With best and thanks
Peter

--
**************************
Peter Lecky





Caret movement in Android studio

Peter
 

Hello all,
I am using Android studio and it seems that it is not possible to move caret to review cursor in edits. Is this a bug of nvda or the problem in accessibility implementation of edit in studio, or may be somewhere in JAB? Steps to reproduce:
1. open Android Studio and and focus code editor with some code.
2. Move review cursor to some place in the edit, which is different than caret position, e.g. 5 lines down
3. Try to move caret to review cursor (press twice nvda+shift+bckspc). Nvda says the character under the review cursor but caret does not move. I tested also function nvda+shift+f9 (move cursor to saved selection position) with same results.
I can submit a bug to tracker if this is a nvda's bug.
Any ideas?
With best and thanks
Peter

--
**************************
Peter Lecky


Re: Error: timer can only be started from the main thread

 

Hi,

What add-ons do you have? It is likely that an add-on isn’t starting/queueing timers from the main thread.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Cyrille via Groups.Io
Sent: Friday, February 21, 2020 5:47 AM
To: nvda-devel@groups.io
Subject: [nvda-devel] Error: timer can only be started from the main thread

 

Hello

Using NVDA 2019.3.1, I have encountered several times this error:

wx._core.wxAssertionError: C++ assertion "wxThread::IsMain()" failed at ..\..\src\common\timerimpl.cpp(60) in wxTimerImpl::Start(): timer can only be started from the main thread

At the beginning, I was thinking that the Windows Magnifier add-on I am developping was responsible for this, since it was happening some times when modifying the zoom level. However, I have finally got this error also with Windows Magnifier add-on disabled when navigating in the processus list with table nav commands. Here is the part of the log:

IO - inputCore.executeGesture (13:18:50.682) - winInputHook (14028):
Input: kb(desktop):alt+control+downArrow
ERROR - unhandled exception (13:18:50.702) - winInputHook (14028):
Traceback (most recent call last):
  File "wx\core.pyc", line 3240, in <lambda>
wx._core.wxAssertionError: C++ assertion "wxThread::IsMain()" failed at ..\..\src\common\timerimpl.cpp(60) in wxTimerImpl::Start(): timer can only be started from the main thread
ERROR - unhandled exception (13:18:50.712) - winInputHook (14028):
Traceback (most recent call last):
  File "wx\core.pyc", line 3240, in <lambda>
  File "wx\core.pyc", line 3284, in __init__
  File "wx\core.pyc", line 3305, in Start
wx._core.wxAssertionError: C++ assertion "wxThread::IsMain()" failed at ..\..\src\common\timerimpl.cpp(60) in wxTimerImpl::Start(): timer can only be started from the main thread
IO - inputCore.executeGesture (13:18:50.731) - winInputHook (14028):
Input: kb(desktop):control+

Windows Magnifier add-on was disabled but some other add-ons were enabled. Thus, I cannot figure if this issue comes from another add-on or from NVDA itself.

I did not succeed in reproducing this issue with all add-ons disabled. But with add-ons enabled this bug shows up too rarely to be able to reproduce it in a reliable way. Thus I cannot guarantee that the add-ons are the cause of this bug.

Has someone also seen this bug?

Has someone an idea of the origin of this bug? Or an idea to investigate it?

Thanks.

Cheers,

Cyrille


Error: timer can only be started from the main thread

Cyrille
 

Hello
Using NVDA 2019.3.1, I have encountered several times this error:
wx._core.wxAssertionError: C++ assertion "wxThread::IsMain()" failed at ..\..\src\common\timerimpl.cpp(60) in wxTimerImpl::Start(): timer can only be started from the main thread
At the beginning, I was thinking that the Windows Magnifier add-on I am developping was responsible for this, since it was happening some times when modifying the zoom level. However, I have finally got this error also with Windows Magnifier add-on disabled when navigating in the processus list with table nav commands. Here is the part of the log:
IO - inputCore.executeGesture (13:18:50.682) - winInputHook (14028):
Input: kb(desktop):alt+control+downArrow
ERROR - unhandled exception (13:18:50.702) - winInputHook (14028):
Traceback (most recent call last):
  File "wx\core.pyc", line 3240, in <lambda>
wx._core.wxAssertionError: C++ assertion "wxThread::IsMain()" failed at ..\..\src\common\timerimpl.cpp(60) in wxTimerImpl::Start(): timer can only be started from the main thread
ERROR - unhandled exception (13:18:50.712) - winInputHook (14028):
Traceback (most recent call last):
  File "wx\core.pyc", line 3240, in <lambda>
  File "wx\core.pyc", line 3284, in __init__
  File "wx\core.pyc", line 3305, in Start
wx._core.wxAssertionError: C++ assertion "wxThread::IsMain()" failed at ..\..\src\common\timerimpl.cpp(60) in wxTimerImpl::Start(): timer can only be started from the main thread
IO - inputCore.executeGesture (13:18:50.731) - winInputHook (14028):
Input: kb(desktop):control+

Windows Magnifier add-on was disabled but some other add-ons were enabled. Thus, I cannot figure if this issue comes from another add-on or from NVDA itself.
I did not succeed in reproducing this issue with all add-ons disabled. But with add-ons enabled this bug shows up too rarely to be able to reproduce it in a reliable way. Thus I cannot guarantee that the add-ons are the cause of this bug.
Has someone also seen this bug?
Has someone an idea of the origin of this bug? Or an idea to investigate it?
Thanks.
Cheers,
Cyrille


Re: Problems wit combo date setting of cards on Amazon

Brian's Mail list account
 

OK I have had to go back to 2019.2.1 to find that selection box etc accessible. Can somebody have a look at this please?
Its hard to give you another instance of this as its only inside my account settings that this anomaly showed up in Firefox.

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: "Brian's Mail list account via Groups.Io" <bglists=blueyonder.co.uk@groups.io>
To: "NVDA Dev list on groups.io" <nvda-devel@groups.io>
Sent: Thursday, February 20, 2020 10:09 AM
Subject: [nvda-devel] Problems wit combo date setting of cards on Amazon


Not sure if this is an nvda issue or that Amazon have changed something. Trying to put a new card in today, it won't let me change the expiry date boxes. Indeed as soon as it gets focus it jumps out and says invalid expiry date. I tried the control key trick, but that seems not to work either.
Has anyone else come across this, and can either suggest a work around or tell me if its a known issue on the site.
If its nvda, then its in all the versions I've got here.
puzzled.
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


Problems wit combo date setting of cards on Amazon

Brian's Mail list account
 

Not sure if this is an nvda issue or that Amazon have changed something. Trying to put a new card in today, it won't let me change the expiry date boxes. Indeed as soon as it gets focus it jumps out and says invalid expiry date. I tried the control key trick, but that seems not to work either.
Has anyone else come across this, and can either suggest a work around or tell me if its a known issue on the site.
If its nvda, then its in all the versions I've got here.
puzzled.
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


Re: Add-on Updater 20.02.2 (experimental) #addonrelease

Brian's Mail list account
 

Hi, well the latest two problem ones are now installed, Mozilla and dropbox. I assume this is what you wanted to hear. Both in alpha.
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-addons@nvda-addons.groups.io>
Sent: Monday, February 17, 2020 6:00 PM
Subject: [nvda-devel] Add-on Updater 20.02.2 (experimental) #AddonRelease


Hi all,



Add-on Updater 20.02.2 is now available. This is both a stable and an
experimental release. Just like recent stable releases, you'll be greeted
with compatibility notice after installing this version. It is also an
experimental release in that compatibility range check will be disabled if
you are using NVDA alpha snapshots; if it goes well, it'll be extended to
all users with version 20.03.



Cheers,

Joseph




Add-on Updater 20.02.2 (experimental) #addonrelease

 

Hi all,

 

Add-on Updater 20.02.2 is now available. This is both a stable and an experimental release. Just like recent stable releases, you’ll be greeted with compatibility notice after installing this version. It is also an experimental release in that compatibility range check will be disabled if you are using NVDA alpha snapshots; if it goes well, it’ll be extended to all users with version 20.03.

 

Cheers,

Joseph


Fw: [nvaccess/nvda] pdf: NVDA skips private use areas characters (#5562)

Brian's Mail list account
 

From: "Victor Cai" <notifications@...>
To: "nvaccess/nvda" <nvda@...>
Cc: "Subscribed" <subscribed@...>
Sent: Monday, February 17, 2020 7:18 AM
Subject: Re: [nvaccess/nvda] pdf: NVDA skips private use areas characters (#5562)


Now, NVDA 2019.3.1 released.

Then, we still need to use version 2013.3 to read private use area characters in pdf while using acrobat reader.

Is it possible to have a try build to fix this issue temporarily?

Actually, I do not know how to do.

(git revert 788cefb) or something else.


Thank you for all of your help.





--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/nvaccess/nvda/issues/5562#issuecomment-586849958


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

 

Hi,
Regarding Windows 7, my plan is to not test it (end of life) unless critical
issues are reported.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Brian's Mail
list account via Groups.Io
Sent: Sunday, February 16, 2020 11:09 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Important: if your development work targets
2020.1, please use Visual Studio 2019 to compile NVDA

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





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

Brian's Mail list account
 

Which reminds me, on the latest stable, I'm getting prompted to install a version of mozilla enhancements with an issue number lower than the one installed already. This started in the last few days. I've not let it do so, since the old one says its compatible. Strange?
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 6:38 AM
Subject: [nvda-devel] 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




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