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.
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...
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, 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.
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,
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...
Thanks Erjen, and we have shared this with our QA team as a bug report so that they can look further into the behavior. I don't have an update to share at this time, but once we have additional information we'll post it here for you.
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:
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.
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!
Thanks again for your reply and follow up. I'm glad that the issue can be reproduced and hopefully there will be a solution for this included in the next update.
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?
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.
22 Replies
Hi Allan,
Welcome to Heroes. I need some clarification. Are you having trouble inserting the @ sign in the text box?
Always Happy to Help,
Adrian
Thanks for answering Adrian.
That's the problem, i can't insert the @ sign.
The only way so far, alt + 64 (ASCII code).
Thanks for the help.
Hi Allan,
Is your course being designed for Spanish speakers such as yourself?
How do you normally type the @ sign on your keyboard?
Adrian
Hi Adrian,
Yes, the course is for spanish people.
I type it normally with altgr + 2 (Win) or opt + 2 (Mac).
Allan
I'm having the same issue.
Apparently in 2 years time and even after the release of a new Storyline version, the issue still remains unsolved... :(
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.
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
http://en.wikipedia.org/wiki/AltGr_key
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,
Erjen
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.
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
Hi Erjen,
I certainly understand - and I hope to see it included too, especially as our team looks at expanding more internationally. :-)
Thanks for teaching me something new today!
Hi,
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.
Thanks Erjen, and we have shared this with our QA team as a bug report so that they can look further into the behavior. I don't have an update to share at this time, but once we have additional information we'll post it here for you.
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!
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,
Erjen
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!
Hello Justin,
Thanks again for your reply and follow up. I'm glad that the issue can be reproduced and hopefully there will be a solution for this included in the next update.
Best regards,
Erjen
Hi,
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,
Marta
Thanks for letting us know how the problem impacts you, Marta. We'll keep this Forum Thread updated with any developments.
Any news? The problem persists. This is a basic limitation. It it solved?
Hi Hugo!
Did you check out the information that Justin shared above in regards to some third party tools that could be causing issue?
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.
Thanks Soren. That is the issue that we have reported to our QA Team as well and this thread is attached for them.
This discussion is closed. You can start a new discussion or contact Articulate Support.