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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
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
