Detect when a field changes

[Richard Gaskin]

Robert Brenstein wrote:

> On 16.11.2013 at 23:35 Uhr -0500 dunbarx wrote:
>>Bill.
>>
>> 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 
considered.

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.

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  Follow me on Twitter:  http://twitter.com/FourthWorldSys