Date   

Re: How to check if current navigator object is an image?

Noelia Ruiz
 

Hi Shubham, imo there is not a definitive way. In fact, the OCR
feature in NVDA can be run regardless of the object role and sometimes
it says that there is not visible content. I think that, if we can be
sure that something is not an image, it may prevent or report it in
certain cases.
Not sure. Looking forward to see more about your work.
Thanks

2020-07-16 9:21 GMT+02:00, Shubham Jain <@ShubhamJain>:

My code is as follows:
import api
nav = api.getNavigatorObject()

I then check if nav.role is equal to ROLE_GRAPHIC (from controlTypes.py )
to determine if it is an image or not. But in many instances, images do not
have a role of graphic. For example, images opened in the default photo
viewer app of Windows 10 have the role ROLE_STATICTEXT while some images in
the browser have the role ROLE_LINK or ROLE_DOCUMENT.

Is there a definitive way to determine is a navigator object is an image?




Re: Braille Extender add-on: much needed code cleanup, rewrites, proper Python 3 porting and optimizations in progress

 

Hi,

Perhaps. What can help with that effort is source code comments and separating patches into separate modules so that when it comes time to send pull requests to NVDA, just the needed parts can be picked and submitted. Another thing I’m going to do (provided that Andre agrees) is convert scripts into script decorators, along with letting the add-on take advantage of more modern NVDA changes.
Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Thursday, July 16, 2020 1:20 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Braille Extender add-on: much needed code cleanup, rewrites, proper Python 3 porting and optimizations in progress

 

Hey Joseph,

 

Though I don't have time too look into this myself, I really dig this idea and am looking forward for it to progress.

One thing that could also be taken into account while refactoring is monkey patching. If we have an overview of what functionality in the add-on requires monkeypatching currently, we can propose better ways in NVDA core to handle these cases, such as with extension points.

 

Regards,

Leonard

 

On 16/07/2020 09:50, Joseph Lee wrote:

Hello all, especially to Braille Extender fans,

 

People watching Braille Extender GitHub repo (https://github.com/andre9642/brailleextender) may have noticed various issues about code maintenance and such, with the ultimate goal being bringing requested features from this add-on to NVDA itself. In preparation for that, I’m studying and taking notes on cleaning up the add-on source code with the following goals in mind:

 

  • Properly port Braille Extender to Python 3
  • Make source code conform better with Python idioms, best practices, and expectations
  • Run general lint over the entire source code to make them more readable and compliant with expectations from NVDA source code
  • Perform under the hood optimizations (this involves bytecode disassembly)

 

Knowing that I and Andre cannot do this alone, I would like to request your assistance in identifying much needed rewrites throughout Braille Extender add-on. At the moment I’m working on Python 3 porting, Flake8-based lint, and under the hood optimizations. See the above link for source code URL, and if you can, please submit new issues on the repo and send in pull requests to Andre. And please don’t forget that whenever you look at this add-on, be mindful that some of its features may end up becoming part of NVDA in the future.

 

Thanks.

Cheers,

Joseph


Re: Braille Extender add-on: much needed code cleanup, rewrites, proper Python 3 porting and optimizations in progress

 

Hey Joseph,


Though I don't have time too look into this myself, I really dig this idea and am looking forward for it to progress.

One thing that could also be taken into account while refactoring is monkey patching. If we have an overview of what functionality in the add-on requires monkeypatching currently, we can propose better ways in NVDA core to handle these cases, such as with extension points.


Regards,

Leonard


On 16/07/2020 09:50, Joseph Lee wrote:

Hello all, especially to Braille Extender fans,

 

People watching Braille Extender GitHub repo (https://github.com/andre9642/brailleextender) may have noticed various issues about code maintenance and such, with the ultimate goal being bringing requested features from this add-on to NVDA itself. In preparation for that, I’m studying and taking notes on cleaning up the add-on source code with the following goals in mind:

 

  • Properly port Braille Extender to Python 3
  • Make source code conform better with Python idioms, best practices, and expectations
  • Run general lint over the entire source code to make them more readable and compliant with expectations from NVDA source code
  • Perform under the hood optimizations (this involves bytecode disassembly)

 

Knowing that I and Andre cannot do this alone, I would like to request your assistance in identifying much needed rewrites throughout Braille Extender add-on. At the moment I’m working on Python 3 porting, Flake8-based lint, and under the hood optimizations. See the above link for source code URL, and if you can, please submit new issues on the repo and send in pull requests to Andre. And please don’t forget that whenever you look at this add-on, be mindful that some of its features may end up becoming part of NVDA in the future.

 

Thanks.

Cheers,

Joseph


Braille Extender add-on: much needed code cleanup, rewrites, proper Python 3 porting and optimizations in progress

 

Hello all, especially to Braille Extender fans,

 

People watching Braille Extender GitHub repo (https://github.com/andre9642/brailleextender) may have noticed various issues about code maintenance and such, with the ultimate goal being bringing requested features from this add-on to NVDA itself. In preparation for that, I’m studying and taking notes on cleaning up the add-on source code with the following goals in mind:

 

  • Properly port Braille Extender to Python 3
  • Make source code conform better with Python idioms, best practices, and expectations
  • Run general lint over the entire source code to make them more readable and compliant with expectations from NVDA source code
  • Perform under the hood optimizations (this involves bytecode disassembly)

 

Knowing that I and Andre cannot do this alone, I would like to request your assistance in identifying much needed rewrites throughout Braille Extender add-on. At the moment I’m working on Python 3 porting, Flake8-based lint, and under the hood optimizations. See the above link for source code URL, and if you can, please submit new issues on the repo and send in pull requests to Andre. And please don’t forget that whenever you look at this add-on, be mindful that some of its features may end up becoming part of NVDA in the future.

 

Thanks.

Cheers,

Joseph


How to check if current navigator object is an image?

Shubham Jain
 

My code is as follows:
import api
nav = api.getNavigatorObject()

I then check if nav.role is equal to ROLE_GRAPHIC (from controlTypes.py)  to determine if it is an image or not. But in many instances, images do not have a role of graphic. For example, images opened in the default photo viewer app of Windows 10 have the role ROLE_STATICTEXT while some images in the browser have the role ROLE_LINK or ROLE_DOCUMENT.

Is there a definitive way to determine is a navigator object is an image?


NVDA 2020.2RC

Rui Fontes
 

Hello!


What happened to the correction to supress the Microsoft Word messages of copy, cut and so on?


Rui Fontes

NVDA portuguese team


Re: Introducing support for selective UIA event registration in NVDA Alpha snapshots

 

Hey


Looking at what you are doing it seems that knowing deterministicaly all possible impacts in all apps will be very hard.
While this is true, I think the new approach more closely resembled what other screen readers like JAWS and Narrator do.
Is there a way to port the selective UIA event registration option to a per profile configuration?

I'm afraid not. This was my initial intent, but it wasn't possible as noted in this earlier thread.


On 07/07/2020 03:53, Joseph Lee wrote:
Hi,
Re-initializing UIA handler thread is a performance nightmare - causes NVDA to freeze until the thread comes to life.
There are two possible routes I've investigated, both involving event handlers and a pointer to UIA element for the object in question (obj.UIAElement):
1. Re-register local event handler group for the specific element by calling UIAHandler.handler.removeEventHandlerGroup then UIAHandler.handler.addEventHandlerGroup in that order for each UIA event the object needs to deal with. Code that needs to run on NVDA 2020.2 beta and earlier must check existence of "addEventHandlerGroup" in UIA handler thread and see if selective event registration is enabled. But that's not quite flexible.
2. Instruct UIA handler thread to listen to events for the specific element: this can be done by calling UIAHandler.handler.addLocalEventHandlerGroupToElement. The good news is that unlike option 1, you don't have to specify exactly which event handler group you want to register the element with. The big downside is that if an application generates new UIA elements (say, when a list opens each time something happens), calling UIAHandler.handler.removeLocalEventHandlerGroupToElement will NOT remove elements in the internal elements set - you must clean them up by cycling through the set of locally registered elements by criteria such as process ID, automation ID, UIA class name and such, followed by removing found elements (process ID is more reliable than automation ID because multiple processes may come with elements proclaiming the same automation ID; this isn't recommended but sometimes this is seen with some Windows 10 apps, even those from Microsoft).
For folks who may not know what Leonard, Bill, and I are talking about:
An event handler group is a collection of events for a UIA element. When a UI Automation client such as NVDA starts, it informs UIAutomationCore.dll that the client needs to listen to events coming from any UIA element, ranging from the currently focused element to the whole UIA tree (everything). In the past, a UIA client would register event handlers one at a time. Starting with Windows 10 Version 1809 (October 2018 Update) and Server 2019, a more convenient way to organize events called "event handler group" was introduced (part of IUIAutomation6 interface). The biggest benefit is that rather than registering one event handler at a time, multiple event handlers can be registered at once, thereby improving performance (unless UIAutomationCore.dll itself is stalled).
As part of his work, Leonard added event handler group support in UIA handler (basically a COM thread). But knowing that many users are still using older Windows releases (Windows 7 Service Pack 1, Windows 8.x, Windows 10 prior to Version 1809), a fake event handler group class is introduced to simulate the actual IUIAutomation6::EventHandlerGroup behavior: trying to register multiple events at once. The code in question goes one step further by teaching NVDA to listen to events coming from system focus and its ancestors only (parent object, or the route from the desktop object to the foreground object, and in turn from the foreground window to the focused control). Although it does introduce performance benefits, it needs to be validated by further testing by testers.
The ideal testing scenarios would be:
* Traveling through UIA universes i.e. testing apps such as Visual Studio where many UIA events are fired by many things at once.
* Reading overlays i.e. modern input features, touch keyboard, among others.
* No regressions, especially for people using Windows 7 and 8.1 (not Windows 8.0 because it is end of life since January 2016); although not recommended, you should test the code on unsupported Windows 10 releases (1507, 1511, 1607, 1703) if needed.

The way I test this code is (note: you don't have to follow exactly what I'm doing):
1. Enable selective UIA event registration. YOU MUST SAVE SETTINGS AND RESTART NVDA AFTER DOING SO! Without this, UIA handler thread will not be able to enable event handler group support (this happens early in the handler thread initialization). An alternative way to do this without restarting NVDA completely is opening Python Console and typing "import UIAHandler; UIAHandler.terminate(); UIAHandler.initialize()" with each part on separate lines.
  2. Use NVDA as normal.
3. If you do encounter issues, YOU MUST RECORD WHAT NVDA IS DOING! Please do record what you are doing and how NVDA responds versus what it should do (either mentally, electronically, physically).
4. Turn off selective UIA event registration (again, RESTART NVDA!).
5. Perform the tasks that would trigger an error in step 3. Compare and record what NVDA is doing now versus what it did with selective event registration enabled.
6. If the problem is indeed caused by selective UIA registration, do let us know immediately (here or on GitHub). Please provide NVDA version, Windows version, how you are reproducing the issue (complete with app name and version, keyboard commands if applicable), and how NVDA responded (speech, braille, etc.). Although folks might be able to guess correctly, more details would help us debug faster, make NVDA more reliable, open up more test cases, and sleep better at nights (programming and debugging all night isn't fun, folks).
Hope this clarifies a lot of things.
Cheers,
Joseph


-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Monday, July 6, 2020 10:59 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Hey,


The problem here is that it isn't very easy to switch between the global and local event registration. It requires removing all UIA event handlers and registering them again, which somehow fails, probably due to a comtypes bug. Alternatively, it could be possible to re-initialize the UIAHandler, but even of that I'm not sure, I recall that was also causing issues for me.


Regards,

Leonard

On 06/07/2020 22:20, Joseph Lee wrote:
Hi,
Not easy, but it can be done at the event handler level (that's the route I'm taking with modern input features at the moment).
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Bill
Dengler
Sent: Monday, July 6, 2020 1:09 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event
registration in NVDA Alpha snapshots

Hi,
Is it possible to disable this on a per-process level?
I've written an app module (a self-contained version of #10910) that needs to react to background windows from the app.

Thanks,
Bill
-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph
Lee
Sent: Monday, 6 July 2020 02:20
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event
registration in NVDA Alpha snapshots

Hello everyone,
Folks on NVDA add-ons list may have seen the below message, but just to reiterate:
For people using Windows 10 App Essentials: you'll notice that if you do enable the option described here, you won't be able to hear emoji panel changes as you scroll through emoji categories. I'm testing a potential temporary fix, which will be rolling out to development snapshot users soon.
As noted by Leonard, please do file issues on GitHub should you notice regressions.
Cheers,
Joseph


-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard
de Ruijter
Sent: Sunday, July 5, 2020 11:11 PM
To: nvda-devel@groups.io; program-l@...
Subject: [nvda-devel] Introducing support for selective UIA event
registration in NVDA Alpha snapshots

Dear all,


As many of you may know, people using Microsoft Visual Studio or other applications mainly accessed by UIAutomation can experience some major lag while using them with NVDA. In an attempt to fix this, I've spent some hours in coming up with an approach that majorly improves performance in these applications. Thanks to great feedback from NV Access and them merging it, it can now be enabled in most recent NVDA Alpha snapshots by enabling the "Enable selective registration for UI Automation events and property changes" option in NVDA's advanced settings.


Taking Visual Studio as an example, with this option enabled, I notice major performance improvements in the following areas:

* Nuget package manager

* Loading/moving through the error list

* Options like go to base, go to implementation, go to definition. etc.

Performance improvements aren't limited to that though. To go a bit technical, rather than requesting for all UIA events and processing/discarding them in NVDA's process, we're now mostly only requesting events for objects of interest. This means that many events fired on other controls than the focused control aren't simply discarded by NVDA, but rather not even seen by NVDA at all, thereby taking out the processing time needed to discard them.

As there might be some regressions introduced by this feature, it is marked advanced/experimental. As I hope it eventually will become the default, I'd really appreciate it if you could report any bugs or regressions perceived with this feature enabled on NVDA's Github.


Kind regards,

Leonard

















Re: Introducing support for selective UIA event registration in NVDA Alpha snapshots

Marlon Brandão de Sousa
 

Looking at what you are doing it seems that knowing deterministicaly all possible impacts in all apps will be very hard.


Is there a way to port the selective UIA event registration option to a per profile configuration?


If it is possible then the feature can be safely distributed because it can be turned off for applications that need the full registration and turned on for others, with all the associated performance problems you described here.

On 07/07/2020 03:53, Joseph Lee wrote:
Hi,
Re-initializing UIA handler thread is a performance nightmare - causes NVDA to freeze until the thread comes to life.
There are two possible routes I've investigated, both involving event handlers and a pointer to UIA element for the object in question (obj.UIAElement):
1. Re-register local event handler group for the specific element by calling UIAHandler.handler.removeEventHandlerGroup then UIAHandler.handler.addEventHandlerGroup in that order for each UIA event the object needs to deal with. Code that needs to run on NVDA 2020.2 beta and earlier must check existence of "addEventHandlerGroup" in UIA handler thread and see if selective event registration is enabled. But that's not quite flexible.
2. Instruct UIA handler thread to listen to events for the specific element: this can be done by calling UIAHandler.handler.addLocalEventHandlerGroupToElement. The good news is that unlike option 1, you don't have to specify exactly which event handler group you want to register the element with. The big downside is that if an application generates new UIA elements (say, when a list opens each time something happens), calling UIAHandler.handler.removeLocalEventHandlerGroupToElement will NOT remove elements in the internal elements set - you must clean them up by cycling through the set of locally registered elements by criteria such as process ID, automation ID, UIA class name and such, followed by removing found elements (process ID is more reliable than automation ID because multiple processes may come with elements proclaiming the same automation ID; this isn't recommended but sometimes this is seen with some Windows 10 apps, even those from Microsoft).
For folks who may not know what Leonard, Bill, and I are talking about:
An event handler group is a collection of events for a UIA element. When a UI Automation client such as NVDA starts, it informs UIAutomationCore.dll that the client needs to listen to events coming from any UIA element, ranging from the currently focused element to the whole UIA tree (everything). In the past, a UIA client would register event handlers one at a time. Starting with Windows 10 Version 1809 (October 2018 Update) and Server 2019, a more convenient way to organize events called "event handler group" was introduced (part of IUIAutomation6 interface). The biggest benefit is that rather than registering one event handler at a time, multiple event handlers can be registered at once, thereby improving performance (unless UIAutomationCore.dll itself is stalled).
As part of his work, Leonard added event handler group support in UIA handler (basically a COM thread). But knowing that many users are still using older Windows releases (Windows 7 Service Pack 1, Windows 8.x, Windows 10 prior to Version 1809), a fake event handler group class is introduced to simulate the actual IUIAutomation6::EventHandlerGroup behavior: trying to register multiple events at once. The code in question goes one step further by teaching NVDA to listen to events coming from system focus and its ancestors only (parent object, or the route from the desktop object to the foreground object, and in turn from the foreground window to the focused control). Although it does introduce performance benefits, it needs to be validated by further testing by testers.
The ideal testing scenarios would be:
* Traveling through UIA universes i.e. testing apps such as Visual Studio where many UIA events are fired by many things at once.
* Reading overlays i.e. modern input features, touch keyboard, among others.
* No regressions, especially for people using Windows 7 and 8.1 (not Windows 8.0 because it is end of life since January 2016); although not recommended, you should test the code on unsupported Windows 10 releases (1507, 1511, 1607, 1703) if needed.

The way I test this code is (note: you don't have to follow exactly what I'm doing):
1. Enable selective UIA event registration. YOU MUST SAVE SETTINGS AND RESTART NVDA AFTER DOING SO! Without this, UIA handler thread will not be able to enable event handler group support (this happens early in the handler thread initialization). An alternative way to do this without restarting NVDA completely is opening Python Console and typing "import UIAHandler; UIAHandler.terminate(); UIAHandler.initialize()" with each part on separate lines.
2. Use NVDA as normal.
3. If you do encounter issues, YOU MUST RECORD WHAT NVDA IS DOING! Please do record what you are doing and how NVDA responds versus what it should do (either mentally, electronically, physically).
4. Turn off selective UIA event registration (again, RESTART NVDA!).
5. Perform the tasks that would trigger an error in step 3. Compare and record what NVDA is doing now versus what it did with selective event registration enabled.
6. If the problem is indeed caused by selective UIA registration, do let us know immediately (here or on GitHub). Please provide NVDA version, Windows version, how you are reproducing the issue (complete with app name and version, keyboard commands if applicable), and how NVDA responded (speech, braille, etc.). Although folks might be able to guess correctly, more details would help us debug faster, make NVDA more reliable, open up more test cases, and sleep better at nights (programming and debugging all night isn't fun, folks).
Hope this clarifies a lot of things.
Cheers,
Joseph


-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Monday, July 6, 2020 10:59 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Hey,


The problem here is that it isn't very easy to switch between the global and local event registration. It requires removing all UIA event handlers and registering them again, which somehow fails, probably due to a comtypes bug. Alternatively, it could be possible to re-initialize the UIAHandler, but even of that I'm not sure, I recall that was also causing issues for me.


Regards,

Leonard

On 06/07/2020 22:20, Joseph Lee wrote:
Hi,
Not easy, but it can be done at the event handler level (that's the route I'm taking with modern input features at the moment).
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Bill
Dengler
Sent: Monday, July 6, 2020 1:09 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event
registration in NVDA Alpha snapshots

Hi,
Is it possible to disable this on a per-process level?
I've written an app module (a self-contained version of #10910) that needs to react to background windows from the app.

Thanks,
Bill
-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph
Lee
Sent: Monday, 6 July 2020 02:20
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event
registration in NVDA Alpha snapshots

Hello everyone,
Folks on NVDA add-ons list may have seen the below message, but just to reiterate:
For people using Windows 10 App Essentials: you'll notice that if you do enable the option described here, you won't be able to hear emoji panel changes as you scroll through emoji categories. I'm testing a potential temporary fix, which will be rolling out to development snapshot users soon.
As noted by Leonard, please do file issues on GitHub should you notice regressions.
Cheers,
Joseph


-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard
de Ruijter
Sent: Sunday, July 5, 2020 11:11 PM
To: nvda-devel@groups.io; program-l@...
Subject: [nvda-devel] Introducing support for selective UIA event
registration in NVDA Alpha snapshots

Dear all,


As many of you may know, people using Microsoft Visual Studio or other applications mainly accessed by UIAutomation can experience some major lag while using them with NVDA. In an attempt to fix this, I've spent some hours in coming up with an approach that majorly improves performance in these applications. Thanks to great feedback from NV Access and them merging it, it can now be enabled in most recent NVDA Alpha snapshots by enabling the "Enable selective registration for UI Automation events and property changes" option in NVDA's advanced settings.


Taking Visual Studio as an example, with this option enabled, I notice major performance improvements in the following areas:

* Nuget package manager

* Loading/moving through the error list

* Options like go to base, go to implementation, go to definition. etc.

Performance improvements aren't limited to that though. To go a bit technical, rather than requesting for all UIA events and processing/discarding them in NVDA's process, we're now mostly only requesting events for objects of interest. This means that many events fired on other controls than the focused control aren't simply discarded by NVDA, but rather not even seen by NVDA at all, thereby taking out the processing time needed to discard them.

As there might be some regressions introduced by this feature, it is marked advanced/experimental. As I hope it eventually will become the default, I'd really appreciate it if you could report any bugs or regressions perceived with this feature enabled on NVDA's Github.


Kind regards,

Leonard
















Re: Introducing support for selective UIA event registration in NVDA Alpha snapshots

 

Hi,
Re-initializing UIA handler thread is a performance nightmare - causes NVDA to freeze until the thread comes to life.
There are two possible routes I've investigated, both involving event handlers and a pointer to UIA element for the object in question (obj.UIAElement):
1. Re-register local event handler group for the specific element by calling UIAHandler.handler.removeEventHandlerGroup then UIAHandler.handler.addEventHandlerGroup in that order for each UIA event the object needs to deal with. Code that needs to run on NVDA 2020.2 beta and earlier must check existence of "addEventHandlerGroup" in UIA handler thread and see if selective event registration is enabled. But that's not quite flexible.
2. Instruct UIA handler thread to listen to events for the specific element: this can be done by calling UIAHandler.handler.addLocalEventHandlerGroupToElement. The good news is that unlike option 1, you don't have to specify exactly which event handler group you want to register the element with. The big downside is that if an application generates new UIA elements (say, when a list opens each time something happens), calling UIAHandler.handler.removeLocalEventHandlerGroupToElement will NOT remove elements in the internal elements set - you must clean them up by cycling through the set of locally registered elements by criteria such as process ID, automation ID, UIA class name and such, followed by removing found elements (process ID is more reliable than automation ID because multiple processes may come with elements proclaiming the same automation ID; this isn't recommended but sometimes this is seen with some Windows 10 apps, even those from Microsoft).
For folks who may not know what Leonard, Bill, and I are talking about:
An event handler group is a collection of events for a UIA element. When a UI Automation client such as NVDA starts, it informs UIAutomationCore.dll that the client needs to listen to events coming from any UIA element, ranging from the currently focused element to the whole UIA tree (everything). In the past, a UIA client would register event handlers one at a time. Starting with Windows 10 Version 1809 (October 2018 Update) and Server 2019, a more convenient way to organize events called "event handler group" was introduced (part of IUIAutomation6 interface). The biggest benefit is that rather than registering one event handler at a time, multiple event handlers can be registered at once, thereby improving performance (unless UIAutomationCore.dll itself is stalled).
As part of his work, Leonard added event handler group support in UIA handler (basically a COM thread). But knowing that many users are still using older Windows releases (Windows 7 Service Pack 1, Windows 8.x, Windows 10 prior to Version 1809), a fake event handler group class is introduced to simulate the actual IUIAutomation6::EventHandlerGroup behavior: trying to register multiple events at once. The code in question goes one step further by teaching NVDA to listen to events coming from system focus and its ancestors only (parent object, or the route from the desktop object to the foreground object, and in turn from the foreground window to the focused control). Although it does introduce performance benefits, it needs to be validated by further testing by testers.
The ideal testing scenarios would be:
* Traveling through UIA universes i.e. testing apps such as Visual Studio where many UIA events are fired by many things at once.
* Reading overlays i.e. modern input features, touch keyboard, among others.
* No regressions, especially for people using Windows 7 and 8.1 (not Windows 8.0 because it is end of life since January 2016); although not recommended, you should test the code on unsupported Windows 10 releases (1507, 1511, 1607, 1703) if needed.

The way I test this code is (note: you don't have to follow exactly what I'm doing):
1. Enable selective UIA event registration. YOU MUST SAVE SETTINGS AND RESTART NVDA AFTER DOING SO! Without this, UIA handler thread will not be able to enable event handler group support (this happens early in the handler thread initialization). An alternative way to do this without restarting NVDA completely is opening Python Console and typing "import UIAHandler; UIAHandler.terminate(); UIAHandler.initialize()" with each part on separate lines.
2. Use NVDA as normal.
3. If you do encounter issues, YOU MUST RECORD WHAT NVDA IS DOING! Please do record what you are doing and how NVDA responds versus what it should do (either mentally, electronically, physically).
4. Turn off selective UIA event registration (again, RESTART NVDA!).
5. Perform the tasks that would trigger an error in step 3. Compare and record what NVDA is doing now versus what it did with selective event registration enabled.
6. If the problem is indeed caused by selective UIA registration, do let us know immediately (here or on GitHub). Please provide NVDA version, Windows version, how you are reproducing the issue (complete with app name and version, keyboard commands if applicable), and how NVDA responded (speech, braille, etc.). Although folks might be able to guess correctly, more details would help us debug faster, make NVDA more reliable, open up more test cases, and sleep better at nights (programming and debugging all night isn't fun, folks).
Hope this clarifies a lot of things.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Monday, July 6, 2020 10:59 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Hey,


The problem here is that it isn't very easy to switch between the global and local event registration. It requires removing all UIA event handlers and registering them again, which somehow fails, probably due to a comtypes bug. Alternatively, it could be possible to re-initialize the UIAHandler, but even of that I'm not sure, I recall that was also causing issues for me.


Regards,

Leonard

On 06/07/2020 22:20, Joseph Lee wrote:
Hi,
Not easy, but it can be done at the event handler level (that's the route I'm taking with modern input features at the moment).
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Bill
Dengler
Sent: Monday, July 6, 2020 1:09 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event
registration in NVDA Alpha snapshots

Hi,
Is it possible to disable this on a per-process level?
I've written an app module (a self-contained version of #10910) that needs to react to background windows from the app.

Thanks,
Bill
-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph
Lee
Sent: Monday, 6 July 2020 02:20
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event
registration in NVDA Alpha snapshots

Hello everyone,
Folks on NVDA add-ons list may have seen the below message, but just to reiterate:
For people using Windows 10 App Essentials: you'll notice that if you do enable the option described here, you won't be able to hear emoji panel changes as you scroll through emoji categories. I'm testing a potential temporary fix, which will be rolling out to development snapshot users soon.
As noted by Leonard, please do file issues on GitHub should you notice regressions.
Cheers,
Joseph


-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard
de Ruijter
Sent: Sunday, July 5, 2020 11:11 PM
To: nvda-devel@groups.io; program-l@...
Subject: [nvda-devel] Introducing support for selective UIA event
registration in NVDA Alpha snapshots

Dear all,


As many of you may know, people using Microsoft Visual Studio or other applications mainly accessed by UIAutomation can experience some major lag while using them with NVDA. In an attempt to fix this, I've spent some hours in coming up with an approach that majorly improves performance in these applications. Thanks to great feedback from NV Access and them merging it, it can now be enabled in most recent NVDA Alpha snapshots by enabling the "Enable selective registration for UI Automation events and property changes" option in NVDA's advanced settings.


Taking Visual Studio as an example, with this option enabled, I notice major performance improvements in the following areas:

* Nuget package manager

* Loading/moving through the error list

* Options like go to base, go to implementation, go to definition. etc.

Performance improvements aren't limited to that though. To go a bit technical, rather than requesting for all UIA events and processing/discarding them in NVDA's process, we're now mostly only requesting events for objects of interest. This means that many events fired on other controls than the focused control aren't simply discarded by NVDA, but rather not even seen by NVDA at all, thereby taking out the processing time needed to discard them.

As there might be some regressions introduced by this feature, it is marked advanced/experimental. As I hope it eventually will become the default, I'd really appreciate it if you could report any bugs or regressions perceived with this feature enabled on NVDA's Github.


Kind regards,

Leonard














Re: Introducing support for selective UIA event registration in NVDA Alpha snapshots

 

Hey,


The problem here is that it isn't very easy to switch between the global and local event registration. It requires removing all UIA event handlers and registering them again, which somehow fails, probably due to a comtypes bug. Alternatively, it could be possible to re-initialize the UIAHandler, but even of that I'm not sure, I recall that was also causing issues for me.


Regards,

Leonard

On 06/07/2020 22:20, Joseph Lee wrote:
Hi,
Not easy, but it can be done at the event handler level (that's the route I'm taking with modern input features at the moment).
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Bill Dengler
Sent: Monday, July 6, 2020 1:09 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Hi,
Is it possible to disable this on a per-process level?
I've written an app module (a self-contained version of #10910) that needs to react to background windows from the app.

Thanks,
Bill
-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph Lee
Sent: Monday, 6 July 2020 02:20
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Hello everyone,
Folks on NVDA add-ons list may have seen the below message, but just to reiterate:
For people using Windows 10 App Essentials: you'll notice that if you do enable the option described here, you won't be able to hear emoji panel changes as you scroll through emoji categories. I'm testing a potential temporary fix, which will be rolling out to development snapshot users soon.
As noted by Leonard, please do file issues on GitHub should you notice regressions.
Cheers,
Joseph


-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Sunday, July 5, 2020 11:11 PM
To: nvda-devel@groups.io; program-l@...
Subject: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Dear all,


As many of you may know, people using Microsoft Visual Studio or other applications mainly accessed by UIAutomation can experience some major lag while using them with NVDA. In an attempt to fix this, I've spent some hours in coming up with an approach that majorly improves performance in these applications. Thanks to great feedback from NV Access and them merging it, it can now be enabled in most recent NVDA Alpha snapshots by enabling the "Enable selective registration for UI Automation events and property changes" option in NVDA's advanced settings.


Taking Visual Studio as an example, with this option enabled, I notice major performance improvements in the following areas:

* Nuget package manager

* Loading/moving through the error list

* Options like go to base, go to implementation, go to definition. etc.

Performance improvements aren't limited to that though. To go a bit technical, rather than requesting for all UIA events and processing/discarding them in NVDA's process, we're now mostly only requesting events for objects of interest. This means that many events fired on other controls than the focused control aren't simply discarded by NVDA, but rather not even seen by NVDA at all, thereby taking out the processing time needed to discard them.

As there might be some regressions introduced by this feature, it is marked advanced/experimental. As I hope it eventually will become the default, I'd really appreciate it if you could report any bugs or regressions perceived with this feature enabled on NVDA's Github.


Kind regards,

Leonard













Re: Introducing support for selective UIA event registration in NVDA Alpha snapshots

 

Hi,
Not easy, but it can be done at the event handler level (that's the route I'm taking with modern input features at the moment).
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Bill Dengler
Sent: Monday, July 6, 2020 1:09 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Hi,
Is it possible to disable this on a per-process level?
I've written an app module (a self-contained version of #10910) that needs to react to background windows from the app.

Thanks,
Bill
-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph Lee
Sent: Monday, 6 July 2020 02:20
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Hello everyone,
Folks on NVDA add-ons list may have seen the below message, but just to reiterate:
For people using Windows 10 App Essentials: you'll notice that if you do enable the option described here, you won't be able to hear emoji panel changes as you scroll through emoji categories. I'm testing a potential temporary fix, which will be rolling out to development snapshot users soon.
As noted by Leonard, please do file issues on GitHub should you notice regressions.
Cheers,
Joseph


-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Sunday, July 5, 2020 11:11 PM
To: nvda-devel@groups.io; program-l@...
Subject: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Dear all,


As many of you may know, people using Microsoft Visual Studio or other applications mainly accessed by UIAutomation can experience some major lag while using them with NVDA. In an attempt to fix this, I've spent some hours in coming up with an approach that majorly improves performance in these applications. Thanks to great feedback from NV Access and them merging it, it can now be enabled in most recent NVDA Alpha snapshots by enabling the "Enable selective registration for UI Automation events and property changes" option in NVDA's advanced settings.


Taking Visual Studio as an example, with this option enabled, I notice major performance improvements in the following areas:

* Nuget package manager

* Loading/moving through the error list

* Options like go to base, go to implementation, go to definition. etc.

Performance improvements aren't limited to that though. To go a bit technical, rather than requesting for all UIA events and processing/discarding them in NVDA's process, we're now mostly only requesting events for objects of interest. This means that many events fired on other controls than the focused control aren't simply discarded by NVDA, but rather not even seen by NVDA at all, thereby taking out the processing time needed to discard them.

As there might be some regressions introduced by this feature, it is marked advanced/experimental. As I hope it eventually will become the default, I'd really appreciate it if you could report any bugs or regressions perceived with this feature enabled on NVDA's Github.


Kind regards,

Leonard


Re: Introducing support for selective UIA event registration in NVDA Alpha snapshots

Bill Dengler
 

Hi,
Is it possible to disable this on a per-process level?
I've written an app module (a self-contained version of #10910) that needs to react to background windows from the app.

Thanks,
Bill

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph Lee
Sent: Monday, 6 July 2020 02:20
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Hello everyone,
Folks on NVDA add-ons list may have seen the below message, but just to reiterate:
For people using Windows 10 App Essentials: you'll notice that if you do enable the option described here, you won't be able to hear emoji panel changes as you scroll through emoji categories. I'm testing a potential temporary fix, which will be rolling out to development snapshot users soon.
As noted by Leonard, please do file issues on GitHub should you notice regressions.
Cheers,
Joseph


-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Sunday, July 5, 2020 11:11 PM
To: nvda-devel@groups.io; program-l@...
Subject: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Dear all,


As many of you may know, people using Microsoft Visual Studio or other applications mainly accessed by UIAutomation can experience some major lag while using them with NVDA. In an attempt to fix this, I've spent some hours in coming up with an approach that majorly improves performance in these applications. Thanks to great feedback from NV Access and them merging it, it can now be enabled in most recent NVDA Alpha snapshots by enabling the "Enable selective registration for UI Automation events and property changes" option in NVDA's advanced settings.


Taking Visual Studio as an example, with this option enabled, I notice major performance improvements in the following areas:

* Nuget package manager

* Loading/moving through the error list

* Options like go to base, go to implementation, go to definition. etc.

Performance improvements aren't limited to that though. To go a bit technical, rather than requesting for all UIA events and processing/discarding them in NVDA's process, we're now mostly only requesting events for objects of interest. This means that many events fired on other controls than the focused control aren't simply discarded by NVDA, but rather not even seen by NVDA at all, thereby taking out the processing time needed to discard them.

As there might be some regressions introduced by this feature, it is marked advanced/experimental. As I hope it eventually will become the default, I'd really appreciate it if you could report any bugs or regressions perceived with this feature enabled on NVDA's Github.


Kind regards,

Leonard


Re: Introducing support for selective UIA event registration in NVDA Alpha snapshots

 

Hello everyone,
Folks on NVDA add-ons list may have seen the below message, but just to reiterate:
For people using Windows 10 App Essentials: you'll notice that if you do enable the option described here, you won't be able to hear emoji panel changes as you scroll through emoji categories. I'm testing a potential temporary fix, which will be rolling out to development snapshot users soon.
As noted by Leonard, please do file issues on GitHub should you notice regressions.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Sunday, July 5, 2020 11:11 PM
To: nvda-devel@groups.io; program-l@...
Subject: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Dear all,


As many of you may know, people using Microsoft Visual Studio or other applications mainly accessed by UIAutomation can experience some major lag while using them with NVDA. In an attempt to fix this, I've spent some hours in coming up with an approach that majorly improves performance in these applications. Thanks to great feedback from NV Access and them merging it, it can now be enabled in most recent NVDA Alpha snapshots by enabling the "Enable selective registration for UI Automation events and property changes" option in NVDA's advanced settings.


Taking Visual Studio as an example, with this option enabled, I notice major performance improvements in the following areas:

* Nuget package manager

* Loading/moving through the error list

* Options like go to base, go to implementation, go to definition. etc.

Performance improvements aren't limited to that though. To go a bit technical, rather than requesting for all UIA events and processing/discarding them in NVDA's process, we're now mostly only requesting events for objects of interest. This means that many events fired on other controls than the focused control aren't simply discarded by NVDA, but rather not even seen by NVDA at all, thereby taking out the processing time needed to discard them.

As there might be some regressions introduced by this feature, it is marked advanced/experimental. As I hope it eventually will become the default, I'd really appreciate it if you could report any bugs or regressions perceived with this feature enabled on NVDA's Github.


Kind regards,

Leonard


Introducing support for selective UIA event registration in NVDA Alpha snapshots

 

Dear all,


As many of you may know, people using Microsoft Visual Studio or other applications mainly accessed by UIAutomation can experience some major lag while using them with NVDA. In an attempt to fix this, I've spent some hours in coming up with an approach that majorly improves performance in these applications. Thanks to great feedback from NV Access and them merging it, it can now be enabled in most recent NVDA Alpha snapshots by enabling the "Enable selective registration for UI Automation events and property changes" option in NVDA's advanced settings.


Taking Visual Studio as an example, with this option enabled, I notice major performance improvements in the following areas:

* Nuget package manager

* Loading/moving through the error list

* Options like go to base, go to implementation, go to definition. etc.

Performance improvements aren't limited to that though. To go a bit technical, rather than requesting for all UIA events and processing/discarding them in NVDA's process, we're now mostly only requesting events for objects of interest. This means that many events fired on other controls than the focused control aren't simply discarded by NVDA, but rather not even seen by NVDA at all, thereby taking out the processing time needed to discard them.

As there might be some regressions introduced by this feature, it is marked advanced/experimental. As I hope it eventually will become the default, I'd really appreciate it if you could report any bugs or regressions perceived with this feature enabled on NVDA's Github.


Kind regards,

Leonard


Re: Error running scons source

Nathaniel Schmidt
 

Glad my reply was helpful.  I was literally taking a stab in the dark.

Nathaniel

========================================
Nathaniel Schmidt
Undergraduate student
Bachelor of Computer Science (S306)
School of information Technology
Faculty of Science, Engineering and Built Environment
Deakin University, cloud campus
https://sync.deakin.edu.au/profiles/student/njschmidt

E: njschmidt@...
M: 0439591709
GitHub: https://github.com/njsch/
Skype: nathaniel_schmidt1994

7

On 4 Jul 2020, at 4:22 pm, Noelia Ruiz <nrm1977@...> wrote:

Hello, many thanks. You gave me the key to solve the problem and find
the appropiate components in the dialog.
I have my NVDA source tree ready now. :)
Unfortunately the app module which I wanted to submit as a PR doesn't
work when it's placed in source\appModules, just when it's included in
scratchpad.
I have commented this at
https://github.com/nvaccess/nvda/issues/11302

Best

2020-07-04 0:42 GMT+02:00, Nathaniel Schmidt <schmidty2244@...>:
Hi,

Not sure if this is necessarily the cause of your problem but I think you
also need the x86_64 components as well.

Nathaniel

========================================
Nathaniel Schmidt
Undergraduate student
Bachelor of Computer Science (S306)
School of information Technology
Faculty of Science, Engineering and Built Environment
Deakin University, cloud campus
https://sync.deakin.edu.au/profiles/student/njschmidt

E: njschmidt@...
M: 0439591709
GitHub: https://github.com/njsch/
Skype: nathaniel_schmidt1994

7

On 4 Jul 2020, at 6:06 am, Noelia Ruiz <nrm1977@...> wrote:

Hello:

I get the following error when running scons source to prepare NVDA's
source code:
scons: *** [build\arm64\IAccessible2proxy.dll] Error 1104
scons: building terminated because of errors.
I see that, in individual components for Visual Studio 2019, there are
several checkboxes with similar names related to:
* MSVC v142 - VS 2019 C++ ARM64 build tools
          * C++ ATL for v142 build tools (ARM64)
I have checked the first checkbox related to these components.
May this issue be related to this? What are the exact checkboxes that
should be selected?

I have created an app module to fix issue #11302, where I described a
bug with Thorium reader and I was trying to create a PR, so I tried to
test in NVDA source code before submitting it, after testing with the
app module placed in the scratchpad folder.
This app module maybe too small to be maintained as a separate add-on,
so I was trying to send a PR.
Thanks











Re: Error running scons source

Noelia Ruiz
 

Hello, many thanks. You gave me the key to solve the problem and find
the appropiate components in the dialog.
I have my NVDA source tree ready now. :)
Unfortunately the app module which I wanted to submit as a PR doesn't
work when it's placed in source\appModules, just when it's included in
scratchpad.
I have commented this at
https://github.com/nvaccess/nvda/issues/11302

Best

2020-07-04 0:42 GMT+02:00, Nathaniel Schmidt <schmidty2244@...>:

Hi,

Not sure if this is necessarily the cause of your problem but I think you
also need the x86_64 components as well.

Nathaniel

========================================
Nathaniel Schmidt
Undergraduate student
Bachelor of Computer Science (S306)
School of information Technology
Faculty of Science, Engineering and Built Environment
Deakin University, cloud campus
https://sync.deakin.edu.au/profiles/student/njschmidt

E: njschmidt@...
M: 0439591709
GitHub: https://github.com/njsch/
Skype: nathaniel_schmidt1994

Sent from my iPhone 7

On 4 Jul 2020, at 6:06 am, Noelia Ruiz <nrm1977@...> wrote:

Hello:

I get the following error when running scons source to prepare NVDA's
source code:
scons: *** [build\arm64\IAccessible2proxy.dll] Error 1104
scons: building terminated because of errors.
I see that, in individual components for Visual Studio 2019, there are
several checkboxes with similar names related to:
* MSVC v142 - VS 2019 C++ ARM64 build tools
* C++ ATL for v142 build tools (ARM64)
I have checked the first checkbox related to these components.
May this issue be related to this? What are the exact checkboxes that
should be selected?

I have created an app module to fix issue #11302, where I described a
bug with Thorium reader and I was trying to create a PR, so I tried to
test in NVDA source code before submitting it, after testing with the
app module placed in the scratchpad folder.
This app module maybe too small to be maintained as a separate add-on,
so I was trying to send a PR.
Thanks





Re: Error running scons source

Nathaniel Schmidt
 

Hi,

Not sure if this is necessarily the cause of your problem but I think you also need the x86_64 components as well.

Nathaniel

========================================
Nathaniel Schmidt
Undergraduate student
Bachelor of Computer Science (S306)
School of information Technology
Faculty of Science, Engineering and Built Environment
Deakin University, cloud campus
https://sync.deakin.edu.au/profiles/student/njschmidt

E: njschmidt@...
M: 0439591709
GitHub: https://github.com/njsch/
Skype: nathaniel_schmidt1994

7

On 4 Jul 2020, at 6:06 am, Noelia Ruiz <nrm1977@...> wrote:

Hello:

I get the following error when running scons source to prepare NVDA's
source code:
scons: *** [build\arm64\IAccessible2proxy.dll] Error 1104
scons: building terminated because of errors.
I see that, in individual components for Visual Studio 2019, there are
several checkboxes with similar names related to:
* MSVC v142 - VS 2019 C++ ARM64 build tools
           * C++ ATL for v142 build tools (ARM64)
I have checked the first checkbox related to these components.
May this issue be related to this? What are the exact checkboxes that
should be selected?

I have created an app module to fix issue #11302, where I described a
bug with Thorium reader and I was trying to create a PR, so I tried to
test in NVDA source code before submitting it, after testing with the
app module placed in the scratchpad folder.
This app module maybe too small to be maintained as a separate add-on,
so I was trying to send a PR.
Thanks




Error running scons source

Noelia Ruiz
 

Hello:

I get the following error when running scons source to prepare NVDA's
source code:
scons: *** [build\arm64\IAccessible2proxy.dll] Error 1104
scons: building terminated because of errors.
I see that, in individual components for Visual Studio 2019, there are
several checkboxes with similar names related to:
* MSVC v142 - VS 2019 C++ ARM64 build tools
* C++ ATL for v142 build tools (ARM64)
I have checked the first checkbox related to these components.
May this issue be related to this? What are the exact checkboxes that
should be selected?

I have created an app module to fix issue #11302, where I described a
bug with Thorium reader and I was trying to create a PR, so I tried to
test in NVDA source code before submitting it, after testing with the
app module placed in the scratchpad folder.
This app module maybe too small to be maintained as a separate add-on,
so I was trying to send a PR.
Thanks


Native support for tab controls?

Karl-Otto Rosenqvist
 

Hi!
I just received info from a developer of an application I'm trying to make more accessible with NVDA. There are two messages one can send to get info about what tab that's selected and info about the tab.

https://docs.microsoft.com/en-us/windows/win32/controls/tcm-getcursel
https://docs.microsoft.com/en-us/windows/win32/controls/tcm-getitem

Are there already support in NVDA to grab this information somehow or do I have to implement these messages?


Kind regards

Karl-Otto

--
Karl-Otto Rosenqvist
MAWINGU
Orgnr: 750804-3937
0701- 75 98 56
karl-otto@...
https://mawingu.se


Re: Using Windows Sandbox with NVDA?

Akash Kakkar
 

As now the sandboxie is open source now, let's what comes on the table

On 6/28/20, Akash Kakkar <akash.misc07@...> wrote:
Thanks Joseph.
Ya Sandboxie is awesome. I was using it untill some time back since 2012

On 6/28/20, DaVid <dhf360@...> wrote:
I don't like windows sandbox, I prefer to use sandboxie. But NVDA is
unreliable with this software.
Also Windows sandbox is included with windows pro only.
Any solution for this?

Sorry to comment this here. I sent a message a long time ago about
this topic, but no one replied.
The compatibility with screen readers is enabled. So, I don't know if
this can be solved with a configuration or is NVDA issue.
Sandboxie can be used correctly with JAWS.

Regards,
DaVid.