data entry fields and decimals


I am having problems with numeric data entry fields in Storyline 360. Here is the problem:

I have set the trigger up so that if the input is equal to 922185.33 then a green tick shows up. The field does not recognise 922185.33 Instead it recognises 922185.3 as the  answer.

It does however work properly with the number 72185.33

Is my number just too big? I have tried changing the trigger so that if the input is equal to 922185.333 but the third three just disappears.



18 Replies
Alyssa Gomez

Hi there, Vic!

It looks like you have 9 total characters with a decimal point (so a decimal and 8 digits). The acceptable answer field should allow for 14 digits, so technically the number 922185.33 shouldn't cause any issues.  I'm going to clarify with my team about that discrepancy.  

I'll keep you posted on what I find out! Sorry about the trouble. 

Vic GLover

Ok - this is getting really weird... I tried with the next data set and same thing - the bigger numbers didn't register as correct (shown by green rectangle around answer).


So I did the reveal answer thing as above to see what happens - and these are the numbers it threw out (triggers for reference)



If I start the preview from scratch and enter the weird numbers that it populated the variables with, it recognizes them as correct.



The variables aren't used elsewhere

Any ideas? I just updated Storyline just in case that was the problem but it wasn't.



Leslie McKerchie

Hey Vic,

Thanks for reaching out and sharing some additional details. 

Alyssa has filed this as a potential bug for our team to take a closer look at. I do not have an update to provide at this time.

This conversation is attached so that we can pop in and update you here when we have additional information to share.

Trey McNabb

@Vic - thanks for starting this thread!

@ Leslie & Alyssa - thanks for making sure we're not lost!

We are running into similar problems with the number of digits. If there are more than 7 digits, the calculation starts rounding, even without decimals. For example, input 12345678 into box 1, with a trigger to add the contents of box 1 to a total, and have a text box display the total. The total display  shows 12345680.  Input 12345674 the total displays 12345670. If decimals are involved, eventually you see the 2nd place fall off as mentioned in Vic's comments.

I'm in state government, working with accountants and auditors, so seeing numbers that large really isn't something unexpected. All the examples we see on Heros using calculations and numeric input are using smaller numbers (i.e. car payments, weekly groceries, etc.)

I've attached a quick example file with notes.

We're starting to suspect it's the numeric variables being based on scientific notation, even if it's not converting to the same format for extremely long numbers.

Jimmi Thøgersen

@Trey - All of Storylines inbuilt operations (addition, multiplication, subtraction, division) will change the result to a precision of 7 significant digits (except for integer multiplication).

Not entirely sure why (haven't looked into it).

But yes, that means that any integer or floating point number with more than 7 digits (that aren't 0's added at the end) will lose precision when using "Storyline arithmetic". I.e. 12345678 (becomes 12345680) or 123.45678 (becomes 123.4568)

The only workaround I can think of, without starting to "fix" Storyline's player code yourself, is to do any calculations needing more in Javascript triggers. The variables can hold more precision - the same as Javascript normally can, meaning the largest "guaranteed precise" integer is 9007199254740991. It's the operations that do the rounding.

There are, however, some unrelated bugs in how Storyline stores numeric variables for resuming a course later. It won't store decimal digits at all, and integers beyond 4294967295 (32-bit) - possibly even half that number (i.e. signed 32-bit) - will be stored very randomly.

Trey McNabb

Hey Jimmi, thanks for popping in. I dropped this in just to have an additional example. We haven't encountered the random storage issue, but then we're not using it much except for one course we're creating. I'm working with my other developer to create the java to handle this. The storage by itself for calling the variable doesn't seem to be an issue for us. I'll use Java to do the math then return the response as a text variable for later use.

I think the part that's frustrating for most users who finally encounter it is we're all spoiled by how well math works in PP. lol


Trey McNabb

I've also just realized this is a change in behavior from SL 2 to SL 3. I found an old calculator from Preston Ruddell created in SL 2 for ELC #162 ( ) [*Note I had it in a download folder labeled REALLY COOL IDEAS] that does the calculations with a different numbers, but shows the actual answer. I tested it with 9 digits, and get the response I would expect.

Vincent Scoma

Hi Everyone,

I am happy to share that we just released the newest version of Storyline 360 (Build 3.36.21213.0) this morning! With this release, we fixed the numeric-entry questions that are evaluated incorrectly, even when learners entered the right answer.

The next step is to update Storyline 360 by heading to your Articulate 360 desktop app and clicking "Update" next to Storyline 360.

As always, we are happy to answer any questions you have by posting in this discussion, or you can contact our Support Engineers directly here.

Trey McNabb

Vincent - Sorry to report I updated my SL360 and tried the example I included in this thread, and still get the same results. If I enter a value of 12345678 and have it add to a total, the reported total is 12345680. If I add 123456.88, the reported value is 123456.9. I also just discovered the total changes if I put the values in the example in the opposite box.  For example, If I put 12345678 in box 1, then 123456.88 in box 2, I get 12469140 in the total. If I reverse these, I get 12469130 in the total.

Verified build 3.36.21213.0 in about.

Jimmi Thøgersen

Yeah, looking through the player code in update 36, nothing has changed in terms of calculations on variables. It still seems like someone added toPrecision without knowing exactly what it does (described in my previous post). There's no actual reason to use toPrecision that I can see. There might be a semi-valid reason (floating point wackiness - e.g. 0.1 + 0.2 = 0.30000000000000004) for rounding to e.g. 7 decimals, but that's not what toPrecision(7) does.

Leslie McKerchie

Hi Monika,

It's possible to add 4 numbers after the decimal when using a numeric entry field as well as a variable. The number variable will be looking for a whole number, but the text variable can handle the thousandths place.

I've attached a quick sample file and here's a quick demo:

Do you know what version of Storyline you're using?

You can check by going to:
Help > About Articulate Storyline

We are currently on Build 3.40.22208.0 of Storyline 360. You can read all of the details here.

Paul O'Connor

Is there any movement on this issue please?

I'm using Storyline 360 V3.48.24159.0 and still experiencing something similar - I've to validate against a number to 6 decimal places. To do this previously (for 4 decimal places) I've multiplied the input by 10000 then testing against a whole number, e.g. enter 59.3333 - scale up and check against 593333 - all works fine.

I've now got an example where the correct answer is 14.180024 - using the same logic as above by multiplying by 1000000 - when displaying the variable gives 14180020 rounding down the last digit. I've even tried using the same multiplier and testing against a decimal e.g. 141800.24 this gives 141800.2 dropping the last digit completely.