David Bovill wrote:
Thanks - taking a look. This is my fourth version of a recursive
function to
walk the message hierarchy - itching to get it just right :)
You might want to check the list archives -- there have been a couple of
threads on this and a number of good handlers presented.
--
Thanks - taking a look. This is my fourth version of a recursive function to
walk the message hierarchy - itching to get it just right :)
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and
David Bovill wrote:
Which makes me think that "pass" works according to a strict hierarchy. If
you "pass" a handler call it will nto find anything in any of the libraries
below it in the hierarchy.
Right. Passing a handler or function call follows the message hierarchy.
While on the other ha
Which makes me think that "pass" works according to a strict hierarchy. If
you "pass" a handler call it will nto find anything in any of the libraries
below it in the hierarchy.
While on the other hand a straight "call" to the handler from a script
behave completely differently in that it will be
I guess there is one difference with regard to the way "pass" works?
on mouseUp
testHierarchy
end mouseUp
on testHierarchy
answer 1
pass testHierarchy
end testHierarchy
on testHierarchy
answer 1
end testHierarchy
In that the second "testHierarchy" does not get called in a single sc
On Sat, 3 Feb 2007 15:04:29 +0100, David Bovill wrote:
> Is it the case that libraries of the same "type" (forn,used, and back) are
> effectively all in one "flat" space - as if they were in a single script,
> and that the order only affects the order the scripts are added to this
> space (in case
I am writing a handler to walk the script hierarchy - which means I have got
to get to the bottom of exactly how the message passing happens. My question
is basically how the hierarchy works exactly with front and backscript and
used stacks. The front go in the front, the used after the stack
