Being future proof is a laudable goal, but practical use cases ensure a solid implementation. It'd be good if you could provide some specific practical use cases where this would be useful. In contrast, one line per event requests would simplify readability but it involves calling add* functions each time addEventHandler function is called.
#Namechanger tracker plugin registration
What about specifying multiple events for different objects at once? One way is to make the functions accept an array of event records (event/NVDAEvent/PID/automationID/className), but this runs into readability and complexity issues but with the advantage that event registration becomes a for loop (can be done all at once).How could a user know which category an event belongs to? Although defining event type is useful, in order for this to be user friendly, a heuristic might need to be employed in the functions themselves to figure out which map an event belongs to.What if UIA is unavailable (XP and Vista)? A trivial fix is to let the functions above raise runtime exceptions.
One way to address this shortcoming is to somehow come up with a record that allows event handler to let certain objects receive priority (same approach as #3831), hence UIA ID's are needed in the end. This is more prominent with structure change event (see #6240) where a storm of them is fired constantly, thus degrading NVDA's UIA handler performance. Currently when an event comes in, it doesn't care where it comes from as long as there is a corresponding event defined in event map(s). This necessarily requires changes to uIAHandler.UIAHandler class, specifically when it comes to dealing with events themselves. EventID is a required parameter, with processID being used by app modules.
#Namechanger tracker plugin windows 10
For an actual working example, see Windows 10 App Essentials add-on. Currently, in order to request event tracking, one must know to which map an event belongs to, add the event ID and corresponding NVDA event name to the intended map, then tell UIAHandler.handler to call * function(s). To solve this dilemma, a number of routines are proposed, united under the idea that UIA handler should be enhanced to allow plugins and other subsystems to request UIA events for specific objects, as well as remove custom event routines in specific situations such as when an app module exits. Also, for performance reasons, certain UIA events are blocked by NVDA, and in order to accommodate them, a UIA version of eventHandler.requestEvents is needed.
For new universal apps and others, a common window class name is used throughout an app, with UIA elements using unique UIA ID's that does not fit the API agnostic model of #3831. Unlike IAccessible/MSAA, UIA uses its own set of properties to identify objects (termed "elements"), including framework ID, automation ID, unique UIA class name (if done properly) and so on. This works well for IAccessible objects and others where each object can be readily identified via window class name, but it is inadequate for UIA and other layers where objects share a common window class name.Ī particular concern is UIA, specifically newer style of applications. This is useful if one can isolate specific process ID's, window class name and name of the event requested, with the intention being to keep this API agnostic as much as possible (see comments on #6240). With the advent of #3831, it became possible for app modules, global plugins and others to tell NVDA to keep an eye on events for specific objects.
0 kommentar(er)
