Richard, I'd love to see the behavior script. Soon I'll be needing something like that. I can roll my own, but will save a lot of time if there is a shareable version. Bill P
William Prothero http://es.earthednet.org > On Apr 25, 2017, at 9:53 AM, Richard Gaskin via use-livecode > <use-livecode@lists.runrev.com> wrote: > > Roland Huettmann wrote: > > > Here is a link for Excel cell formatting: > > > > <https://support.microsoft.com/en-us/help/264372/how-to-control-and-understand-settings-in-the-format-cells-dialog-box-in-excel> > > Good guidance - thanks for including the link. > > > > Millions of users know this formatting style. Why reinvent the wheel? > > Numberformat could eventually be enhanced to this direction... > > > > I still also wished to see it as a property-set of fields, but built > > in, not "just" as a custom property. Dreaming...). It is a simple > > user wish, not a recipe about how to do it. I understand that it is > > difficult to do. > > Like Lagi says, "Everything is easy for the man who doesn't have to do > it himself." :) > > Why not have both, "good" now and "best" later? > > Even if the core team were in a position to drop other priorities to add > formatting to fields, they couldn't do it any faster than a scripter who has > the advantage of doing it in LiveCode itself. > > There are many things only the engine team can do, and for those we have no > choice of what language they must be done in: the engine is written in C++, > so it requires a C++ expert to work on engine features. > > As a attractive as this proposal for field-level numeric formatting is, there > are many other tasks already in queue (it's been many years since I was able > to play a video in Linux, and others have their own lists of preferred > priorities as well). > > So even the most optimistic projection of engine team availability for this > field enhancement would be months down the road. > > But we could have this by this afternoon with a behavior script. > > Why wait? > > Sure, an engine-level version would execute faster, and it's worth doing for > language design and workflow reasons as well. > > But a very useful behavior script could be crafted in an afternoon, and it > would not only provide immediate value to those using it, but help with the > design considerations that would have to go into an engine-based property > later on anyway. > > So we could consider the behavior script a prototype, but even better it can > be used to provide immediate useful results. > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > ____________________________________________________________________ > ambassa...@fourthworld.com http://www.FourthWorld.com > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
