How to detect changed text in a field?
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
One thing that might help in understanding events in Revolution is that, in the example code I gave above, the SetFieldAndUpdate command is actually also an event, though it isn't using the "send" syntax.
Without the "send", the event can only go up the hierarchy, so the definition of the command has to be at least as high as the highest use of it, probably the card or stack.
When sending "down" the hierarchy, the send command is needed to direct the event to the right destination.
Without the "send", the event can only go up the hierarchy, so the definition of the command has to be at least as high as the highest use of it, probably the card or stack.
When sending "down" the hierarchy, the send command is needed to direct the event to the right destination.
~ Nonsanity
~ Chris Innanen
~ Chris Innanen
-
- VIP Livecode Opensource Backer
- Posts: 10052
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
Mr. Innanen's running two for two this evening. Good work.
The only thing I might contribute is an option to expand his suggestion using property syntax.
Like a good many other languages, Rev support virtual properties, with getProp and setProp handlers that are triggered whenever one of these virtual props is read or written to, respectively.
So for your setup you could put the data from the URL into the field using something like this:
set the uCurrentText of field "myField" to url tMyURL
And then in that field's script (or in the card or stack script of you need other fields to use the same behavior) you can put your accessors:
-- Sent to the object whenever the uCurrentValue property is set:
setProp uCurrentText, pValue
-- do whatever you like here
set the text of the target to pValue
end uCurrentText
-- Sent to the object whenever its uCurrentValue prop is read:
getProp uCurrentText
-- do other stuff here
return the text of the target
end uCurrentText
So by getting and setting the virtual property uCurrentText, you now have triggers which you can use to accomplish any other behaviors in addition to retrieving and/or storing the displayed text.
Using command-syntax handlers as Chris suggested is also a good way to go, and in this case I can't think of strong benefits of one over the other.
But since you've had some experience with OOP I thought you might enjoy at least knowing about this virtual property option, if not for the problem at hand then for something else down the road....
The only thing I might contribute is an option to expand his suggestion using property syntax.
Like a good many other languages, Rev support virtual properties, with getProp and setProp handlers that are triggered whenever one of these virtual props is read or written to, respectively.
So for your setup you could put the data from the URL into the field using something like this:
set the uCurrentText of field "myField" to url tMyURL
And then in that field's script (or in the card or stack script of you need other fields to use the same behavior) you can put your accessors:
-- Sent to the object whenever the uCurrentValue property is set:
setProp uCurrentText, pValue
-- do whatever you like here
set the text of the target to pValue
end uCurrentText
-- Sent to the object whenever its uCurrentValue prop is read:
getProp uCurrentText
-- do other stuff here
return the text of the target
end uCurrentText
So by getting and setting the virtual property uCurrentText, you now have triggers which you can use to accomplish any other behaviors in addition to retrieving and/or storing the displayed text.
Using command-syntax handlers as Chris suggested is also a good way to go, and in this case I can't think of strong benefits of one over the other.
But since you've had some experience with OOP I thought you might enjoy at least knowing about this virtual property option, if not for the problem at hand then for something else down the road....
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 10052
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
> can I use setProp and getProp over standard properties
> (e.g. variables or... text of field... Wink ).
Not as triggers, though you can add your votes to that request here:
http://quality.runrev.com/qacenter/show_bug.cgi?id=3126
But as we did with the built-in text property, you can get and set built-in properties from within getProp/setProp handlers, so for most purposes you can get pretty much the same thing by just using a different name.
> (e.g. variables or... text of field... Wink ).
Not as triggers, though you can add your votes to that request here:
http://quality.runrev.com/qacenter/show_bug.cgi?id=3126
But as we did with the built-in text property, you can get and set built-in properties from within getProp/setProp handlers, so for most purposes you can get pretty much the same thing by just using a different name.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Damn. Just goes to show how AWFUL the docs have been in Revolution. I just did a search on "properties" and then "property" and "setProp" didn't come up in either. I'd never even HEARD of the thing! 
(I haven't upgraded to 2.9, so I can't speak about the help there...)
I knew there were bound to be hidden features in those awful docs that I'd stumble across from time to time, but one as useful as THAT is just... It's just... #$%#$!%$#%#$!!!1!eleven!
Please tell me the 2.9 docs are better! (Not that I have the hundreds of dollars handy that RR demands for a mere point update.)

(I haven't upgraded to 2.9, so I can't speak about the help there...)
I knew there were bound to be hidden features in those awful docs that I'd stumble across from time to time, but one as useful as THAT is just... It's just... #$%#$!%$#%#$!!!1!eleven!
Please tell me the 2.9 docs are better! (Not that I have the hundreds of dollars handy that RR demands for a mere point update.)

~ Nonsanity
~ Chris Innanen
~ Chris Innanen
-
- VIP Livecode Opensource Backer
- Posts: 10052
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
FWIW, getProp and setProp show up among the See Also entries in the Dictionary entry for customProperties, which is one of the results of your search.
Making a search index for a language like this is tricky business; I wrote about 30% of the SuperTalk Language Guide and I don't wish that job on anyone.
But as both an author and a learner over the years, I've found the See Also section to be among the most helpful way to find related tokens. Whenever I've had to pick up a new language, I tend to search for whatever topical hits I can find, then check out the various See Alsos on each of those pages to get a good feel for related tokens I may not have been able to anticipate.
PS: AFAIK the upgrade from v2.8 to v2.9 is free.
Making a search index for a language like this is tricky business; I wrote about 30% of the SuperTalk Language Guide and I don't wish that job on anyone.
But as both an author and a learner over the years, I've found the See Also section to be among the most helpful way to find related tokens. Whenever I've had to pick up a new language, I tend to search for whatever topical hits I can find, then check out the various See Alsos on each of those pages to get a good feel for related tokens I may not have been able to anticipate.
PS: AFAIK the upgrade from v2.8 to v2.9 is free.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Hi all,
I don't think that bug 3126 is going to be honoured any time soon. The standard argument against requests like these is that it would have a big negative effect on Rev's performance in terms of speed.
Best,
Mark
I don't think that bug 3126 is going to be honoured any time soon. The standard argument against requests like these is that it would have a big negative effect on Rev's performance in terms of speed.
Best,
Mark
The biggest LiveCode group on Facebook: https://www.facebook.com/groups/livecode.developers
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode