How to get the event source of a QMenu which is bind to some QPushButtons?
-
-
have a look at the docs : signals and slots
bq. Advanced Signals and Slots Usage:
For cases where you may require information on the sender of the signal, Qt provides the QObject::sender() function, which returns a pointer to the object that sent the signal.in your case qsignalmapper could be an even better solution.
-
I'm not sure I totally agree with that statement. I think it makes sense to want to attach a context to a menu (-action). Considder a context menu for a list of items. The menu contains a set of actions that can operate on the items. I think it makes sense to
reuse the same menu and the same actions as implementation for the operations, and
wish to know at the action level what the context of the operation is.
This case is not that different.
I can see a case for having some kind of context for actions, but no ready-made solution for it.
-
Two pushbuttons are static. I just would go the easy way and create two menus. And we're not talking about context menus (these are easy to manipulate via the Qt::ContextMenuPolicy and the customContextMenuRequested signal), but a "regular" button menu.
One could try to subclass QPushButton and override slot showMenu. Albeit that one is not virtual by design, all slots are inherently virtual when called via the metacall/signal-slot mechanism. I would not bet that this works out in all cases, though.
-
The problem is, when triggered() is called by a particular menu, whether the same menu is used in two buttons or you have different menus, you cannot work out which QPushButton the triggering menu is attached to.
I tried looking at the parent() of the menus, but they are NULL. If I set the parent of them upon creation, then the menus are displayed when the buttons are drawn instead of when clicked.
Even doing a pointer comparison between the event's sending QMenu and each QPushButton::menu() don't match.
-
So, when an action of the menu fires, the connected slot should use the URL associated with that button, right?
If you still do not want to use separate menus and actions - which I think is the easiest and less problematic approach - you might want to connect to the pressed() signal of the buttons (use a [[Doc::QSignalMapper]] to associate an id or the like). I don't know if that works reliably in all and every corner cases (activation with the keyboard instead of the mouse comes into mind).
-
You could considder an alternative approach:
How about you subclass QPushButton. In this custom class, you can attach the menu already. Then, you give your button a set of signals corresponding with the items in the menu. You can give these signals an identifier argument to identify the instance of the button.That way, you will have no need to fiddle with sender() or with QSignalMapper.