No matter what i do to the font and font size of the text within a text entry box, it always reverts back to the Articulate font, 12 point.
I've already noticed there are two ways to edit the font: You can click on the box and change the font, or you can edit the text and then change the font.
I've done both and every time it reverts back to Articulate 12pt.
Is this a bug? What's the work around? Highly annoying!
Since this thread includes a few different issues as I mentioned what'd I'd like to have you do is share a file with our Support engineers so that they could test it and confirm which element it may match with or if they're able to determine a fix.
I am also experience the originally posted issue (text in data entry fields returning to Articulate 12 pt after edits have been made).
I've found that if I can get one data entry field to have the settings I want (using the workarounds) I can then use the format painter to apply those settings to other data entry fields. So far they seem to stick, both in Preview and after the course has been published.
Figured I'd share in case it works for someone else.
I don't think you missed an email - I don't have a further update to share at this time. It is something I've shared with our team using the different reports mentioned here and once we do have additional information to share we'll certainly update the thread.
BTW- My only work around is to have no label on the field and add a separate textbox that acts as the label. Then, I just added a state trigger to hide the "label" textbox when the user click on the TextEntry field.
I too am using Alexander's workaround which seems to be doing what I want it to. Another potential option is to create a default value for your variable (for use as a prompt) instead of the separate "label" textbox Alexander mentions, i.e. insert a default value of "Insert name here" (or whatever). This then shows in the data entry field when previewing/publishing the project until the user overwrites the variable.
The problem with this is that when the user click in the data entry field they will have to manually delete the default value ("Insert name here") before entering their own values. I prefer the functionality of Alexander's option but this may work for what some people want to do without having spare textboxes sitting around.
This is a significant bug, and what frustrates me the most is that it has persisted for years.
Not only is it annoying, this particular product flaw makes development of simulations that require data entry, cumbersome and time consuming. None of the "customer based solutions" (while appreciated) have worked for me...and I have tried them all.
I find it quite unacceptable that Articulate has not addressed this issue; I sincerely hope it is resolved soon.
I don't know if you've had time to review this thread in it's entirety (it's a bit long, so I totally understand if you didn't!) but the issues were not consistently reproducible based on the initial postings here. We were able to reproduce them recently and as such reported it to our team and have included a link to this thread in the report with our QA team so that they're aware of the number of users being impacted. I'll be sure to provide an update in regards to the situations once I have additional information to share but I'm unable to offer a time frame in regards to that.
If you'd like us to confirm that your currently situation matches the issues identified in this thread, please feel free to share your .story file with our team here and describe what you're seeing vs. what you'd prefer to see.
I would like to share the file, but company policy won't allow it.
I have read quite a few of the postings in this thread and my issue matches those where the font reverts back to 12 pt whenever a text box is selected. This is particularly annoying because for my applications I have to adjust the position of Storyline text boxes to match up with the software fields I am simulating...and I can't position the text boxes until the font size and type is correct. As soon as I move the text box...it reverts back to the default font. Saving the text box with as a new default is inconsistent (works sometimes...sometimes not). Consequently, it is very difficult to produce the effect I need.
Hopefully we will hear an official solution from Articulate soon.
Thanks Paul for clarifying and let us know which element is causing you trouble. We'll keep folks posted in this thread, but I'm unable to offer a timeframe in regards to when I'll be able to share an update here. As long as you stay subscribed, you'll receive any notifications via email.
This is a significant bug, and what frustrates me the most is that it has persisted for years.
Not only is it annoying, this particular product flaw makes development of simulations that require data entry, cumbersome and time consuming. None of the "customer based solutions" (while appreciated) have worked for me...and I have tried them all.
I find it quite unacceptable that Articulate has not addressed this issue; I sincerely hope it is resolved soon.
I couldn't agree more, with every statement, if you paid me.
Me too. This could very well have been a deal-breaker for us concerning Storyline if I had thought to check the forums before purchase. As I have said before, most of our e-learning is computer simulations. The constant reverting back to Arial 15.5 when a text box is selected is unacceptable.
I am finding this bug to be highly annoying; particularly for simulations. I have tried every "solution" suggested above, but to no avail. You would think that after several years, an issue that has this much impact would be resolved.
Sorry you're running into this issue and we have reported it to our team. It took some time to narrow down the specific issues here, and I apologize for that - but now that we've got them clearly detailed and reported to our QA team it's in their hands for further investigation. Once we have any additional updates or information to share, we'll be certain to do so here. Anyone who is subscribed to the thread either by responding or using the "subscribe" button at the top will receive those updates automatically.
It is right at 3 months since I opened a case on the simulation font part of this issue. I continue cranking out my simulations, knowing that I have to go back and touch every single text entry box at least once more. It's in the hundreds of text entry boxes now.
Hi! We've also experience the issue of font changing within text entry fields and I've send a AS file to the supportteam to hopefully help them with the investigation of our problem. Hope to hear from them soon!
Thanks Carola and I see that you're working with Wilbert (Case # 00729958 for my reference) so we'll follow along as well and ensure that this case is connected to the issues mentioned here once Wilbert does the testing so that we can appropriately track and follow up with you.
Has anything been done on this bug? It is seriously impacting my
development and affecting my ability to deliver my product has efficiently
as I would like. The time it is taking to resolve this issue is totally
unacceptable.
Before you even ask for help, uninstall and reinstall Storyline. That will be the first thing you have to do anyway. I finally got my IT guys to do that, and it has changed nothing for me. YMMV.
I was getting ready to log a new ticket the other day on this with Articulate; I was creating a story depicting what was wrong. I had generated a try me of a simulation I was working on that had a lot of user entry fields. I had already replaced all the user entry fields with new created TEXT ENTRY FIELDS that operated correctly except for the big issue of not being the default position for the cursor when the user got to the screen instead they had to click on it.
So I copied one of the slides that I had engineered to appear correct to the user into a new story; then I copied and pasted into the same new story the same slide pre-engineering to illustrate to Articulate how it was not working correctly. I then went into preview to verify that everything looked correct…. and OMG the un-engineered slide was working correctly…… when I transitioned to that slide the cursor was defaulted in the text entry field and when I typed in the text it was not too big and it was not wrapping out of sight.
I was gobsmacked (for you yanks that’s astonished). I copied all of the slides from the original unedited try me story into the new story and they all worked correctly when I previewed it.
So now whenever I create a new try me simulation I copy it into a my new seed version (see attached) that works and then save it as a new story that has the correct functionality.
It has only been a few days but so far everything is working correctly.
195 Replies
Hi Sarah,
Since this thread includes a few different issues as I mentioned what'd I'd like to have you do is share a file with our Support engineers so that they could test it and confirm which element it may match with or if they're able to determine a fix.
Thank you Ashely. I've sent along a paired-down file to the Support Engineers.
I am also experience the originally posted issue (text in data entry fields returning to Articulate 12 pt after edits have been made).
I've found that if I can get one data entry field to have the settings I want (using the workarounds) I can then use the format painter to apply those settings to other data entry fields. So far they seem to stick, both in Preview and after the course has been published.
Figured I'd share in case it works for someone else.
Thanks Jennifer for sharing that here - and I'll make sure that workaround is documented in the report we filed as well.
You're welcome.
Thanks for "keeping tabs" on all of this.
@Ashley Terwilliger,
It's been two months since I posted on this thread and entered a case. Did I miss an email or is there no solution at this time?
Hi DJ,
I don't think you missed an email - I don't have a further update to share at this time. It is something I've shared with our team using the different reports mentioned here and once we do have additional information to share we'll certainly update the thread.
I too am using Alexander's workaround which seems to be doing what I want it to. Another potential option is to create a default value for your variable (for use as a prompt) instead of the separate "label" textbox Alexander mentions, i.e. insert a default value of "Insert name here" (or whatever). This then shows in the data entry field when previewing/publishing the project until the user overwrites the variable.
The problem with this is that when the user click in the data entry field they will have to manually delete the default value ("Insert name here") before entering their own values. I prefer the functionality of Alexander's option but this may work for what some people want to do without having spare textboxes sitting around.
This is a significant bug, and what frustrates me the most is that it has persisted for years.
Not only is it annoying, this particular product flaw makes development of simulations that require data entry, cumbersome and time consuming. None of the "customer based solutions" (while appreciated) have worked for me...and I have tried them all.
I find it quite unacceptable that Articulate has not addressed this issue; I sincerely hope it is resolved soon.
Hi Paul,
I don't know if you've had time to review this thread in it's entirety (it's a bit long, so I totally understand if you didn't!) but the issues were not consistently reproducible based on the initial postings here. We were able to reproduce them recently and as such reported it to our team and have included a link to this thread in the report with our QA team so that they're aware of the number of users being impacted. I'll be sure to provide an update in regards to the situations once I have additional information to share but I'm unable to offer a time frame in regards to that.
If you'd like us to confirm that your currently situation matches the issues identified in this thread, please feel free to share your .story file with our team here and describe what you're seeing vs. what you'd prefer to see.
Hi Ashley,
I would like to share the file, but company policy won't allow it.
I have read quite a few of the postings in this thread and my issue matches those where the font reverts back to 12 pt whenever a text box is selected. This is particularly annoying because for my applications I have to adjust the position of Storyline text boxes to match up with the software fields I am simulating...and I can't position the text boxes until the font size and type is correct. As soon as I move the text box...it reverts back to the default font. Saving the text box with as a new default is inconsistent (works sometimes...sometimes not). Consequently, it is very difficult to produce the effect I need.
Hopefully we will hear an official solution from Articulate soon.
Thanks
Thanks Paul for clarifying and let us know which element is causing you trouble. We'll keep folks posted in this thread, but I'm unable to offer a timeframe in regards to when I'll be able to share an update here. As long as you stay subscribed, you'll receive any notifications via email.
I couldn't agree more, with every statement, if you paid me.
Me too. This could very well have been a deal-breaker for us concerning Storyline if I had thought to check the forums before purchase. As I have said before, most of our e-learning is computer simulations. The constant reverting back to Arial 15.5 when a text box is selected is unacceptable.
Agreed. This, along with the odd font rendering in SL2, would have been deal breakers had my clients known about them.
I am finding this bug to be highly annoying; particularly for simulations. I have tried every "solution" suggested above, but to no avail. You would think that after several years, an issue that has this much impact would be resolved.
Hi Bryan,
Sorry you're running into this issue and we have reported it to our team. It took some time to narrow down the specific issues here, and I apologize for that - but now that we've got them clearly detailed and reported to our QA team it's in their hands for further investigation. Once we have any additional updates or information to share, we'll be certain to do so here. Anyone who is subscribed to the thread either by responding or using the "subscribe" button at the top will receive those updates automatically.
It is right at 3 months since I opened a case on the simulation font part of this issue. I continue cranking out my simulations, knowing that I have to go back and touch every single text entry box at least once more. It's in the hundreds of text entry boxes now.
Frustrating.
Hi! We've also experience the issue of font changing within text entry fields and I've send a AS file to the supportteam to hopefully help them with the investigation of our problem. Hope to hear from them soon!
Thanks Carola and I see that you're working with Wilbert (Case # 00729958 for my reference) so we'll follow along as well and ensure that this case is connected to the issues mentioned here once Wilbert does the testing so that we can appropriately track and follow up with you.
Thank you Mark! This saved what I had left of my sanity!
This post was removed by the author
Has anything been done on this bug? It is seriously impacting my
development and affecting my ability to deliver my product has efficiently
as I would like. The time it is taking to resolve this issue is totally
unacceptable.
Before you even ask for help, uninstall and reinstall Storyline. That will be the first thing you have to do anyway. I finally got my IT guys to do that, and it has changed nothing for me. YMMV.
I was getting ready to log a new ticket the other day on this with Articulate; I was creating a story depicting what was wrong. I had generated a try me of a simulation I was working on that had a lot of user entry fields. I had already replaced all the user entry fields with new created TEXT ENTRY FIELDS that operated correctly except for the big issue of not being the default position for the cursor when the user got to the screen instead they had to click on it.
So I copied one of the slides that I had engineered to appear correct to the user into a new story; then I copied and pasted into the same new story the same slide pre-engineering to illustrate to Articulate how it was not working correctly. I then went into preview to verify that everything looked correct…. and OMG the un-engineered slide was working correctly…… when I transitioned to that slide the cursor was defaulted in the text entry field and when I typed in the text it was not too big and it was not wrapping out of sight.
I was gobsmacked (for you yanks that’s astonished). I copied all of the slides from the original unedited try me story into the new story and they all worked correctly when I previewed it.
So now whenever I create a new try me simulation I copy it into a my new seed version (see attached) that works and then save it as a new story that has the correct functionality.
It has only been a few days but so far everything is working correctly.
This discussion is closed. You can start a new discussion or contact Articulate Support.