might have figured it out, could I get a verification on this

Christopher Mitchell chrism at lumin.us
Thu Feb 19 00:15:46 EST 2004


Alex,

That if-then idiom looks like exactly what I was looking for.  It 
should essentially cut off inheritance.  I'll give it a shot tomorrow,  
but I think I'm done for the evening.  Thanks very much.

Yours,
Chris
On Feb 18, 2004, at 11:02 PM, Alex Rice wrote:

>
> On Feb 18, 2004, at 9:30 PM, Christopher Mitchell wrote:
>
>> It seems that, and I guess in a way it makes sense, if there is no 
>> over-riding handler in the children, the message path goes all the 
>> way up until it finds it, then it runs it in that location.
>>
>> So I've over come this by putting a series of empty handlers in each 
>> of the substacks.  It seems like this could be easier if there was a 
>> way to specify that certain stacks in parents were not inherited... 
>> am I missing this?
>
> The message path is just always there- you can't turn it off for any 
> stacks.
>
> It's perfectly acceptable to put an empty handler if you want to trap 
> a message and not have it reach the mainstack or whatever parent 
> control.
>
> There is an idiom that can be used instead, and I like this better 
> (learned on this list perhaps from Ken Ray). In a mainstack you can 
> put:
>
> on preOpenStack
>   if the owner of the target is me then
>     -- handle mainstack message
>   else
>     -- handle substack message
>   end if
> end preOpenStack
>
> Similarly, for a library stack "start using", you want to check the 
> target of the message:
>
> on libraryStack
>   if the target <> me then exit libraryStack
>  ...
> end libraryStack
>
> Check out Dar's excellent Message Mechanics primer to learn more about 
> the message path.
> <http://www.swcp.com/~dsc/revstacks.html>
>
>
> --
> Alex Rice | Mindlube Software | http://mindlube.com
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>



More information about the use-livecode mailing list