WinAppDriver element not found

Question

I'm trying to use WinAppDriver, Appium & C# to do some UI automation on an ancient Delphi 5 application. It fires up the app, there's a little splash screen then a windows modal box for logging in. The usernames already filled out, so just type out the password and press the OK button.

var appCapabilities = new DesiredCapabilities();
appCapabilities.SetCapability("app", @"C:\APP\APP1998.exe");
appCapabilities.SetCapability("deviceName", "WindowsPC");
Session = new WindowsDriver<WindowsElement>(new Uri(WindowsApplicationDriverUrl), appCapabilities);
Assert.IsNotNull(Session);
Assert.IsNotNull(Session.SessionId);

Assert.AreEqual("APP1998", Session.Title.ToUpper());
Session.Manage().Timeouts().ImplicitWait = TimeSpan.FromSeconds(15);
Session.Keyboard.SendKeys("PASSWORD1");

These all fail:

//The logon dialog OK button
Session.FindElementByName("OK").Click();
//The File menu
Session.FindElementByName("File").Click();
//The Exit command from the File menu
Session.FindElementByName("Exit").Click();

I'm using WinAppDriver 1.0 and Appium 3.0.0.2 with Visual Studio, WinAppDriver and Inspect.exe running as admin.

Inspect shows the login screen and the splash screen as separate screens which are not connected in the tree.

The page source after you log in is:

  <?xml version="1.0" encoding="utf-16"?><Window AcceleratorKey="" AccessKey="" AutomationId="" ClassName="TApplication" FrameworkId="Win32" HasKeyboardFocus="False" HelpText="" IsContentElement="True" IsControlElement="True" IsEnabled="True" IsKeyboardFocusable="True" IsOffscreen="True" IsPassword="False" IsRequiredForForm="False" ItemStatus="" ItemType="" LocalizedControlType="window" Name="Mop1998" Orientation="None" ProcessId="11084" RuntimeId="42.1578230" x="0" y="0" width="1" height="1" CanMaximize="False" CanMinimize="True" IsModal="False" WindowVisualState="Normal" WindowInteractionState="ReadyForUserInteraction" IsTopmost="False" CanRotate="False" CanResize="False" CanMove="False" IsAvailable="True" />

Coming from a webdriver background, I can't see any ID's in there - no wonder it's not being able to find them or is that a misunderstanding on my part.

Is this app just too old for WinAppDriver? Should I give up?

Can you also post the exact error message when the `click` action fails? Alternatively, instead of looking for the element you can potentially click on the coordinates of the "OK" button. This always works, even on older programs. — Chuk Ultima, Mar 20 '18 at 09:15
The exception is: {"An element could not be located on the page using the given search parameters."} — PeterG, Mar 21 '18 at 09:45
No I don't want to go down that round - it makes tests brittle. — PeterG, Mar 22 '18 at 09:30

score 1 · Accepted Answer · answered Mar 20 '18 at 16:30

1

It's not the best option but I think you can use the sendkeys to access the OK button. Like Session.Keyboard.SendKeys(Keys.Alt + "o" + Keys.Alt); Since the access key is Alt+o. Alternately (IDK if this is gonna work) you can try to use the accessibilityId "3741054" as a accessibilityId like Session.FindElementByAccessibilityId("3741054");

answered Mar 20 '18 at 16:30

Yuri Costa de Oliveira

30
7

The weird thing is - the Accessibility ID changes on every run! So we can't use that. – PeterG Mar 21 '18 at 08:49
What does it shows on LegacyIAccessible.Name in inspect ? – Yuri Costa de Oliveira Mar 22 '18 at 15:23
A lot of the controls have nothing in them for that element. – PeterG Mar 23 '18 at 13:55
Did the .SendKeys(Keys.Alt + "o" + Keys.Alt) worked for the "OK" buttong? – Yuri Costa de Oliveira Mar 23 '18 at 15:57
I don't know if SendKeys helped the asker, but it got my ToolStripMenuItem working. – EC. Dec 20 '18 at 16:46

score 0 · Answer 2 · answered Jan 30 '20 at 12:25

you can use below snippet to handle splash screen and any kind of windows of desktop(like if you have two windows and want to switch)

var currentWindowHandle = driver.CurrentWindowHandle;
    Thread.Sleep(TimeSpan.FromSeconds(5));
            var allWindowHandles = driver.WindowHandles;
    driver.SwitchTo().Window(allWindowHandles[0]);

James · Answer 3 · 2020-06-18T13:07:42.787

0

I have had far more success with Actions class than using webdrivers baked in .Click() for interactions with WindowElement objects.

Also, searching by XPath with more than a single attribute to identify the object works far better, at least for me.

So, from my experience working with WinAppDriver everyday the last couple of years I would try:

new Actions(Session).Click(Session.FindElementByXPath("//*[@Name='OK' and @ClassName='TWAOkButton']")).Build().Perform();

edited Jun 18 '20 at 13:07

answered Jun 17 '20 at 14:21

James

19
3

Actions are sometimes the only way of clicking something and therefore your point is valid. I wouldn't say I have come across any Systems Under Test where Actions have MORE success than .Click() but there are a few SUTs where say a row in a table is greyed out but becomes enabled when you hover over it and therefore you cannot click until after the cursor is over the element. In those cases Action are required and .Click() won't work. I've never seen that on a login screen like the OP has but it's possible. – Ewan Feb 16 '22 at 09:32

WinAppDriver element not found

3 Answers3