Subject: Re: Don't amputate numberformat

[Mark Waddingham]

On 2017-04-24 14:13, Roland Huettmann via use-livecode wrote:
> Mike Kerner: "Well, that would be a nice thing to have in a field 
> widget,
> but I run into
> formatting issues with databases, as well, especially when sorting."
> 
> I do not know much about the internal workings of the machine, but 
> could
> such work be outsourced? Maybe someone could raise funding? I would 
> rather
> like to see the improvements in the core engine instead of as a LC 
> Builder
> widget since it is so basic.

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.

Trying to do a similar thing with the current field is a little more 
complex
because the field allows char level access to its contents.

In your previous post you suggested it would be nice to be able to do 
something
along the lines of:

   put "1.234" into field 1
   set the format of field 1 to "currency"

In this case, assuming the user's currency format was something like 
'£0.00' then
you would see '£1.23' in the field. (I don't think I can understate how 
neat
this would be).

However, the question to ask (and I've been asking myself in the back of 
my mind
since I read your post) is: what, in this context does 'put char 1 to 3 
of field 1'
mean?

Does it mean '1.23' or '£1.'?

The problem here is that which it should mean very much depends on what 
you
are wanting to do.

The idea of the feature is that it completely separates computational 
value (1.234)
from display value (£1.23) - however, fields have a large number of 
features which
work (and can only work) if it is based on display value.

For example, it would be slightly unsettling to a user if they could not 
select a
portion of '£1.23' to copy onto the clipboard - the way the field 
presents its selection
is using 'char X to Y' so that immediately gives us a constraint that 
the displayed
chars of the value would be used for char X to Y evaluation.

However, from a computational point of view, it is kinda important that 
the following
is true:

   put "1234" into field 1
   put char 1 to 4 of field 1 is "1234"

So that immediately gives us a constraint that it would have to be the 
computational
value that would be used for char X to Y evaluation. So we end up going 
back round
in a circle...

Warmest Regards,

Mark.

P.S. I should say that the above should not be taken as 'this is not 
possible to do',
more that a naive approach to doing it probably isn't going to work so 
something a
little cleverer is needed... And like most things, things which are a 
little cleverer
just require a little more application of the 'little grey cells' :)

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps