RE: [fltk.general] Making a menu_bar submenu close when the menu_bar loses focus - [General Use]
MacArthur, Ian (Leonardo, UK)
> dropped down when I move focus away from the menu_bar.
This is pretty normal, though, many (most?) GUI toolkits do that; indeed I think that's the default behaviour for Win10.
However, the Win10 system menus, though they stay dropped down, will not usually block click events *that occur outside the menu area* from propagating to other widgets, whereas FLTK menus typically grab the context and so will prevent clicks from propagating, until the menu is dismissed.
It's a design choice, and it's hard to pick the *right* choice for every case. Remember that FLTK has to strive for some consistency across a range of different Window Manager environments, so it is tricky to please everybody!
> The only times it doesn't is if
> 1) I pass the mouse over another menu item, in which case the second sub-menu drops down, or
> 2) I click on the menu_bar away from any menu items.
> This has the effect that all other events in my app seem to be blocked, especially the app close event which is the most infuriating.
Yup - see above...
> I presume I need to handle the UNFOCUS event in the menu_bar, but how do I cause the sub-menu to close.
Well... I think in the past I faked this up on Windows by catching the LEAVE event in the menu handle() method, then generated a synthetic click at the mouse position (i.e. outside the menu.) Since the menu is grabbing the context anyway, that click goes nowhere, but does dismiss the menu.
That said, I just looked for a sample of that code and can not find it - it is likely on some machine I do not have access to right now...
> Alternaively I would like to generate a system noise alert that window close is being ignored.
Leonardo MW Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
Philip Rose
From: MacArthur, Ian (Leonardo, UK)
Sent: 15 September 2020 15:35
To: fltkg...@googlegroups.com
Subject: RE: [fltk.general] Making a menu_bar submenu close when the menu_barloses focus - [General Use]
> When I open a top-level sub-menu in my Fl_Menu_Bar I then find that it stays
> dropped down when I move focus away from the menu_bar.
This is pretty normal, though, many (most?) GUI toolkits do that; indeed I think that's the default behaviour for Win10.
However, the Win10 system menus, though they stay dropped down, will not usually block click events *that occur outside the menu area* from propagating to other widgets, whereas FLTK menus typically grab the context and so will prevent clicks from propagating, until the menu is dismissed.
It's a design choice, and it's hard to pick the *right* choice for every case. Remember that FLTK has to strive for some consistency across a range of different Window Manager environments, so it is tricky to please everybody!
Thanks Ian, It was that blocking effect that made me think this was not usual behaviour. I understand now and will live with it I guess, or try and fake it like you say below.
> The only times it doesn't is if
> 1) I pass the mouse over another menu item, in which case the second sub-menu drops down, or
> 2) I click on the menu_bar away from any menu items.
> This has the effect that all other events in my app seem to be blocked, especially the app close event which is the most infuriating.
Yup - see above...
> I presume I need to handle the UNFOCUS event in the menu_bar, but how do I cause the sub-menu to close.
Well... I think in the past I faked this up on Windows by catching the LEAVE event in the menu handle() method, then generated a synthetic click at the mouse position (i.e. outside the menu.) Since the menu is grabbing the context anyway, that click goes nowhere, but does dismiss the menu.
That said, I just looked for a sample of that code and can not find it - it is likely on some machine I do not have access to right now...
OK, but I was clicking outside the menu – on the X at the top right of the window.
> Alternaively I would like to generate a system noise alert that window close is being ignored.
Phil.
MacArthur, Ian (Leonardo, UK)
> > > I presume I need to handle the UNFOCUS event in the menu_bar, but how do I cause the sub-menu to close.
> > Well... I think in the past I faked this up on Windows by catching the LEAVE event in the menu
> > handle() method, then generated a synthetic click at the mouse position (i.e. outside the menu.)
> > Since the menu is grabbing the context anyway, that click goes nowhere, but does dismiss the menu.
> > That said, I just looked for a sample of that code and can not find it - it is likely on some
> > machine I do not have access to right now...
OK, but I was clicking outside the menu – on the X at the top right of the window.
- I drop down one of the menus, and do not dismiss it
- I click somewhere outside the menu, (including on the Red-X) and the menu is dismissed (but the click is not otherwise actioned)
- I click again in the same place, the click event is actioned.
Overall, that's what I'd expect: that first click on the "red-X" is not actioned because the menu had grabbed the context, but that does cause the menu to close. A second click then actions the "red-X" and the app terminates normally.
What behaviour do you see in your app?
Is it different from the behaviour of the menubar demo.? If so, the callback you have attached to the "red-X" may be complicating matters?