Date   
Issue on accessible podcatcher in 2019.3

Brian's Mail list account
 

This is intermittent and as such doing a github entry is not that easy. This is the program destributed by webbie and is stand alone and very handy.
The crash happens when the log stopped at which time I had to restart nvda.

Input: kb(desktop):downArrow
IO - speech.speak (11:29:03.333) - MainThread (2584):
Speaking [LangChangeCommand ('en_GB'), 'In Touch (BBC Radio 4)', '10 of 16']
IO - inputCore.InputManager.executeGesture (11:29:05.183) - winInputHook (3368):
Input: kb(desktop):enter
DEBUG - speech.manager.SpeechManager._handleIndex (11:29:05.510) - MainThread (2584):
Unknown index 8749, speech probably cancelled from main thread.
IO - speech.speak (11:29:05.517) - MainThread (2584):
Speaking [LangChangeCommand ('en_GB'), 'Frame1']
IO - speech.speak (11:29:05.518) - MainThread (2584):
Speaking [LangChangeCommand ('en_GB'), 'Getting podcast, please wait.', '1 of 1']
IO - inputCore.InputManager.executeGesture (11:29:08.559) - winInputHook (3368):
Input: kb(desktop):downArrow
IO - inputCore.InputManager.executeGesture (11:29:09.423) - winInputHook (3368):
Input: kb(desktop):upArrow
IO - inputCore.InputManager.executeGesture (11:29:10.023) - winInputHook (3368):
Input: kb(desktop):downArrow
IO - inputCore.InputManager.executeGesture (11:29:10.423) - winInputHook (3368):
Input: kb(desktop):upArrow
IO - inputCore.InputManager.executeGesture (11:29:10.855) - winInputHook (3368):
Input: kb(desktop):downArrow
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (11:29:11.400) - MainThread (2584):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
IO - inputCore.InputManager.executeGesture (11:29:12.655) - winInputHook (3368):
Input: kb(desktop):tab
IO - inputCore.InputManager.executeGesture (11:29:13.351) - winInputHook (3368):
Input: kb(desktop):upArrow
IO - inputCore.InputManager.executeGesture (11:29:13.671) - winInputHook (3368):
Input: kb(desktop):downArrow
IO - inputCore.InputManager.executeGesture (11:29:14.495) - winInputHook (3368):
Input: kb(desktop):upArrow
IO - inputCore.InputManager.executeGesture (11:29:15.199) - winInputHook (3368):
Input: kb(desktop):escape
DEBUGWARNING - watchdog._watcher (11:29:16.400) - watchdog (3428):
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 912, in pumpAll
File "IAccessibleHandler.pyc", line 643, in processGenericWinEvent
File "eventHandler.pyc", line 39, in queueEvent

DEBUGWARNING - RPC process 1992 (dwm.exe) (11:29:17.138) - Dummy-24 (4812):
Thread 1092, build\x86_64\remote\injection.cpp, inproc_winEventCallback, 66:
SetWindowsHookEx with WH_GETMESSAGE failed, GetLastError returned 5

DEBUGWARNING - RPC process 1992 (dwm.exe) (11:29:17.140) - Dummy-24 (4812):
Thread 1092, build\x86_64\remote\injection.cpp, inproc_winEventCallback, 69:
SetWindowsHookEx with WH_CALLWNDPROC failed, GetLastError returned 5

And there it just stopped working.
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

Issue reported by spanish user: NVDA reports unknown for menus and Windows

Noelia Ruiz
 

Hello:

Also for @Reef and @Mick, in case this could be related to NVDA's
installation or updates, or something related with Ofice in
combination with NVDA.
This has been reported on a spanish mailing list. Seems that the same
user had a similar issue time ago after installing Office 2007. This
person has run the tool COM registration fixing without good results.
What's the best way to fix these kind of issues? Maybe restoring the
system? Please, let me know if we should open an issue in case this
could be related to NVDA updates or installation process.
Also, as a reminder, I commented a different problem with Outlook,
also reported by other spanish user. Not sure if these issues have
some kind of relationship.
This was reported on this list at
https://groups.io/g/nvda-devel/message/44836

Re: How to silence reading control types.

Pawel Urbanski
 

Hi Everyone,
I finally, after lots of digging found a workaround:
Using: roleText and roleTextBraille to overwrite the properties, set
them before calling super() method on the subclassed control.

The idea for the core dev team:
Rename those properties to:
roleLabelSpeech and roleLabelBraille - respectively.
There are only around 50 calls to current roleText and roleTextBraille
properties in the NVDA's codebase - easy to refactor.

The 'label' name gives a stronger hint to its purpose. At first I
thought that it is some kind of text returned and not useful for
setting values.
Marking them as 'speech' and 'braille' gives a hint to the effect. We
currently have the roleTextBraille variant, which somehow hints that
both are related.
Additionally, some kind of class constants as: 'ROLE_SILENT' and
'ROLE_HIDDEN' would be useful to skip speaking or displaying when set
as part of some event procedure.

I could try to create a branch and try to hack something...

Best,
Pawel

On 25/02/2020, Pawel Urbanski via Groups.Io
<pawel=e-urbanski.com@groups.io> wrote:
Dear Everyone,
Since I am not that deeply knowledgeable about NVDA
s internals, I reached out to some of you with a few questions. I read
through the sources before, but could not find the way to achieve the
following:
How can I silence speaking the control type?

I'm developing/improving an add-on for a few IDEs. All of them provide
code completion.
When completion popup shows up its type is spoken. After completion is
inserted the role for editable text is spoken as well.
I tried the following on the level of the app module or custom control
class and events, but it did not work in certain cases:
controlTypes.silentRolesOnFocus.add(ControlTypes.ROLE_EDITABLETEXT)
controlTypes.silentValuesForRoles.add(controlTypes.ROLE_EDITABLETEXT)

It seems to me that the control label for role is read first. While I
managed to discard useless states, which add the noise, I cannot make
the roles silent.

The only hack, which I would like to avoid, but works is to rename the
type role labels:
controlTypes.roleLabels[controlTypes.ROLE_EDITABLETEXT] = "" # Empty
string.
I rename it back to the standard: "edit" in the terminate method call.

Any help or hints will be more than appriciated...

All the best...



How to silence reading control types.

Pawel Urbanski
 

Dear Everyone,
Since I am not that deeply knowledgeable about NVDA
s internals, I reached out to some of you with a few questions. I read
through the sources before, but could not find the way to achieve the
following:
How can I silence speaking the control type?

I'm developing/improving an add-on for a few IDEs. All of them provide
code completion.
When completion popup shows up its type is spoken. After completion is
inserted the role for editable text is spoken as well.
I tried the following on the level of the app module or custom control
class and events, but it did not work in certain cases:
controlTypes.silentRolesOnFocus.add(ControlTypes.ROLE_EDITABLETEXT)
controlTypes.silentValuesForRoles.add(controlTypes.ROLE_EDITABLETEXT)

It seems to me that the control label for role is read first. While I
managed to discard useless states, which add the noise, I cannot make
the roles silent.

The only hack, which I would like to avoid, but works is to rename the
type role labels:
controlTypes.roleLabels[controlTypes.ROLE_EDITABLETEXT] = "" # Empty string.
I rename it back to the standard: "edit" in the terminate method call.

Any help or hints will be more than appriciated...

All the best...

Waltr 2 and NVDA

Brian's Mail list account
 

Those who may not know this is a paid for piece of software which makes file conversion from a pc or a mac to an I phone very simple, altering coding and changing file extention names as required. Its far more efficient and less mind bending than I Tunes. However it won't work correctly with NVDA, but does better with Jaws. It seems the selection buttons on the main interface are not being read, and some very odd results obtained in the file browser as well, with words like main Thread being spoken.
The logs I have thus far are here:
I have sent the info to the developer who have extended my free trial, so may well be looking at it as well. You can find their site if you juust type waltr2 into any search engine.

IO - inputCore.InputManager.executeGesture (10:48:33.032) - winInputHook (5604):
Input: kb(desktop):enter
IO - speech.speak (10:48:35.359) - MainThread (2540):
Speaking [LangChangeCommand ('en_GB'), 'WALTR 2']
IO - inputCore.InputManager.executeGesture (10:48:39.456) - winInputHook (5604):
Input: kb(desktop):tab
IO - inputCore.InputManager.executeGesture (10:48:40.784) - winInputHook (5604):
Input: kb(desktop):tab
IO - speech.speak (10:48:40.809) - MainThread (2540):
Speaking [LangChangeCommand ('en_GB'), 'or Select Files...']
IO - inputCore.InputManager.executeGesture (10:48:42.512) - winInputHook (5604):
Input: kb(desktop):tab
IO - speech.speak (10:48:42.552) - MainThread (2540):
Speaking [LangChangeCommand ('en_GB'), 'collapsed']
IO - inputCore.InputManager.executeGesture (10:48:43.775) - winInputHook (5604):
Input: kb(desktop):tab
IO - inputCore.InputManager.executeGesture (10:48:44.983) - winInputHook (5604):
Input: kb(desktop):tab
IO - inputCore.InputManager.executeGesture (10:48:45.975) - winInputHook (5604):
Input: kb(desktop):tab
IO - speech.speak (10:48:46.004) - MainThread (2540):
Speaking [LangChangeCommand ('en_GB'), 'or Select Files...']
IO - inputCore.InputManager.executeGesture (10:48:53.224) - winInputHook (5604):
Input: kb(desktop):space
IO - speech.speak (10:48:53.810) - MainThread (2540):
Speaking [LangChangeCommand ('en_GB'), 'WALTR2', 'Documents library Documents library\nFile name:']
IO - speech.speak (10:48:53.812) - MainThread (2540):
Speaking [LangChangeCommand ('en_GB'), 'File name:', 'collapsed']
IO - speech.speak (10:48:53.814) - MainThread (2540):
Speaking [LangChangeCommand ('en_GB'), 'Alt+n']
DEBUG - NVDAObjects.NVDAObject._get_placeholder (10:48:53.816) - MainThread (2540):
Potential unimplemented child class: <NVDAObjects.Dynamic_IAccessibleEditWindowNVDAObjectEditableIndentNav object at 0x0689B870>
IO - speech.speak (10:48:53.816) - MainThread (2540):
Speaking [LangChangeCommand ('en_GB'), 'blank']
IO - speech.speak (10:48:54.787) - MainThread (2540):
Speaking [LangChangeCommand ('en_GB'), 'Contains movies and other video files.\nDate created: \u200e14/\u200e07/\u200e2009 \u200f\u200e06:08']

Not much to go on there, but the log from the developers part says.

INFO - globalCommands.GlobalCommands.script_navigatorObject_devInfo (11:00:52.346) - MainThread (3244):
Developer info for navigator object:
name: ''
role: ROLE_BUTTON
roleText: None
states: STATE_FOCUSABLE, STATE_FOCUSED
isFocusable: True
hasFocus: True
Python object: <NVDAObjects.UIA.UIA object at 0x0681E750>
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=711, top=310, width=160, height=20)
value: None
appModule: <'appModuleHandler' (appName 'waltr2', process ID 4980) at address 4b768d0>
appModule.productName: 'WALTR'
appModule.productVersion: '2.7.19.0'
TextInfo: <class 'NVDAObjects.NVDAObjectTextInfo'>
windowHandle: 721792
windowClassName: 'HwndWrapper[WALTR2.exe;;465ddc20-4c27-4bc6-99d7-3fe713a49c20]'
windowControlID: 0
windowStyle: 369754112
extendedWindowStyle: 786432
windowThreadID: 2604
windowText: 'WALTR 2'
displayText: ''
UIAElement: <POINTER(IUIAutomationElement) ptr=0x30bf7b0 at 6d2ce90>
UIA automationID:
UIA frameworkID: WPF
UIA runtimeID: (7, 4980, 28828491)
UIA providerDescription: [pid:4980,hwnd:0x0 Main(parent link):Unidentified Provider (managed:MS.Internal.Automation.ElementProxy, PresentationCore, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35)]
UIA className: Button
UIA patterns available: LegacyIAccessiblePattern, InvokePattern, SynchronizedInputPattern


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: Caret movement in Android studio

Peter
 

Hello Mohammad,
Thanks for suggestion. I made simple swing app with edit and tested. It looks that problem is really in android studio code editor, because it works as expected in my swing app.
Will try to contact people in Jet brains (Android studio is based on IntelliJ Idea), or may be google accessibility team, they worked on accessibiility of Android studio.
With best
Peter

On 21. 2. 2020 15:00, mohammad suliman wrote:
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.
https://docs.oracle.com/javase/accessbridge/2.0.2/javamonkey.htm
Let us know how things goes for you.
All the best!
Mohammad
On Fri, 21 Feb 2020 at 15:40 Peter <lecky_lists@... <mailto: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
--
**************************
Peter Lecky
PGP key: http://cezap.sk/~lecky/peter_lecky.asc
JID (preferovany im protokol - mozu pouzit aj ti co pouzivaju google talk): peter.lecky@...
skype (moze byt): peter.lecky
ICQ (ak naozaj nemozte inak): 370315145

Error building NVDA with VS 2019

Cyrille
 

Hello

 

I do not succeed in building NVDA alpha with VS 2019.

 

I have first tried on an existing local repo. Since it did not work, I have tried by cloning a brand new local repo:

 

Here is the end of the build log with the error:

 

ia2_i.c

cl /Fobuild\arm64\ia2_p.obj /c build\arm64\ia2_p.c /nologo /W3 /WX /std:c++17 /Od /MT /DUNICODE=_CRT_SECURE_NO_DEPRECATE

/DWIN32 /DPROXY_CLSID_IS={0x62d295fe,0x2062,0x4369,{0xa0,0x10,0x4f,0x59,0xb5,0xe3,0x2d,0x5e}} /Iinclude /Imiscdeps\incl

ude /Ibuild\arm64 /Z7

ia2_p.c

cl /Fobuild\arm64\ia2_data.obj /c build\arm64\ia2_data.c /nologo /W3 /WX /std:c++17 /Od /MT /DUNICODE=_CRT_SECURE_NO_DEP

RECATE /DWIN32 /DPROXY_CLSID_IS={0x62d295fe,0x2062,0x4369,{0xa0,0x10,0x4f,0x59,0xb5,0xe3,0x2d,0x5e}} /Iinclude /Imiscdep

s\include /Ibuild\arm64 /Z7

ia2_data.c

Creating 'build\arm64\IAccessible2proxy.manifest'

link /nologo /incremental:no /WX /subsystem:windows,6.02 /release /OPT:REF /export:DllGetClassObject,private /export:Dll

CanUnloadNow,private /export:GetProxyDllInfo,private /manifest:embed /manifestinput:build\arm64\IAccessible2proxy.manife

st /dll /out:build\arm64\IAccessible2proxy.dll /implib:build\arm64\IAccessible2proxy.lib rpcrt4.lib oleaut32.lib ole32.l

ib /PDB:build\arm64\IAccessible2proxy.dll.pdb /DEBUG build\arm64\ia2_i.obj build\arm64\ia2_p.obj build\arm64\ia2_data.ob

j

LINK : fatal error LNK1104: impossible d'ouvrir le fichier 'LIBCMT.lib'

scons: *** [build\arm64\IAccessible2proxy.dll] Error 1104

scons: building terminated because of errors.

 

Any idea why I get this error? Did I miss something during VS 2019 installation?
Note: I have first uninstalled VS 2017 and then re-installed VS 2019.

 

Thanks in advance.

Cheers,

 

Cyrille

 

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

Cyrille
 

Hello

At least, I succeed in reproducing such an error with a brand new NVDA config (no add-ons, no config).
I go on a webpage with a big table (e.g. https://en.numista.com/catalogue/pieces44.html).
I go in the first column of the second table (the big one). And I press control+alt+downArrow during many secons (say 5 seconds). I maintain the keys down during this time to cal many times the script.
If I do not yet succeed in reproducing the error, I make another try by pressing control+alt+upArrow during about 5 seconds. And again down during 5 seconds if it was not enough to trigger the error.

I recall that the original use case were the call of the zoom in or out scripts in Windows Magnifier add-on. In fact, when zooming in or out, I may execute the gesture many times in 1 or 2 seconds to reach the zoom factor I want.

Thus it seems that this error occurs when repeating a lot a script call.

Any idea to investigate still further?

Thanks.
Cheers,

Cyrille

-----Message d'origine-----
De : nvda-devel@groups.io <nvda-devel@groups.io> De la part de Brian's Mail list account via Groups.Io
Envoyé : vendredi 21 février 2020 21:29
À : nvda-devel@groups.io
Objet : Re: [nvda-devel] Error: timer can only be started from the main thread

It occurred to me that any add on that is permanently active is likely to be one of the culprits. Perhaps this might help. I remember a similar error to this when the machine itself was doing a back up and the nvda in question did have a lot of add ons. Perhaps there is just not enough time for one of the add ons to do its stuff and it has poor sensing of when its not supposed to start the timer. Obviously, I'm a lay person at your level. However there does seem to be one heck of a lot of add ons in there to me. Does the IBM tts need to be there? Also there are a lot I do not recognise and as such they have probably not been tested by many people.
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: "Cyrille via Groups.Io" <cyrille.bougot2=laposte.net@groups.io>
To: <nvda-devel@groups.io>
Sent: Friday, February 21, 2020 3:28 PM
Subject: Re: [nvda-devel] Error: timer can only be started from the main thread


Hi Joseph

Thanks for answering.

I have the following add-ons.
[('Access8Math', '2.3'), ('addonUpdater', '19.11'), ('audioChart', '1.2'), ('charInfo', '1.3'), ('clock', '19.12-dev'), ('columnsReview', '3.0-20191212-dev'), ('developerToolkit', '2020.2'), ('easyTableNavigator', '2.0'), ('Eloquence', '2019.10.08'), ('EnhancedPhoneticReading', '0.5a2'), ('IBMTTS', '19.10B2'), ('instantTranslate', '20191216-dev'), ('outlookExtended', '1.5-dev-20200211'), ('placeMarkers', '14.0'), ('resourceMonitor', '20.01'), ('SentenceNav', '2.7'), ('speechHistory', '2019.03.30_CB'), ('switchSynth', '1.03'), ('tonysEnhancements', '1.2'), ('VLCAccessEnhancement', '2.0.2'), ('webAccess', '2019.12.13'), ('winMag', '1.0-dev-20200219')] This makes a lot of add-ons. And since the issue occurs only from time to time, I cannot disable add-ons one by one to find where is the problem.
That's why I was wondering if there is a way to know who has created this timer. Or if anyone else was experimenting the same issue.

Cheers,

Cyrille

----- Mail d'origine -----De: Joseph Lee
<@joslee>&Agrave;: nvda-devel@...&eacute;: Fri,
21 Feb 2020 13:55:53 +0100 (CET)Objet: Re: [nvda-devel] 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&rsquo;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.IoSent: Friday, February 21, 2020 5:47 AMTo:
nvda-devel@...: [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+downArrowERROR - 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 threadERROR - 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 Startwx._core.wxAssertionError: C++ assertion "wxThread::IsMain()" failed at ..\..\src\common\timerimpl.cpp(60) in
wxTimerImpl::Start(): timer can only be started from the main threadIO - 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: Error: timer can only be started from the main thread

Brian's Mail list account
 

It occurred to me that any add on that is permanently active is likely to be one of the culprits. Perhaps this might help. I remember a similar error to this when the machine itself was doing a back up and the nvda in question did have a lot of add ons. Perhaps there is just not enough time for one of the add ons to do its stuff and it has poor sensing of when its not supposed to start the timer. Obviously, I'm a lay person at your level. However there does seem to be one heck of a lot of add ons in there to me. Does the IBM tts need to be there? Also there are a lot I do not recognise and as such they have probably not been tested by many people.
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: "Cyrille via Groups.Io" <cyrille.bougot2=laposte.net@groups.io>
To: <nvda-devel@groups.io>
Sent: Friday, February 21, 2020 3:28 PM
Subject: Re: [nvda-devel] Error: timer can only be started from the main thread


Hi Joseph

Thanks for answering.

I have the following add-ons.
[('Access8Math', '2.3'), ('addonUpdater', '19.11'), ('audioChart', '1.2'), ('charInfo', '1.3'), ('clock', '19.12-dev'), ('columnsReview', '3.0-20191212-dev'), ('developerToolkit', '2020.2'), ('easyTableNavigator', '2.0'), ('Eloquence', '2019.10.08'), ('EnhancedPhoneticReading', '0.5a2'), ('IBMTTS', '19.10B2'), ('instantTranslate', '20191216-dev'), ('outlookExtended', '1.5-dev-20200211'), ('placeMarkers', '14.0'), ('resourceMonitor', '20.01'), ('SentenceNav', '2.7'), ('speechHistory', '2019.03.30_CB'), ('switchSynth', '1.03'), ('tonysEnhancements', '1.2'), ('VLCAccessEnhancement', '2.0.2'), ('webAccess', '2019.12.13'), ('winMag', '1.0-dev-20200219')]
This makes a lot of add-ons. And since the issue occurs only from time to time, I cannot disable add-ons one by one to find where is the problem.
That's why I was wondering if there is a way to know who has created this timer. Or if anyone else was experimenting the same issue.

Cheers,

Cyrille

----- Mail d'origine -----De: Joseph Lee <@joslee>&Agrave;: nvda-devel@...&eacute;: Fri, 21 Feb 2020 13:55:53 +0100 (CET)Objet: Re: [nvda-devel] 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&rsquo;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.IoSent: Friday, February 21, 2020 5:47 AMTo: nvda-devel@...: [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+downArrowERROR - 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 threadERROR - 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 Startwx._core.wxAssertionError: C++ assertion "wxThread::IsMain()" failed at ..\..\src\common\timerimpl.cpp(60) in wxTimerImpl::Start(): timer can only be started from the main threadIO - 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: Error: timer can only be started from the main thread

Cyrille
 

Hi Joseph
Thanks for answering.
I have the following add-ons.
[('Access8Math', '2.3'), ('addonUpdater', '19.11'), ('audioChart', '1.2'), ('charInfo', '1.3'), ('clock', '19.12-dev'), ('columnsReview', '3.0-20191212-dev'), ('developerToolkit', '2020.2'), ('easyTableNavigator', '2.0'), ('Eloquence', '2019.10.08'), ('EnhancedPhoneticReading', '0.5a2'), ('IBMTTS', '19.10B2'), ('instantTranslate', '20191216-dev'), ('outlookExtended', '1.5-dev-20200211'), ('placeMarkers', '14.0'), ('resourceMonitor', '20.01'), ('SentenceNav', '2.7'), ('speechHistory', '2019.03.30_CB'), ('switchSynth', '1.03'), ('tonysEnhancements', '1.2'), ('VLCAccessEnhancement', '2.0.2'), ('webAccess', '2019.12.13'), ('winMag', '1.0-dev-20200219')]

This makes a lot of add-ons. And since the issue occurs only from time to time, I cannot disable add-ons one by one to find where is the problem.
That's why I was wondering if there is a way to know who has created this timer. Or if anyone else was experimenting the same issue.
Cheers,
Cyrille
----- Mail d'origine -----
De: Joseph Lee <joseph.lee22590@...>
À: nvda-devel@groups.io
Envoyé: Fri, 21 Feb 2020 13:55:53 +0100 (CET)
Objet: Re: [nvda-devel] 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

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