Question

I have winforms application that is signed and has manifest with level="requireAdministrator" uiAccess="false".
I want to start another application with hidden window and to work with it using UI Automation API.

        Process procinst = new Process();
        procinst.StartInfo = new ProcessStartInfo()
        {
            WindowStyle = ProcessWindowStyle.Hidden,
            UseShellExecute = true,
            ErrorDialog = true,
            Verb = "runas",
            FileName = appfilepath
        };           
        procinst.Start();

The new process with hidden window can be seen in Spy++ but not in UISpy and I cannot also find it using FindFirst method:

mainwnd = AutomationElement.RootElement.FindFirst(TreeScope.Descendants, new PropertyCondition(AutomationElement.NameProperty, "apptitle"));

When ProcessWindowStyle is Minimized everything goes fine, when it is Hidden - everything stops.
Is it expected UI Automation behavior? UI Automation cannot access hidden windows? Is there any way to hack it?

Was it helpful?

Solution 2

That's sad but that's true:

There is not really such a thing as an “invisible” or “background” elements in UIA – when an element is gone, it will no longer be in the UIA tree. This is a good thing for assistive technologies (less pruning of the tree required), but can be troublesome for UI Automation frameworks. Historically we would tend to cache UI elements so we could get back to them again faster. When needed, one could call a mix of ShowWindow and accSelect with SELFLAG_TAKEFOCUS. This no longer works. If, say, a tool window is tabbed and not in the foreground; our cached element for it will because invalid, and if it’s requested we need to a) bring it into the foreground and b) find the element from scratch again.

WPF in Visual Studio 2010 – Part 6 : Automated UI Testing

OTHER TIPS

According to MSDN, "programmatically hidden" UI elements should not be in the UI Automation tree.

In particular:

UIA_IsOffscreenPropertyId (30022) Identifies the IsOffscreen property, which is a Boolean value that indicates whether the automation element is entirely scrolled out of view (for example, an item in a list box that is outside the viewport of the container object) or collapsed out of view (for example, an item in a tree view or menu, or in a minimized window). If the element has a clickable point that can cause it to receive the focus, the element is considered to be on-screen while a portion of the element is off screen. The value of the property is not affected by occlusion by other windows, or by whether the element is visible on a specific monitor. If the IsOffscreen property is TRUE, the UI element is scrolled off-screen or collapsed. The element is temporarily hidden, yet it remains in the end-users perception and continues to be included in the UI model. The object can be brought back into view by scrolling, clicking a drop-down, and so on. Objects that the end-user does not perceive at all, or that are "programmatically hidden" (for example, a dialog box that has been dismissed, but the underlining object is still cached by the application) should not be in the automation element tree in the first place (instead of setting the state of IsOffscreen to TRUE).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top