strange menu behavior

[J. Landman Gay]

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
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
> 
> 
> 


-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com