Scroll the menu to find all the places to visit
NoteTab - Calculating Text
17 Feb 2009In my latest foray into NoteTab arithmetic I came across a curious fact around performing arithmetic calculations on a variable containing text. Whilst in purely mathematical terms an arithmetic operation on something that has a numeric value is a bit nonsensical, but NoteTab is a text editor…
H="Inc Text"
^!Set %Val%=FooBar
^!Prompt >^%Val%^%Val%<
This clip displays two prompts when run. The first prompt as one might expect displays “>FooBar<”. The second prompt however displays “>1<”!
Apparently any text is evaluated to zero when you try and perform a purely arithmetic operation on it. Which broadly speaking makes sense if you just think about a piece of text as having no arithmetic value (or “zero”).
So I came across this interesting point when I was taking a masked numeric input from a clip wizard. Take a look at the following clip.
H="Strange Result"
^!Set %Val%=^?{(M="099")Enter a value=2}
^!Inc %Val%
^!Prompt ^%Val%
Running this clip and accepting the default input of two you mjight expect should give you a final prompt of “3”, except you’ve spotted where I’m going with this and you know that it’s probably going to be something to do with adding numbers to text and so turn out to be “1” instead. Well … you’re absolutely right.
The result is 1 as the input mask (even though it is using optional numeric place holders after the first compulsory numeric place holder) simply pads the input value with spaces.
i.e.
The calculation should be of the form: 2+1=3
But we actually get: “2 “+1=0+1=1
The answer is therefore quite simple - remove the spaces…
H="Better Result"
^!Set %Val%=^$StrTrim("^?{(M="099")Enter a value=2}")$
^!Inc %Val%
^!Prompt ^%Val%
So the astute amongst you will have noticed that we are now trimming the input to remove spaces which should now nicely produce the desired result when we use the default of 2 giving us a final result of 3.
Errr…. except we still get a result of 1.
It seems that there’s either a bit of a bug or an evaluation order at work here that means we don’t actually end up trimming off the spaces. It seems we need an extra assignment step. The following clip does produce the desired result of 3.
H="Right Result"
^!Set %Val%=^?{(M="099")Enter a value=2}
^!Set %Val%=^$StrTrim("^%Val%")$
^!Inc %Val%
^!Prompt ^%Val%
So the moral of the story is ensure that your variables are purely numeric before you start performing arithmetic operations on them and make sure that if you need to trim user input for a numeric you assign it to a variable first before trying to trim.
