CODEWITHSUNDEEP
comui-automationmicrosoft-ui-automationuia
Patrik
Patrik

Reputation: 1346

Is there any internal timeout in Microsoft UIAutomation?

I am using the UI Automation COM-to-.NET Adapter to read the contents of the target Google Chrome browser that plays a FLASH content on Windows 7. It works.

I succeeded to get the content and elements. Everything works fine for some time but after few hours the elements become inaccessible.

The (AutomationElement).FindAll() returns 0 children.

Is there any internal undocumented Timeout used by UIAutomation ?

According to this IUIAutomation2 interface There are 2 timeouts but they are not accessible from IUIAutomation interface. IUIAutomation2 is supported only on Windows 8 (desktop apps only).

So I believe there is some timeout. I made a workaround that restarts the searching and monitoring of elements from the beginning of the desktop tree but the elements are still not available. After some time (not sure how much) the elements are available again. My requirements are to read the values all the time as fast as possible but this behavior makes a damage to the whole architecture. I read somewhere that there is some timeout of 3 minutes but not sure.

if there is a timeout, is it possible to change it ? Is it possible to restart something or release/dispose something ? I can't find anything on MSDN.

Does anybody have any idea what is happening and how to resolve ?

Upvotes: 4

Views: 1958

Answers (1)

AlbusMPiroglu
AlbusMPiroglu

Reputation: 653

Thanks for this nicely put question. I have a similar issue with a much different setup. I'm on Win7, using UIAutomationCore.dll directly from C# to test our application-under-development. After running my sequence of actions & event subscriptions and all the other things, I intermittently observe that the UIA interface stops working (about 8-10min in my case, but I'm heavily using the UIA interface).

Many different things including dispatching the COM interface, sleeping at different places failed. The funny revelation was I managed to use the AccEvent.exe (part of SDK like inspect.exe) during the test and saw that events also stopped flowing to AccEvent, too. So it wasn't my client's interface that stopped, but it was rather the COM-server (or whatever the UIAutomationCore does) that stopped responding.

As a solution (that seems to work most of the time - or improve the situation a lot), I decided I should give the application-under-test some breathing point, since using the UIA puts additional load on it. This could be a smartly-put sleep points in your client, but instead of sleeping a set time, I'm monitoring the processor load of the application and waiting until it settles down.

One of the intermittent errors I receive when the problem manifests itself is "... was unable to call any of the subscribers..", and my search resulted in an msdn page saying they have improved things on CUIAutomation8 interface, but as this is Windows8 specific, I didn't have the chance to try that yet.

I should also add that I also reduced the number of calls to UIA by incorporating more ui caching (FindAllBuildCache), as the less the frequency of back-and-forth the better it is for the uia. Thanks to the answer of Guy in another question: UI Automation events stop being received after a while monitoring an application and then restart after some time

Upvotes: 1

Related Questions