Hi Jacque,
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
built standalone.
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.
Thanks again,
Chris
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 | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
------------------------------------------
Chris Sheffield
Read Naturally
The Fluency Company
http://www.readnaturally.com
------------------------------------------
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
