But what do you need that functionality for? If you want a menu to be invactive, just disable it.
But what do you need that functionality for? If you want a menu to be invactive, just disable it.
I want to make it not visible, this is what I want. They want to reduce the number of the clicks you have to do with the mouse.
well, there would be a solution, but it doesnt' work perfectly. I can reduce the dimension of the QMenu, but the QMenu keeps the focus and it would be necessary to press ESCAPE to move the focus to elsewhere.
You mean you want to make collapsible menus? Try making the action responsible for the menu invisible (setVisible(false)).
Thanks for your help.
I tried it but what I get is a void little rect at the same point where there was the qmenu. And then, I need to click on it to make this little rect to disappear.
Maybe you just need to update() the menu bar or the parent menu?
![]()
It doesn't work. It doesn't update. The rect remains, as if you build a QMenuBar with QMenus and no actions.
Seems to work quite fine for me...
try these statements in a on_click() of QPushButton
mb->setActiveAction(mb->actions()[0]);
mb->actions()[0]->menu()->setActiveAction(mb->actions()[0]->menu()->actions()[0]);
then try to hide the first menu that has just appeared. I can close the qmenubar but the qmenu is open.
I do this inside a routine because if you click outside the menu, the qmenu closes regularly because another event has just fired on another object.
Sorry, if I insist.
But why do you setActiveAction at all? Could you explain what are you trying to achieve? QMenu closes because it is a popup window, not through any kind of magic. In your situation it doesn't close, because it is modal and you don't do anything to break the event loop.
Placido Currò (14th May 2007)
I need the setActiveAction because it opens the qmenu I need to show. I don't use the popup() or the exec() because the former opens the menu but not within the qmenubar and then if I click the right or left arrow the QMenuBar doesn't open the near menus and the latter suspends the event loop.
This is why I used this statement. My application must show a menu opened but close that menu if it receives a command to close the qmenubar, even before the human operator can do it. Imagine these events:
My application is a simple client whoose task is to draw and build the gui.
1) my application receives commands to build a qmenubar and show a qmenu
2) the operator chooses the menu
3) the operator does something...
4) the application receives a command to build a qmenubar and show a qmenu
my application takes a buffer of the events during the server-time and when it's ready to build the qmenubar it can receive the input to close the qmenubar before it has been displayed. In this case the application receives the command to close the qmenubar and obviously his opened children. This is what I can't do, closing the qmenus, if any is open.
Maybe you should operate on event level then? It might be a general way to handle many things, not only the menu.... I'm sure if you posted proper events to the menu, you'd get the effect you desire.
Bookmarks