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

[Christopher Mitchell]

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?

Yours,
Chris
On Feb 18, 2004, at 10:01 PM, Christopher Mitchell wrote:

> somehow these lines:
>
> --    close stack "consonants"
> --    close stack "controls"
>
> in the button onMouseup handler, are making their way into the main 
> stack and simultaneously bypassing the closestackrequest handler.  If 
> I comment these lines, as such, the highlight toggles and the thing 
> does not quit.  I do not see the logical message path here.
>
> Yours,
> Chris
> On Feb 18, 2004, at 9:56 PM, Christopher Mitchell wrote:
>
>> Hello, again...
>>
>> I have three stacks - a "main" stack acting as a menu with buttons 
>> that should  be highlighted when that particular function is 
>> activated, and (currently only) 2 windows that pop up when my one 
>> button is activated.  they are supposed to be closed when that button 
>> is clicked again.
>>
>> Well, strange things are happening now that I moved my menu toolbar 
>> onto my main stack, and there is some weird interaction in the realm 
>> of close stack handling.
>>
>> This script is in the main stack, thus inherited all around:
>>
>> on closeStackRequest
>>   answer "Quit program?" with "Yes" or "No"
>>   if it is "Yes" then pass closeStackRequest
>> end closeStackRequest
>>
>> on closeStack
>>   quit
>> end closeStack
>>
>> --
>> to make this behavior not happen in the other two stacks open, I have 
>> put this in each one (if there is a way to localize a handler to 
>> prevent inheritance, please let me know):
>>
>> on closeStackRequest
>>
>> end closeStackRequest
>>
>> --
>>
>> finally, I have this button script on the main stack which go's to 
>> and closes the two substacks, as well as toggles the highlight of the 
>> button itself and a custom property to keep tabs on its status:
>>
>> on mouseUp
>>   if the selectStatus of me is "off" then
>>     set the selectStatus of me to "on"
>>     set the hilight of me to true
>>     set the defaultStack to "consonants"
>>     go stack "consonants"
>>     palette stack "controls"
>>   else
>>     set the selectStatus of me to "off"
>>     set the highlight of me to false
>>     close stack "consonants"
>>     close stack "controls"
>>     set the defaultStack to "main"
>>   end if
>> end mouseUp
>> --
>>
>> Okay, this was all working well until I got rid of the SUBSTACK 
>> toolbar, which had previously been my visible main menu and handled 
>> the close request/program quitting. because it is a sibling, it did 
>> not mess with the other substacks.  Now, however, the main stack 
>> causes all the stacks to inherit this functionality, and even though 
>> they are blocked off with an empty pair of handlers to override the 
>> main function, everytime I click the button the second time (thus to 
>> "close" the other two stacks and turn off the highlighting) the whole 
>> thing closes WITHOUT going through the "Do you want to quit" handler!
>>
>> I don't see why the main stack would be receiving a close stack 
>> message here, and certainly why, if it were receiving this message, 
>> my Yes or No handler would be over-ridden.
>>
>> If anyone has time to instruct me in the errors of my ways here, I'd 
>> appreciate it as it is driving me batty.
>>
>> Yours,
>> Chris
>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>