Question about repeating events


Javi Domínguez
 

Hello.

I am making an appModule for an application. When the application shows a dialog whose accessibility I want to improve, an object receives the focus. NVDA speak that object twice because, as I have checked, it receives two event_gainFocus. Is there a way to handle these repeating events?

Thanks

Javi Dominguez


James Scholes
 

First thought: store a boolean flag on your app module (or overlay object or wherever). Set it to False initially. In your gain focus event handler, check the state of the flag. If False, set to True and let the event be processed as usual. If True, ignore the event. I haven't written this type of event-driven code in an NVDA add-on, so there may be a more best-practice way to do it.

Regards,

James Scholes

On 05/06/2021 at 12:13 pm, Javi Domínguez wrote:
Hello.

I am making an appModule for an application. When the application shows
a dialog whose accessibility I want to improve, an object receives the
focus. NVDA speak that object twice because, as I have checked, it
receives two event_gainFocus. Is there a way to handle these repeating
events?

Thanks

Javi Dominguez






Javi Domínguez
 

Hello, James.

Thanks. The flag is the first thing that I have thought about but it doesn't work.

The problem is that it only happens when the dialog is shown, when the object receives the focus using the tab it behaves normally. The flag has no effect.

Greetings

Javi

P.S. I'm thinking ... It's an overlaying object, maybe it overlays twice ... I'm going to look at it, sometimes it's happened to me.

El 05/06/2021 a las 19:16, James Scholes escribió:
First thought: store a boolean flag on your app module (or overlay object or wherever). Set it to False initially. In your gain focus event handler, check the state of the flag. If False, set to True and let the event be processed as usual. If True, ignore the event. I haven't written this type of event-driven code in an NVDA add-on, so there may be a more best-practice way to do it.

Regards,

James Scholes

On 05/06/2021 at 12:13 pm, Javi Domínguez wrote:
Hello.

I am making an appModule for an application. When the application shows
a dialog whose accessibility I want to improve, an object receives the
focus. NVDA speak that object twice because, as I have checked, it
receives two event_gainFocus. Is there a way to handle these repeating
events?

Thanks

Javi Dominguez







Javi Domínguez
 

In effect, the class is overlayed twice. That is why the flags do not work, when the class is overlayed again the flag is reset to False.

El 05/06/2021 a las 20:55, Javi Domínguez escribió:
Hello, James.

Thanks. The flag is the first thing that I have thought about but it doesn't work.

The problem is that it only happens when the dialog is shown, when the object receives the focus using the tab it behaves normally. The flag has no effect.

Greetings

Javi

P.S. I'm thinking ... It's an overlaying object, maybe it overlays twice ... I'm going to look at it, sometimes it's happened to me.


El 05/06/2021 a las 19:16, James Scholes escribió:
First thought: store a boolean flag on your app module (or overlay object or wherever).  Set it to False initially.  In your gain focus event handler, check the state of the flag.  If False, set to True and let the event be processed as usual.  If True, ignore the event.  I haven't written this type of event-driven code in an NVDA add-on, so there may be a more best-practice way to do it.

Regards,

James Scholes

On 05/06/2021 at 12:13 pm, Javi Domínguez wrote:
Hello.

I am making an appModule for an application. When the application shows
a dialog whose accessibility I want to improve, an object receives the
focus. NVDA speak that object twice because, as I have checked, it
receives two event_gainFocus. Is there a way to handle these repeating
events?

Thanks

Javi Dominguez







falkogiepmans@...
 

Was the overlaying twice intentional? I'm asking because I'm quite curious in what situation that would be useful.

Kind regards,
Falko
 
 


Doug Lee
 

What follows is based on my understanding of how NVDA objects and overlay classes work. Please correct as needed. This is a somewhat involved response to the question of why overlay objects may be created so often, and more
generally to the question of how to keep track of time-sensitive information related to an actual application element.

I believe an NVDA object is created for the focused item when it receives focus, but also at other times. I do not believe an NVDA object lives very long, as a rule. I also believe the exact timing of an NVDA object's
creation and lifespan are not guaranteed.

I believe that an overlay object is created when an NVDA object is created and destroyed when its corresponding NVDA object is destroyed. As such, I believe that the timing and lifespan of overlay objects is also not
guaranteed.

NVDA modules of course, including add-ons, live longer. In particular, I believe an NVDA add-on's module initializes every time the first instance of an application loads, perhaps each time the app loads even when it has more
than one instance; and terminates when the final, or each, instance unloads. (Obviously I'm not clear on the behavior when an app has multiple simultaneous instances.)

The longer lifespan of a module makes it likely a better place to keep scoreboard-type data, such as whether a particular item has spoken yet; but to do that, we would need a reliable way to identify a specific application
element. NVDA objects and overlay objects do not natively provide this.

I believe there is no "official" means of establishing whether two NVDA objects or overlay objects refer to the same physical entity within an application. There are, however, a few possible means of establishing this well
enough for use, though they may take some work.

First, UIA provides the RuntimeID int array that is meant to do this across the lifespan of each UIA element. I don't think that works for absolutely every UIA element out
there, but it probably works reliably in most modern apps.

Another alternative might be based on a chosen set of element properties, such as name plus screen location and size plus element type. This sort of approach can be
used for MSAA as well, where I think there is less support for element identity directly (there is the IAccIdentity interface, but I know very little of that one).

Note that, at least officially, comparing MSAA object references is not a valid means of establishing identity of an MSAA element. I imagine it may help sometimes to rule out failures; e.g., if two references are equal,
obviously the object is the same. I have not tested the utility of this approach under NVDA though.

On Mon, Jun 07, 2021 at 07:35:01AM -0700, falkogiepmans@babbage.com wrote:
Was the overlaying twice intentional? I'm asking because I'm quite
curious in what situation that would be useful.
Kind regards,
Falko



--
Doug Lee dgl@dlee.org http://www.dlee.org
Level Access doug.lee@LevelAccess.com http://www.LevelAccess.com
Don't be afraid your life will end; be afraid that itwill never begin.
-- Grace Hansen