strange menu behavior
cmsheffield at gmail.com
Thu Mar 2 11:40:56 EST 2006
Thanks for the suggestions. Unfortunately the menu group of both
stacks does have the backgroundBehavior set to true.
I've done a little more investigating and this is what I've found.
When the second stack first opens, it is not even getting set as the
topStack or the defaultStack. So unfortunately your workaround
doesn't even work. I've even tried setting it to the defaultStack
explicitly without success. I've found that once I click on my File
menu (just to activate the menu, but not actually click Quit) then
the topStack and defaultStack are set correctly, which would explain
why ctrl-Q works at this point. So there is definitely something
strange going on. This behavior occurs both in the Rev IDE and in a
Can you, or anyone else for that matter, think of any reason why
topStack and defaultStack would not get set correctly? What's
strange is I have another stack that opens the same way and it works
just fine. I've compared the properties between the two stacks,
their menu groups, and even the File button within their menu groups
to see if anything is different. Everything is the same other than
things like the layers of the objects.
Any other ideas? This one has me stumped, but I figure it's got to
be something I've done because the other stack does work like I said.
On Mar 1, 2006, at 7:53 PM, J. Landman Gay wrote:
> Depending on your setup, it might be a message hierarchy thing. On
> Macs, the menubar property of a stack puts the menu into the OS
> menu space and keyboard shortcuts are sent there first. There isn't
> any other menu available, since only one can be active at a time.
> Whatever menu group a stack contains will get first crack at
> keyboard events.
> On Windows there is no global menu bar, and the menu functions as a
> group on the card. Keyboard events are sent to the card and, if the
> stack is a substack, the event passes through to the main stack.
> If your menu group in the main stack has backgroundBehavior set to
> true, but the menu group on the substack does not, then the main
> stack's menu group would catch the event. Check to see if your
> substack's menu group has backgroundBehavior set to true. If it
> does then maybe you did find a bug.
> One workaround would be for your quit handler to check whether the
> mainstack was the topstack, and only quit if it is.
> Jacqueline Landman Gay | jacque at hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
The Fluency Company
More information about the Use-livecode