Here is the repo of an issue I am facing trying to test an application with a splash screen.
I am trying to automate the following application (Revit)

You can download a free trial here for repo:
http://www.autodesk.com/products/revit-family/free-trial
Here is a link to my github repo with the code:
https://github.com/ianceicys/WinAppDriverSampleTests
I'm having similar issues working with a different BIM app (Tekla). In particular that status 13. error comes up and then I spend forever to get the thing running again. I've had some luck using the Session.SwitchTo when there are splash screens and popups. Just been trial and error to find the right thing to use, but its like the session isn't in the right place to find elements.
We have a similar issue with our application. We have added a command line argument for disabling the splash screen. However, is there a way to pass command line argument when starting the application session.
Hey Guys,
Any workaround for this problem. I've been struggling with this problem and want to know if anybody has any workaround for same.
"I was playing with one of my old WPF app where the starting point is set to splash screen. On that screen, am asking the user to log in and once the user is authenticated that screen would unload and open another screen which is basically the main app. I'm trying to automate this scenario but couldn't able to crack - how to start another session with another screen, basically. If I use existing session then getting error - "Currently selected window has been closed".
@rahul24, after investigating this, I found a workaround for my own WPF based, splash windows infested app. This works on my end.
My splash screen logs me in. After clicking the login button, I added this code
WaitForNewWindow(_session);
_session.SwitchTo().Window(_session.WindowHandles[0]);`
The WaitForNewWindow method is written thus
private static void WaitForNewWindow(IWebDriver session)
{
var windowHandle = session.CurrentWindowHandle;
const int retries = 120;
for (var i = 0; i < retries; i++)
{
Thread.Sleep(500);
if (session.WindowHandles.Count <= 0) continue;
if (windowHandle != session.WindowHandles[0])
return;
}
}
This will wait for a new window every 0.5 seconds and transfer the control back as soon as the new window is up and running. Of course, you may change the timeouts to fit your app.
@nitroxn聽there is currently not a way to pass a command line param to the app but we have it on the backlog to聽add such a feature.
Similar to what @daghb suggested, you can create a new Desktop session and find your window that way. @ianceicys聽in your RevitScenarios test I added the following after creating the RevitSession:
聽
聽 聽 聽 聽 聽聽 appCapabilities.SetCapability("app", "Root");
聽 聽 聽 聽 聽聽 RevitSessionDesktop = new IOSDriver
聽 聽 聽 聽 聽聽 RevitSessionDesktop.Manage().Timeouts().ImplicitlyWait(TimeSpan.FromSeconds(3));
Then in the test method this will find the聽View menu item and click it (I'm using Revit v2017):
var RevitMainWindows_2 = RevitSessionDesktop.FindElementByName("Autodesk Revit 2017 - [Recent Files]");
var RevitPane_1 = RevitMainWindows_2.FindElementByName("AdApplicationButton");
var RevitPane_2 = RevitMainWindows_2.FindElementByName("RibbonHostWindow");
var btnView = RevitPane_2.FindElementByName("View");
btnView.Click();
Thanks @daghb and @yodurr . Will try this and let you know.
THanks @yodurr and @daghb I'll try this and let you know! Enjoying the New Year Holiday.
@yodurr
I am facing a major issue ,not able to run the tests because of the below error
" An unknown error occurred in the remote end while processing the command."
When I try to run the tests , it throws this error and stops. So am not able to execute the tests.
On an average , out of 10 attempts i try to run the tests, it fails 7-8 times. Having hard time to run the tests. Please let me know if there is a fix or workaround for this issue in the next release
This is not related to the splash screen. There is no splash screen involved.
Note: I restart the WinAppDriver every time i run the test , still it fails with the issue " An unknown error occurred in the remote end while processing the command"
@viji-123 - can you check whether your last run resulted in a ghost EXE file after exiting the tests? From time to time, my WPF exe file seems to linger in a non-determined way when exiting the tests. Use the Task Manager to see if the process lingers. Also, from time to time, when running remote, the WinAppDriver fails to bind to other network interfaces than localhost if you are not absolutely sure it runs as admin.
@ianceicys were you able to try this again?
The error that was originally reported above is due to the way REVIT launches. The attached Windows Application Driver log showed that the application was successfully launched and an application window was found. Unfortunately as you all have pointed out, the splash screen was identified as the main application window since it was the very first window opened belonging to the application process. As soon as the splash screen is dismissed, any subsequent commands we send to it will result in no such window error as reported above.
I found @daghb's solution to be the best option as we already have a working session with the right AppId and processId. All we need to do now is to wait for the main window to appear using fixed delay or querying CurrentWindowHandle and WindowHandles. For example:
```c#
DesiredCapabilities appCapabilities = new DesiredCapabilities();
appCapabilities.SetCapability("app", YourAppId);
WindowsDriver
Assert.IsNotNull(session);
// Identify the current window handle. You can check through inspect.exe which window this is.
var currentWindowHandle = session.CurrentWindowHandle;
// Wait for 2 minutes seconds or however long it is needed for the right window to appear
// and for the splash screen to be dismissed. You can replace this with a more intelligent way to
// determine if the new main window finally appears.
Thread.Sleep(TimeSpan.FromMinutes(2));
// Return all window handles associated with this process/application.
// At this point hopefully you have one to pick from. Otherwise you can
// simply iterate through them to identify the one you want.
var allWindowHandles = session.WindowHandles;
// Assuming you only have only one window entry in allWindowHandles and it is in fact the correct one,
// switch the session to that window as follows. You can repeat this logic with any top window with the
// same process id (any entry of allWindowHandles)
session.SwitchTo().Window(allWindowHandles[0]);
@daghb had posted an example of how you can wait for the window handles to change. In a particular circumstance where your app will simply refocuses (won't launch a new instance) when re-launched, you may alternatively use `launchApp` instead of `switchTo` to have similar outcome as described in #213. Nevertheless, switching windows definitely gives you more control especially when there are more than one window opened.
In [v1.0-RC release](https://github.com/Microsoft/WinAppDriver/releases/tag/v1.0-RC), WinAppDriver introduced a new feature where you can [attach to an existing app window](https://github.com/Microsoft/WinAppDriver/blob/v1.0-RC/README.md#attaching-to-an-existing-app-window). While this is not necessary in the original scenario above, it may be a great option especially if the creation fails to begin with.
In this release, Windows Application Driver can also now launch an application with command line arguments. You can now specify command line parameter to disable splash screen when you see fit using this new feature. Below is an example of launching **Notepad** opening `MyTestFile.txt` in `C:\MyTestFolder\` working directory.
```c#
// Launch Notepad
DesiredCapabilities appCapabilities = new DesiredCapabilities();
appCapabilities.SetCapability("app", @"C:\Windows\System32\notepad.exe");
appCapabilities.SetCapability("appArguments", @"MyTestFile.txt");
appCapabilities.SetCapability("appWorkingDir", @"C:\MyTestFolder\");
WindowsDriver<WindowsElement> NotepadSession = new WindowsDriver<WindowsElement>(new Uri("http://127.0.0.1:4723"), appCapabilities);
The snippet above is taken from CreateSessionWithArguments_ClassicApp test scenario. Check out the README.md for more information on other supported capabilities.
Most helpful comment
@rahul24, after investigating this, I found a workaround for my own WPF based, splash windows infested app. This works on my end.
My splash screen logs me in. After clicking the login button, I added this code
The WaitForNewWindow method is written thus
This will wait for a new window every 0.5 seconds and transfer the control back as soon as the new window is up and running. Of course, you may change the timeouts to fit your app.