Subject: Re: Don't amputate numberformat

[Bob Sneidar]

I had a whole system for doing this in another app. I should probably resurrect it. A user could right-click a field in pointer mode and with the normal contextual menu would also get options for setting some standard validations. The user could pick from pre, mid, and post validations. Pre would validate/format when the field was populated. Mid would validate/format when the user closed the field, and post would validate/format when the form was saved. The pre and post allowed values in the database to be different than the ones used by livecode, for instance the sql value of 1 or 0 for a column of type BOOLEAN, and the hilited of a button being true or false. The mid allowed for instance an integer of the proper length to be formatted as a phone number using the formatPhone() function I wrote for it. 

I have a library of nothing but format and validations like formatIP, isIP etc. 

Bob S


> On Apr 24, 2017, at 07:27 , Mark Waddingham via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> The field is a rather large, difficult and very very picky piece of engine
> code so pretty much nothing related to it is far from 'easy' to do. Of course, the
> 'how one would implement something' has to be preceded by 'how would such a thing
> work' and the latter is not entirely clear in this case...
> 
> Mike's suggestion of a 'field widget', I'd perhaps suggest would be a 'field'
> much more inline with a database 'field' - i.e. it would be a single thing
> which had a 'format' property (think type of column). The 'field' would hold
> a single value, and the 'format' would determine how that (typeless) value would
> be interpreted and rendered.