WinAppDriver
WinAppDriver copied to clipboard
SendKeys() using unknown keyboard configuration instead of local (azerty vs qwerty-like)
I'm using Appium to automate our new app. My first attempts is as simple as the code below. Here we use the AZERTY keyboard configuration.
However, the text entered in the app is with a QWERTY-like configuration, so "aaa" comes out as "qqq". My "regular" Selenium tests never had this issue. However, trying out all the keys gave me some weird results. For example, I get the colon character twice from different keys, but no dot character... So it's not a correct QWERTY either.
DesiredCapabilities appCapabilities = new DesiredCapabilities();
appCapabilities.SetCapability("app", "Company.NewApp_nhrabtd3q6ea2!App");
appCapabilities.SetCapability("platformName", "Windows");
appCapabilities.SetCapability("deviceName", "WindowsPC");
MobileFormsSession = new WindowsDriver<WindowsElement>(new Uri(WindowsApplicationDriverUrl), appCapabilities);
MobileFormsSession.FindElementByAccessibilityId("username").SendKeys("aaa");
currently only US keyboard layout is supported. We do understand what is going on here and would like to fix this.
@yodurr Agreed but isn't it partially a bug also (because I never get the dot, but colon twice)?
For those interested: the work-around is to copy text to the Windows clipboard and paste it. This keeps the text as passed in the test methods.
The copy past workaround won't work if driving an app remotely. Can you fix this bug. It's annoying to switch keyboard during development one for testing and one for developing. It's hard to test mutlilanguages application
I have the same issue. I am in Spain and when I run my program in Appium, if I do not change the keyboard language configuration to EN-US, my tests do not work.
Please, it would be interesting to fix this issue.
Can you update the keyboard language programmatically?
@Exoow Yes. I have not program it yet, but I know that exists ways to change this by code. Anyway, if this were implemented in the code, it would be a great improvement. I think when you write a text in a SendKeys function. the text should be sent as you wrote, not depending about the language configuration, right?
Hello, I have exactly the same error do you have a solution? Thanks
i have the same error do you have a solution plz?
if any one can help me plz
any updates???
Two years later, still can't write a test properly... 👎
I have a workaround on Windows 10 for this problem, but I hope this will be solved soon:
You can set a keyboard shortcut for the keyboard layout in Windows Settings -> Time & language -> Region & language -> Additional date, time, & regional settings -> Change input methods -> Advanced settings -> Change language bar hot keys.
I set US keyboard layout to ctrl+0 and my local keyboard layout to ctrl+1 and in my testcode I am using the shortcuts to switch the keyboard layout ...
// switch to US keyboard layout Actions switchKeyboardLayoutActions = new Actions(session); switchKeyboardLayoutActions.SendKeys(Keys.Control + "0" + Keys.Control); switchKeyboardLayoutActions.Build(); switchKeyboardLayoutActions.Perform();
// your send keys actions ...
// switch back keyboard layout switchKeyboardLayoutActions = new Actions(session); switchKeyboardLayoutActions.SendKeys(Keys.Control + "1" + Keys.Control); switchKeyboardLayoutActions.Build(); switchKeyboardLayoutActions.Perform();
can we get an update on this issue? it makes no sense to me that SendKeys does NOT send the keys you want, depending on your locale, and that something like that gets labeled as an enhancement, not a bug personaly, i was happy to learn that Katalon(which i use for automation testing) now supports WinAppDriver, but if i have to change my locale every time i want to test a windows application, then i won't be automating those anytime soon please let us either specify a locale for the WinAppDriver or get the current locale when starting the driver
Bump! This needs to be fixed...
We have VMs that we setup for automated tests, so a workaround that configures windows manually is not an option. Is there a way to switch the keyboard layout programmatically? Please fix this annoying bug.
Other layouts than US keyboard would be very handy in cases for non-english apps. It cannot be that you have to change the keyboard layout on the test machines to achieve this.
I'm having this issue also with - becoming + because I'm on a swedish keyboard layout. This should probably be prioritized since it seems to break alot of peoples tests.
This is a royal pain in the a**!
Same here. Gotta resort to windows API's ugly and fragile workarounds to change the keyboard.
Also, ActivateKeyboardLayout doesn't seem to work for me.
Same here, would love to get this fixed, any update?
Any update on this??? Same issue here with a machine using German layout.
Also, let me just comment that allowing different keyboard distributions does make a lot of sense in UI tests... For example, we have had weird bugs regarding decimal numbers being rendered in the UI, since in Germany they use ',' as decimal separator, whereas in other countries '.' is used
That is really a pity. I have the same issue. I would be very happy if you could solve the problem. Thank you very much in advance.
It boggles the mind that a product is released as production ready with a bug like this, which ties the tests written to the exact keyboard layout that the person who wrote the tests used. @yodurr any news on this?
Hey, It's been 6 years, is there any quick fix for that issue ?
I too have just run into this issue. I am using the WinAppDriver to control a open file dialog as part of some automated tests. I am trying to set the file path but because I have a English UK keyboard instead of C:\somefolder I get C:#somefolder which obviously is not much use. To arrive here after searching for a solution I am appaled discover this is such an old issue with no response. Shameful!
Would be nice to finally solve this issue.
Would be nice if Microsoft didn't recommend a testing framework, then abandon it while promissing that it really isn't abandoned.