Trying a custom handler for several math fields

[Peter Haworth]

If I might add a comment here.  I believe Vaughn said he was working with
database applications.  If so, the trick is to do all the calculations
using the data returned from the database rather than the data displayed in
the fields,

That doesn't address the issue of formatting numbers as currency of course,
and it sure would be nice to have a built-in way to do that in LC.  Maybe
some extensions to the numberFormat property, or better still, a new
property that basically achieves the same purpose but is a permanent
property of a control along with something like "set the formattedText
of..." and "get the unformattedText of..."

Pete
lcSQL Software <http://www.lcsql.com>


On Sat, Sep 14, 2013 at 10:15 AM, Richard Gaskin <ambassador at fourthworld.com
> wrote:

> Vaughn Clement wrote:
>
> > Frankly I was surprised that LC did not recognize commas and money
> > symbols. This is a standard thing in almost any software that has
> > numbers being used? I would think it could be added to the object
> > inspector to set the money settings, and maybe still treat the field
> > as a string for purposes of calculations.
>
> I think this boils down to the difference between a general-purpose
> programming language like LiveCode (and C, Python, Lua, etc.), and more
> specialized tools like Excel and FileMaker.
>
> Since Excel and FileMaker were written in C, we could say that this is
> something that even C can handle.  But it takes a great many lines of C to
> be able to produce a system that separates storage from display, and while
> we can do this in LC with a fraction of the number of lines required, it
> still takes some scripting.
>
> Similarly, both Excel and FileMaker have automatic behaviors associated
> with cells/fields, but as you've found we need to explicitly respond to
> specific messages in LC to trigger behaviors like calculations.
>
> As convenient as these automated elements are in special-purpose tools,
> they greatly restrict the range of things that can be built with them. A
> spreadsheet will always look like a spreadsheet, and a FileMaker DB will
> also look and behave like a FileMaker DB (which is why we see so many LC
> devs making front-ends for DB systems like FileMaker, so they can deliver
> custom UIs not possible in those highly-specialized tools).
>
> All that said, as I noted before I think it would add tremendous value to
> LC to adopt an option to automatically separate storage format from display
> format for both fields and chunks, and have added my notes from my earlier
> post to the feature request for this:
> <http://quality.runrev.com/**show_bug.cgi?id=7891<http://quality.runrev.com/show_bug.cgi?id=7891>
> >
>
> In the meantime, we can have exactly what we're looking for right now with
> a bit of scripting.  I mention this not to suggest RunRev shouldn't invest
> the time to do that in the engine (since of course I do feel it would be
> very valuable), but only to note that there's nothing stopping anyone from
> having this today if they're willing to roll up their sleeves for an hour
> or two and work it out.  After all, there are many dozens of apps in the LC
> community that have done this already.
>
>
> --
>  Richard Gaskin
>  Fourth World
>  LiveCode training and consulting: http://www.fourthworld.com
>  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
>  Follow me on Twitter:  http://twitter.com/**FourthWorldSys<http://twitter.com/FourthWorldSys>
>
>
>
> ______________________________**_________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/**mailman/listinfo/use-livecode<http://lists.runrev.com/mailman/listinfo/use-livecode>
>