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