Chris Sheffield wrote:
I've found what I think is a bug of some kind, but I wanted to ask here
to see if someone else has run into anything like this, and to see if
maybe it's something I'm doing.
I've got an application that uses a splash screen method. The main
stack opens and the user has to enter his password to continue. This
main stack has its own menu, which includes File -> Quit with Ctrl-Q
set as the shortcut. After entering a password and logging in
successfully, another stack opens. This stack has its own menu, which
also includes File -> Quit with Ctrl-Q as its shortcut. When hitting
ctrl-Q from this second stack, it should close the stack and return to
the main login screen. Unfortunately, it's exiting the application
completely. I believe what's happening is hitting ctrl-Q in the second
stack is triggering the menu item in the first stack, which *is*
supposed to exit the application completely. I've found that if I
access the menu in the second stack by just clicking File, then ctrl-Q
works correctly. It's almost as if the menu in the second stack is not
loading or coming to the front or whatever until it is accessed in some
way with an actual click of the mouse.
Anyone have any ideas? Have I found a bug of some kind, or could there
possibly be something I'm doing?
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.
One extra piece of information is
that I am changing the menu items of this File menu in the preOpenStack
handler of the second stack, dependent on a couple different
conditions. Not sure if that would have anything to do with it or
not. This problem only occurs under Windows, btw. On the Mac the
behavior is exactly how I want it.
Any help would be appreciated.
Thanks,
Chris
------------------------------------------
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
--
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
