Can I prevent "NaN" from appearing in numerical entry?

I gave this problem some more thought today, and did finally find a way to workaround this within SL (it seems), but the solution is somewhat complex. I've attached the story file for anyone interested in seeing/trying the implementation. The result is that I can detect a NaN entry (the basic problem we were discussing above), then overwrite the "NaN" display in the field with a more meaningful/desired default value (in this case, that's the number 0), and pop-up a feedback message indicating "invalid entry" as a way of getting good usability for this type of entry field. 

The core breakthrough here (at least for me) was realizing that the NaN condition could be detected by evaluating the entry value against the condition of all possible numbers (the conditions being IF less than or equal to 0, OR  greater than 0 ---  in other words, all numbers ---   this seems kind of obvious in retrospect). This is detected and acted on with a set of sequential triggers and intermediate variables as shown below.  (since the conditional choices in the trigger wizard do not support "Not" conditions for the comparative operators, the logic ends up needing to be a lot more complex than it would have been otherwise, because I can only detect and qualify a trigger based on the entry being a number, rather than on not being a number). 

The logic is based on a boolean "isNaN" flag variable that gets initialized to true, and is then reset to false if the entry is a number using the conditions mentioned above ---  this will evaluate each time an entry is made. The sequence (order) of some of the triggers that are driven by a change in the "copyOfEntry" variable is crucial -- this is a good example of how multiple triggers (based on the same event) need to be laid out in a precise order, and how that order of execution can be used to your advantage. The intermediate "copyofEntry" variable was needed as a proxy variable for the raw input value, otherwise the action of resetting the raw variable to zero (when NaN occurs) causes a sort of recursive event loop problem (if only one value variable is used).  The feedback message is implemented on a layer. The two added "numeric entry" object triggers are needed (one for loss of focus, and one for the enter key) so that either clicking outside the field or hitting enter will cause the value to be processed as a new input.

If anyone can see an easier path to achieving this, I'd love to see this simplified, but this does seem to do the trick for me at least. While this works, it does seem like logic overkill for simply dealing with the NaN issue.. It would be much better if the NaN condition could be added to the SL condition options dropdown for numeric variables to make such handling a piece of cake.....  and it would be nice if "Not" operators were allowed to be optionally added in front of the conditional operators (that would have cut the complexity here in half). A feature request has been submitted for such NaN condition checking.

- Doug

Another possible way to avoid nan is by using an execute JavaScript trigger after the setting the variable value:

This is the JavaScript code to run:

Hey Simon, I had the same problem and I tried to leave with a 0, this way, in a group it can calculate the sum of the fields.
I see that this conversation is from 5 years ago, so I hope you had solved XD, but if can be useful for other people I did this:

IF( NOT( {string} > 0) , 0 , {string})

Maybe switching to text entry gives more control over "incorrect" entries?  Will try later.

But if that was the case, then surely you'd have this issue when having to us numerical entry, e.g. for calcs etc.  If you still want to collect numbers but don't need to calc them then I guess you're okay.  

I'd like to see an answer to this as well.  If a user backspaces over the 0 or whatever value is in a numerical entry field, and then clicks outside the box or hits enter for whatever reason before making an entry, "NaN" will show up in the field, indicating there was a non-number entry attempt.  This is a bit of a usability problem in that there is no way to override this with a more user-friendly phrase like "number required" or "invalid entry" or just a default of  "0" in the case of somebody clearing/backspacing and clicking out with no entry at all.  To many non-programmer users, "NaN" is meaningless and could be very unexpected and confusing to a user.

I tried to check for this as a condition in a trigger that would replace "NaN" with something else when it appears,  but it doesn't seem possible because the "equal to" value selector does not allow a value of "NaN" to be specified, since it's not a numeric value. And, if trying to compare it to a text variable set to "NaN" that doesn't work either because text variables are not allowed to be compared to numeric variables in the conditional expressions -- these restrictions make sense generally, but they also preclude any workarounds. .

Has anyone found a workaround for this?

Thanks,

Doug

IIRC, switching to text entry (instead of numerical) means "NaN" no longer appears.  At least I think that's the case seeing as I did this 3 months ago.  If you only want the learner to enter numbers then you can use conditions to ensure this is the case.

Simon --  yep, thanks, I get that for cases where treating numbers as text is sufficient.  The problem is that in many common use cases (as you mentioned earlier in the thread), there's a need to be able to process numeric entries as numbers --- ie, use numeric operators in the condition expressions for things like range checking, or to any kind of calculation. These operations require the use of numeric variables ---  then we're back to the NaN display issue.

If there was simply a way in the conditions menus to check for "NaN" as the current "value" of  a numeric variable, then we could replace NaN with something useful and understandable by all users (such as setting it to a proper numerical reset value and/or displaying "please enter a number" as feedback in an adjacent textbox for example.

Some solution for this is fairly essential, imo, for getting basic usability in place when numeric entries are involved.  I suppose if there's no direct workaround in SL itself, javascript could be used to check that variable for the "NaN" condition and then set other variables as needed for feedback or value reset.

Yep, can't argue with you there Doug.  This does need addressing.  Have you submitted a feature request?

Not yet, but a feature request probably makes sense for this issue, as it doesn't seem a direct solution exists currently.