Richard's approach would be my approach also. It's usually easier to make the
solution overly complex, than to make it this simple.
Phil Davis
On 9/24/10 11:12 AM, Richard Gaskin wrote:
DunbarX wrote:
This all came about because someone wanted a single universal watchdog on
his stack. He had several handlers in several places, all of which could
create a condition he wanted to act upon. So the "send in time" handler fit that
bill. If he created yet another such handler somewhere, it would be
covered. But it occurred to be that if the condition was met and the handler
still
had much to do and might take a long time to do it, then the condition could
not be dealt with until that handler ends. It seemed intriguing to think
that something could monitor, say, the state of variables, from outside the
handler while it was running.
Anyone think this is a useful, perhaps monumental, feature?
Indeed it would:
Add Threaded messaging and or execution in Transcript
<http://quality.runrev.com/qacenter/show_bug.cgi?id=2832>
But threading comes with an additional level of responsibility. Right now we
almost never have to worry about race conditions, an area where a lot of
programmers using threaded languages spend thousands of hours each year
debugging hard-to-track-down issues.
Once you introduce threading into the language it's like handing someone a
loaded gun with a map to their foot. Still very useful, and well worth
implementing, but it would so fundamentally change the messaging system that
it would raise the learning curve and open up many new ways to make mistakes. :)
For those who need it threading would be a godsend, and RunRev couldn't add
this fast enough for me. Many server processes could be much more optimized
with a threaded implementation.
In the meantime, for single-user apps working within a non-threading system
isn't usually so bad. As we've seen in this example, it usually requires no
more than a single line of code to have any additional checking happening
inside of any handler you like, and with that requirement it leaves the
scripter explicitly in control of the interactions between things.
For property settings this might even be reduced to zero additional lines of
code in the repeat loop if you include a setProp handler that will respond to
the change:
-- Main handler:
on mouseUp
repeat with i = 1 to 100
set the uMyProp of this stack to i
end repeat
end mouseUp
-- In stack script, library, or any other place in the
-- message path:
setProp uMyProp pValue
if pValue = 50 then
DoSomethingCool
end if
end uMyProp
It can be tempting to use getProp and setProp in places where more
controllable and concise function and command calls can work well as
accessors, but when you need 'em they're handy to have available.
--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
--
Phil Davis
PDS Labs
Professional Software Development
http://pdslabs.net
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution