Problem with "@" in TextEntry


Im working with one interaction. The value or the right answer of the TextEntry is an email address.

When i test it and try to type the "@" with option+2 (Mac) or Altgr + 2 (Windows), doesn't write anything and select all the text. 

Can anyone help me out? 

Im in Guatemala, so, the lenguage of the keyboard is in spanish.

I want the user type an email address to pass the next step in the interaction.

Thank´s a lot... and congratulations, great piece of software!

22 Replies
Ashley Terwilliger-Pollard

Hi Erjen,

I'm able to type the @ symbol in using the "shift" key and the number 2 which is how I would normally type it on my Windows 8 system and PC keyboard. It's worth noting that some other keystrokes may be associated with web browser actions though - so you may need to look at that behavior and what keystrokes you're using to insert that symbol. 

Erjen Adriaensen

Hello Ashley,
Thank you for your reply.
I have an azerty type keyboard with Dutch - BEP (Belgian-Period) setting, it is not on the US qwerty setting.

On the US setting I can indeed use shift+2, on BEP setting shift+number 2 gives me exactly that... the number 2.

I can not expect every user to alter their keyboard to US qwerty settings because the software only allows typing @ or # in US setting and doesn't support the use of the AltGr key.

The AltGr key is used a lot for special characters by different countries.
France for example also uses azerty and types AltGr+0 to have an @.
Turkey and Germany use AltGr+Q for their @ symbol, Italy uses AltGr+ò. 
Belgium, Denmark, Sweden, Finland, Norway and Estonia use AltGr+2, etc...

A more complete list of the use of the AltGr key can be found here

To me, this is a serious Storyline flaw because you can only work around this issue so much and sometimes you just have to be able to type specific characters in an e-learning. The customer has no truck with this either, they just want to type the characters the way they are used to do it, regardless of their keyboardsetting.

Therefore I hope that Articulate can fix this in a future update.
Thanks in advance,

Ashley Terwilliger-Pollard

Hi Erjen,

Thanks for sharing that here - you learn something new everyday. :-)  I don't have that key as I don't have the same keyboard type, but I went ahead and shared this as a feature request on your behalf. In the meantime, you may want to indicate to your users if a course will require that symbol and therefore the US setting or keyboard type. 

Erjen Adriaensen

Hello Ashley,

Thank you for your swift reply and for making it a feature request, allthough in this case I'd rather call it a bug report... ;).
Being able to use the available keys on your keyboard to type into a text field (all be it a non-US keyboard) just seems rather self-evident. Especially if you want to make an e-learning that can be used in different countries and will be exported as such.
It would be great if the Storyline developers can incorporate this soon in Storyline 1 and 2 in a future update!
For the time being, I'll try to work around it somehow.
Thanks again,


Erjen Adriaensen


Unfortunately the problem still remains after 2 updates. :(
Non-US users (i.e. users with a keyboard that is not on the "US setting") are unable to use the following characters in a textfield:

"€, |, @, #, ^, {, }, ´, `, [, ]"

These are pretty common and well-used characters and it's unrealistic to assume that the whole world uses a US keyboard setting.

Please try to fix this as soon as possible. The problem has been signaled two years ago and it still remains... Storyline is not cheap so it is not unreasonable that users should be able to use their keyboards in their respective language settings...

Thank you in advance.


Justin Grenier

Good Afternoon, Erjen.

I was initially able to reproduce the problem you reported, and shared the behavior with our Quality Assurance Team for further examination.  When multiple folks in QA were unable to reproduce the problem, I took a closer look at my machine and found that a freeware utility that I use for screencasting was intercepting the AltGr+2 key combination.  I couldn't use AltGr+2 in Notepad either, which indicated to us that this problem was not specific to Storyline.  When I disabled this utility, the problem was resolved.

Upon further research, it turns out that this is a common problem.  Check out this discussion thread within Microsoft's community.  It seems that third-party tools often intercept AltGr+2, and a non-exhaustive list of tools that may do this is as follows:

We hope this is useful information.  Good luck with your project!

Erjen Adriaensen

Hello Justin,

Thank you very much for your reply. 
Since I'm able to use my Alt Gr key to type  " € | @ # ^ { } [ ] ´`~ \ " 
just fine not only here, but also in any other program or application (Word, PowerPoint, Outlook, Notepad, Dreamweaver, Photoshop, Flash, After Effects, Illustrator, you name it... ) 
I was sure the problem was Storyline related.
Especially because I can use these keys just fine in a normal standard textbox within Storyline, only when I use a data entry field so users can fill in their e-mail address, an amount of Euro's or if they have to fill in the right hexadecimal code, the Alt Gr key is disabled.
It is in fact not 1 key combination that does not work, every Alt Gr key combination does not work when I tested and previewed my slides.

I did some further testing and found out that within Storyline itself, the Alt Gr key simply does not work. (I.e. when I preview it within Storyline by slide, by scene or the entire project)
However... If I publish the entire project, strangely enough, all of these key combinations do seem to work!
I have tested this in a fully updated SL1 and SL2. Both with the same result.
On one hand it's good news that the Alt Gr key seems to work when published, on the other hand it's very time consuming and impractical to publish an entire project with dozens of slides every single time just to test one single slide.
Publishing is my last step, after I review and test every single slide by itself, therefore I didn't publish these problemslides before, it just seemed pointless given the fact that these wouldn't even work in previewmode...

So the issue is definitely within Storyline, but the problem lies somewhere within the preview settings.
It would be great if this could be verified and resolved in the next update of Storyline.
Thank you for your help and follow up.

Best regards,


Justin Grenier

Thanks for clarifying that the problem only happens in Preview, Erjen.  I was able to reproduce this behavior.

I have submitted this issue to our Quality Assurance team for their review. As a workaround, you may need to continue to test the published output rather than the Preview.

I cannot offer a time frame for when or if this issue will be resolved so please continue to take advantage of the workaround if you encounter this issue in the future.

Please let us know if you need anything else, and have a great day!

Marta Burda


I'm having similar problem, I think.

I created software simulation (test mode), in certain text entry slides I have to enter Polish characters (i.e. I have to press alt+l to get a special character ł).

When I publish the course, the problem is gone - I can type the character.

I'm working on the most recent version of SL2 (update 4).

Is there anything you can do about this inconvenience?

Kind regards,




Soren J Birch

Leslie, for Storyline 2 Preview mode the issue is not that 3rd party tools intercepts the keystroke.

Preview mode does not accept the combination of keys where AltGr + 2 is invoked. I noticed that as I did my Screen capture recording. As soon as I typed AltGr+ 2 to make a @ sign, the screen recording took it as some kind of event controlling keypress and generated a new slide or something. Captivate does the same actually. Isn't that odd?

Workaround for now is still to publish and review from there.