On TextChanged not firing when field changed by script

[stam]

Hi all,
according to the documentation, this

Is dispatched by the field whenever a user (or simulated user) action causes the content of the field to change.

I have a setup where a complex set of graphics that creates a summary parameter - i was hoping to use that as a trigger to update a database every time a value is changed, which will in turn change the summary parameter. i.e., instead of having to add the updating command to every graphic, i could just add it to the the field showing the summary parameter with an on textChanged handler.

Sadly this doesn't seem to fire - putting a simple script like

Code: Select all

on textChanged
   put "Changed!" into msg
end textChanged

doesn't ever fire.

Is there another way to achieve this all will i have to edit all the individual components that generate the parameter manually to trigger the update?

Many thanks
Stam

[richmond62]

I got that to work, but is was incredibly slow to react

LC 9.6.1, MacOS 11.3 beta 8

In the field script:

Code: Select all

on textChanged
   put "Text Changed"
end textChanged

Mind you that was when the end-user (me) typed into the field.

I set up a button with this script:

Code: Select all

on mouseUp
   put "xXx" after field "ff"
end mouseUp

when the button is clicked "xXx'" is appended to the text in field "ff", but the
textChanged script in the field script does NOT fire.

[stam]

when the button is clicked "xXx'" is appended to the text in field "ff", but the
textChanged script in the field script does NOT fire.

Thanks Richmond,

i too created a simplified example and like you created a button to put the long time in the field. The textChanged handler doesn't fire unless i manually change the field text; clicking the button puts the long time in the field but doesn't trigger the textChanged handler.

This is disappointing... not sure if this is a bug or if there is a workaround?

[FourthWorld]

IIRC the textChanged message was added for interaction only, to provide one-stop shopping for human interaction which would otherwise require a wide range of event handlers.

If you're changing text via a script, you could add a line right after that to do whatever else you need right in that same script.

[stam]

IIRC the textChanged message was added for interaction only, to provide one-stop shopping for human interaction...

thanks Richard - as i'm inherently lazy, I had been hoping that wasn't the case, as this field will be modified from any of about 30 other controls, which on the face of it would mean a lot of legwork/duplication, but I'll see if this can be abstracted to a behaviour for the modifying controls, might more feasible that way...

thanks for confirming, as that really isn't obvious from the documentation...
Stam

[FourthWorld]

Lazy is the mother of invention.

It's an interesting category of problem.

For one-to-many patterns the go-to is behaviors.

But what is a good model for many-to-one?

[dunbarx]

I know this is so old-fashioned as to be out of fashion, but I wrote a little gadget that uses the idle message to detect when a field content changes under script control. If this is of any interest, I will post the stack. It works fine, however much it harkens back to the late 80's.

Craig

[stam]

I suppose it wouldn't be too difficult to write a script that periodically checks for changes in the field. I.e. store previous value in script variable, compare with current variable and if a change then run the script that updates the database, then call itself again in xx time.

Bit messy though, would have been so much easier if textChanged just worked with any method of changing text, not just keyboard entry...
Also not liking the lack of control... i suspect i'll end up going with the heavy legwork option...

[dunbarx]

Stam.

I suppose it wouldn't be too difficult to write a script that periodically checks for changes in the field. I.e. store previous value in script variable, compare with current variable and if a change then run the script that updates the database, then call itself again in xx time.

Check out the post just above yours. I used "idle" as the engine to do just that.

textChangeByScript.livecode.zip

(1.12 KiB) Downloaded 118 times

Click on the button, and a new number appears in the top field. And by script, since the text of that field has changed, a new number appears in the bottom field. The text of the field is interrogated constantly by the "idle" message.

Craig

[dunbarx]

As a matter of opinion (mine) I also think that the textChanged message should be more universal. It should fire if the, er, text has changed, period.

Craig

[jacque]

I haven't tried it but I wonder if the "type" command would work to simulate manual entries. Instead of putting text into the field, type it. Or if you don't want the entry to visibly appear letter by letter, just type a space after the parameter is put there.

[dunbarx]

Jacque.

I think the OP wanted a textChanged message to fire if the text in a field was changed under script control, not by typing, pasting, dragging and dropping, or whatever.

It does not. As Richard pointed out, it was designed specifically to fire under user, not script control.

Craig

[stam]

Check out the post just above yours. I used "idle" as the engine to do just that.

Hi Craig - the documentation/dictionary advises against this. In their examples, the advise against using the idle handler like this:

Code: Select all

on idle -- avoid if possible
    global startTime
    if the seconds > startTime + 60 then -- 60 seconds have gone by
        put the time into field "Clock Face"
        put the seconds into startTime
    end if
    pass idle
end idle

The following example does the same thing more efficiently, since it only needs to handle a single message every sixty seconds:

on updateClock -- a better way
    put the time into field "Clock Face"
    send "updateClock" to me in 60 seconds
end updateClock

I guess they're suggesting it's more processor/memory intensive to keep polling with the idle handler, but really have no idea if that translates to a real issue.

But as you say it's a very similar method - but both seem messy to me and won't have immediate effect.

[stam]

As a matter of opinion (mine) I also think that the textChanged message should be more universal. It should fire if the, er, text has changed, period.

Craig

+1!

[jacque]

Jacque.

I think the OP wanted a textChanged message to fire if the text in a field was changed under script control, not by typing, pasting, dragging and dropping, or whatever.

I know. I'm talking about the "type" command that simulates a user manually typing into a field. This command sends all the same messages as a manual entry, which may also trigger the textChanged message.

Code: Select all

put empty into fld 1
select text of fld 1 -- place the insertion point 
type "new param" 

On the other hand, now that I think about it, this would have to be placed in every graphic control anyway so isn't any different than simply calling the update handler directly.