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

I'm having this issue now and it's two years down the track and 4 years from the start of this thread! Does the feature request function work? Seems crazy that this bug is still there after such a long time.

Thanks Lea for sharing the javascript code here with us! 

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:

Idid some research and I found JS solution:

Here is link:

https://dl.dropboxusercontent.com/u/26178433/No%20NaN%20output/story.html

And story file:

https://db.tt/p21265XY

Brenda,

The default value (that is set when you create the variable) really just determines the initial value of the variable before any other action changes it.  It doesn't "restore" the variable to this value in any way after the value is changed, so the default value is only useful for setting initial conditions when the app first starts.

Doug

Glad you found a work around.  However, wouldn't it work to set the numeric variable's default value to zero?

note: the condition check mentioned in the second paragraph above didn't come across:   It should read " IF less than or equal to 0, OR greater than 0"...  in other words, all numbers.

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

update:  feature request has been submitted.

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