Creating UI Automation Client Applications (Cont.) UI Automation Events for Clients UI Automation lets clients subscribe to events of interest. This capability improves performance by eliminating the need to continually poll all UI elements in the system to see if any information, structure, or state has changed. | " |
The properties of an element are generic to all elements and not specific to a control type. Control patterns, discussed later, expose control-specific properties.
| " |
Efficiency is also improved by the ability to listen for events only within a defined scope. For example, a client can listen for focus change events on all UI Automation elements in the tree, or on just one element and its descendants. Client applications subscribe to events of a particular kind by using methods such as AddAutomationEventHandler or AddFocusChangedEventHandler to register an event handler These methods take a callback interface, which should be implemented in an object created by the client. A method such as IUIAutomationEventHandler::HandleEvent will then be called on the appropriate thread whenever the event occurs. On shutdown, or when UI Automation events are no longer of interest to the application, UI Automation clients should remove the events. They do so either by calling a removal method for specific events such as RemoveAutomationEventHandler or RemoveFocusChangedEventHandler, or by calling the RemoveAllEventHandlers method to remove all events. UI Automation and Screen Scaling Starting with Windows Vista®, users can change the screen resolution (in dots per inch or dpi) so that most UI elements appear larger. Previously, the scaling had to be implemented by applications. Now, the Desktop Window Manager performs default scaling for all applications that do not handle their own scaling. UI Automation client applications must take this feature into account. The UI Automation API does not use logical coordinates. Methods and properties either return physical coordinates or take them as parameters. By default, UI Automation applications that run at a screen resolution other than 96 dpi will get incorrect results from these methods and properties. For example, because the cursor position is in logical coordinates, the client cannot simply pass these coordinates to the IUIAutomation::ElementFromPoint method to get the element that is under the cursor. In addition, the application will not be able to correctly place windows outside its client area. The solution to this situation has two parts: - Make your client application aware of screen resolution by calling the Win32 function SetProcessDPIAware at startup. This function makes the entire process aware of screen resolution, so that no windows belonging to the process are scaled.
- Call GetPhysicalCursorPos to get the current cursor coordinates.
User Account Control and User Rights Finally, you need to consider User Account Control and user rights to ensure your client can access the information it needs. Before a user launches an administrative application the operating system prompts the user for consent to run the application with elevated user rights. Similarly, when a user attempts to perform a task that requires administrative user rights, Windows presents a dialog box that asks the user for consent to continue. This dialog box is protected from cross-process communication, so that malicious software cannot simulate user input. Only signed client applications are trusted to communicate with applications running at a higher user-rights level. To gain access to the protected system UI, applications must be built with a manifest file that includes a special attribute. This UIAccess attribute is included in the <requestedExecutionLevel> tag where the value of the level attribute is an example only, as follows: <trustInfo xmlns=
"urn:0073chemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="highestAvailable"
UIAccess="true" />
</requestedPrivileges>
</security>
</trustInfo>
The UIAccess attribute value is "false" by default; that is, if the attribute is omitted, or if there is no manifest for the assembly, the application will not be able to gain access to protected UI. With access to the system and target application’s UI, your client applications can navigate the UI, retrieve properties and control patterns for UI elements, and listen to relevant UI events. Matthew Karr |