Detect when a field changes
ambassador at fourthworld.com
Mon Nov 18 15:08:17 CET 2013
Robert Brenstein wrote:
> On 16.11.2013 at 23:35 Uhr -0500 dunbarx wrote:
>> I am with you, and any honest LiveCoder ought to be as well. The
>> "textChanged" message should stand on its own feet, if it has any,
>> and do what it advertises.
> But then, if "textChanged" fires on any change, including scripted
> changes, we need to go through extra hoops to distinguish between
> user-input and script-based changes. The message as it is now means
> Text-Changed-by-User and allow us, for example, verify user input
> (and what if the verification routine programmatically corrects user
> input?). I am not sure that that would really be so useful in the big
> scheme of things.
This is a very interesting point, one I hadn't considered when the
conversation began but which I hope finds its way into any bug report on
this, if one's been filed, so the full scope of implications can be
With all due respect to dunbarx, I don't think the "honesty" or lack
thereof with any developer is in question here, nor should it be.
While there are from time to time bugs in LC, many times unexpected
behavior is the result of a different conceptualization of what a given
feature should do between the scripter using a feature and the RunRev
team member who implemented it.
With the textChanged message, it seems that it was implemented to
address a set of circumstances previously unknowable to us, the full
range of user interactions which can cause field contents to change.
Since any changes driven by scripts are fully knowable to the person who
wrote the scripts, this is a useful message for all other circumstances
driven by user actions, which could not otherwise be known at all
without expensive polling.
There has been some discussion of extending getProp and setProp to be
able to use those with built-in properties, and if we had that now then
Bill would have one-stop-shopping with the text property of the field.
But in the meantime, while I have no opinion on whether the scope of the
textChanged message should be extended, I do acknowledge that Robert's
point is potentially very important, given that for every circumstance
in which a more complete scope may be useful to some, for others it may
not be appropriate.
So for the here-and-now, if one needs to resolve this with the current
engine one solution might be to use factored code that sets text using a
single centralized handler, so all changes from any script happen in one
place, and the textChanged message covers every other user interaction.
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
Follow me on Twitter: http://twitter.com/FourthWorldSys
More information about the use-livecode