Trying a custom handler for several math fields

[Geoff Canyon]

On Fri, Sep 13, 2013 at 9:57 AM, <dunbarx at aol.com> 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
script:

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.

gc