[BUG] Type Into Activity does not support different keyboard layout

Okay so let me explain. I’m danish, and i use danish windows language but US-ANSI keyboard as it is way easier to code on.

Robot farm is Danish UI and Danish keyboard layout, it was US layout, but because of changes in out setup it has to be danish layout now.

Problem now is when the automations enter something i’ve coded on my system with US layout symbols is all wrong, ‘\’ becomes ‘<’. If i change robot farm back to US layout it’s fine again.

Now here is the kicker, automations developed on my co-workers PC who prefers danish layout runs fine on the danish layout robot farm, and you guessed it, his automations have the same typing issue if we change the robot farm to US keyboard layout.

Images is from the same robot farm system few minutes apart.
This is an automation developed on my machine that runs US keyboard layout


Here is the Type Into settings

in my mind, when the character is \ in the variable it should not be < when typed out depended on the windows keyboard layout

Everything is fully updated to latest activity version (not pre-release)

Should this be moved to bug report instead or am i screwing up some setting ?

I would try Set Text and see if that works better. It’s also generally better to use Set Text instead of Type Into, unless the UI Element doesn’t support Set Text.

isn’t support, we already tried

@loginerror any of your devs have an explanation?

Hey @Rasmus_J

Let me push it to our bug tracker and have our devs have a look. It doesn’t sound right.

Just to have more information, could you provide:

  • UIAutomation package version
  • Studio version
  • whether the same happens with the classical design

Do you get the same result with “SendWindowMessages” set to “False”? I have had issues with “nordic characters” before and setting this to false solved it, sometimes.

21.4.4

2021.4.3 (enterprise solution)

  • whether the same happens with the classical design

No difference if i run from a classic or modern folder
It’s been an issue for a long time, even before modern was introduced, but i’ve never had the time to report the issue.

1 Like

I’ve tried any possible combination of SendWindowMessage, Simulate and nothing, with the activate, click before, empty and so on, same issue all around.

I’ve even tried to change layout before opening a project so UiPath opens with the danish layout selected and when it runs it types < instead of \ even tho the variable is . the second i flip it back to US layout, which was set at the date of cretion of the project, it types it out correctly, without restarting UiPath.

and if i open a project made by my co-worker who runs danish layout and i run any of his projects, my layout has to be danish for it to type correct

That’s annoying! If you just need it to work until someone, or you, finds a permanent solution you could use “set to clipboard” and paste it into the field with “Type Into” - I know it isn’t pretty but that should work(hopefully) in the meantime.

@loginerror it seems like it’s been fixed for new projects since we upgraded to 2021.4.3 last week except for the SendWindowMessage, that this isn’t working right as @Obsev also noted

We just created two new projects, one on the US layout machine and one on the DK layout machine. All they do is open a notepad and do Set Text and then three Type Into (default, SendWindowMessage and SimulateType)

Then i ran both projects on my US layout machine, and the conclusion is, it doesn’t matter what layout the project was created on

But if you run an automation and you use SendWindowMessage on your activities, and in our case runs danish layout, a character like \ will become < instead.

I redid the other project that i exprerienced the massive issue with and it’s now been reduced to the above issue, but the save file box does support simulated so it’s fixed that way.

But your devs should look into this issue about SendWindowsMessage and see if it’s fixable

Thank you, the issue is not properly recognized and will be scheduled for a fix depending on the existing priorities (can’t share anything specific).

I’ll update this topic when more will be known :slight_smile: