I have a suite of tests that exercise a GUI project. The testing software is written in C# using the NUnit framework. The tests access the parts of the GUI by reducing its components to a series of AutomationElement objects. By manipulating these objects, I am able to exercise various functionalities of the GUI.
Recently I made some minor changes in the way our test suite runs. Since that time, tests that make use of the Open File dialog sometimes fail. By traversing the AutomationElement tree of the dialog, I see that the "Open" button is represented by a 'pane' rather than a 'button'. Note that this does not happen every time. Roughly half the time the tests are run, tests fail because of the Open File dialog, and the rest of the time the test results are clean.
Background Details:
The nightly suite is kicked off by a scheduled task on a Windows 10 computer with a locked screen. The screen must remain locked for security reasons.
I discovered early on that tests which require SendKeys.SendWait fail when running with a locked screen. Originally, we had used SendKeys.SendWait with Open File dialogs, but due to the locked screen restriction, we switched to traversing the AutomationElement tree of the dialog to populate the File Name edit box and click the Open button. This worked really well, so tests which required the Open File dialog could remain in the overnight test suite.
At one point, I ran the test suite manually from a directory on a drive which had automatic backup enabled. In this situation the Open File dialog element tree contained an Open pane rather than an Open button (as seen by traversing the tree with a TreeWalker object). The pane was empty and had no children. The button was being displayed properly and I could click it manually, but the AutomationElement tree did not show a button. The button on the GUI also had an extra dropdown that would have allowed me to select a previous version of the file, if I had wished.
After lots of debugging, I discovered that if I changed the focus, the AutomationElement tree recalculated itself, and the Open pane became a button in the element tree. So, my solution was to find an element in the dialog that could accept focus and set the focus there. This is how I refreshed the GUI in memory. To be clear, there was no need to refresh the GUI graphically on the screen--only in memory.
Current Problem:
As mentioned above, I am now experiencing a problem in the overnight tests that is similar, if not identical, to that which I first saw on the backed-up directory. The overnight tests are not running on a backed-up directory, but the element tree shows an Open pane rather than a button (same symptom, probably different cause).
During my investigation, I discovered that the setting-focus-on-another-element solution does not work with a locked screen. I verified this by manually running tests on the backed-up drive. The tests passed when the screen was unlocked (1st iteration through had a pane, 2nd iteration had a button after focus was set). The tests failed when the screen was locked (multiple iterations each had a pane, even after trying to set focus at the end of each iteration).
I found a related post here: UI Automation: Open File dialog elements tree contains not all elements. Unfortunately, the final resolution is to use SendKeys.SendWait, which I already stated won't work for us because of the need to run with a locked screen.
Other posts I found suggested using a mouse_event. So, I tried to use mouse_event to click somewhere on the GUI to move the focus. This did nothing on a locked screen.
Does anyone have a way to refresh the Open File dialog memory so that the Open button is not listed as an empty pane? Other strategies I haven't thought of?