Trying a custom handler for several math fields

dunbarx at dunbarx at
Sat Sep 14 10:22:40 EDT 2013


If you simply enter "$50" in an excel cell and then add that cell plus "3" to another cell, it works fine. No explicit currency formatting needed. I think you said this. Excel has this knowledge built-in, Try it with "#50". But that only means that Excel understands the "$" sign, helping the user with a shortcut.

LiveCode does not, because it simply sees three characters in that "$50" string and takes it at face value. Livecode types its variables by context when you act on them. So if you add a number to "$50" you will get an error. If you add a number to "50", it is then that the engine types the string as a number.

It would be simple to this in LC., though one would have to vet each string before arithmetic evaluation. So you would trip up on:

add fld 1 to fld 2.

Because there is no way to trap the "add" command. As you said, another layer has to be added. Because we are dealing with strings.

But I was making a point to the OP, mainly about learning the basics of LC. He had a problem with dealing with strings such as "$50" in arithmetic.

Am I too blinkered with my stringiness?


-----Original Message-----
From: Geoff Canyon <gcanyon at>
To: How to use LiveCode <use-livecode at>
Sent: Sat, Sep 14, 2013 1:48 am
Subject: Re: Trying a custom handler for several math fields

On Fri, Sep 13, 2013 at 9:57 AM, <dunbarx at> wrote:

> Since LC uses strings as its base unit, it does require a bit more
> management. Of course, this also offers exquisite control over those
> strings.
> So although Excel, for example, knows that a value of "$50" in a cell is
> in actuality a number, LC does not. It is quite literal that way.

I don't think this quite reflects reality, in two ways:

First, as far as I know, LC doesn't use strings as a base unit. If you put
50 into X, LC (I believe) stores X as a number, and doesn't have to do any
conversion if you then add 2 to X. Of course, if you put "$50" into X, LC
is going to make X a string. Engine-eers, feel free to jump in.

Second, it's important to be clear about what Excel does/doesn't do. If you
put 50 in a cell, Excel stores the numerical value of 50. If you apply a
currency format to the cell, Excel displays the "$" in front of the 50, but
the cell is still 50 -- you can set another cell to be the square root of
that cell, and Excel won't tell you that the square root of $50 is
meaningless; it will just display 7.280109889.

If you put $50 in a field, Excel does the same thing as a shortcut: it
strips the $, and applies a currency format to the cell.

If you put '$50 in a cell, then Excel storing the literal string "$50" and
puts a warning on the cell, "Number stored as text." Interestingly, if you
set another cell's formula to 3 + your cell, Excel will try to accommodate
you and display 53. Note that if you do the same with either of the other
two cells (where the cell is actually storing 50) the cell you put that
formula in will store 53, but be automatically formatted as currency, and
display as $53.

Excel's cleverness would be tricky to replicate in LC -- not because LC
can't do each of the above things, but doing them in a way that "just
works" the way Excel's formatting does is (as far as I know) not built-in.
Off the top of my head, for maximum robustness and flexibility, I'd create
two fields, and hide one of them. If that one is called V for value, and
the visible one is D for display, then putting this in the script for V:

on updateDisplay
   put "$" & me into fld "D"
end updateDisplay

would still allow you to do things like this:

add 4 to fld "V"
send "updateDisplay" to fld "V"

and get Excel-like functionality. Likewise, if you put this in fld "D"s

on textChanged
   put goodNumber(me) into fld "V"
end textChanged

... and your goodNumber function somewhere in the message path, you'd be
able to edit the visible value in fld "D", and still derive the numeric
value to put back into fld "V" All of that would need to be cleaned up and
abstracted from a given pair of fields in order to be truly useful, but for
this discussion it gets the job done.

use-livecode mailing list
use-livecode at
Please visit this url to subscribe, unsubscribe and manage your subscription 


More information about the Use-livecode mailing list