d_stranz
4th April 2016, 17:26
I have a QMainWindow with both a menubar and a set of toolbars. I create QAction instances and connect slots to their triggered() and hovered() events. All of the action instances get put into QMenu instances owned by the menubar, and many of them also get added to one or more toolbars.
The enabled state for most of the QAction instances is set to false when the app first starts. As the user performs certain operations, the data needed by the actions becomes available, so the action should be enabled. I do this in the hovered() events - I check to see if the required data is available, and enable the QAction if it is.
The weird behaviour I am seeing is that since Qt 5.5 (I think), hovering over a disabled menu item will not cause the hovered() signal to fire (or at least my slot doesn't get called). If I hover over the same item on a toolbar, the hovered() signal is emitted whether the action is enabled or not.
If the hover slot does not enable the action, then the action on the menu stays unresponsive. If the hover slot enables the action, then the menu action becomes responsive and emits the hovered signal.
There are some menu items that do not have toolbar counterparts. I cannot get these to respond to hovered() signals no matter what changes in the program.
It does not seem to matter whether other items on the menu are enabled or disabled, either dynamically or set to enabled on creation. The items that start disabled stay unresponsive only until their corresponding icons are hovered and thereby enabled.
Has anyone else seen similar behaviour? Has something changed in QMenu since Qt 5.4 (or maybe it has been since Qt 5 and I haven't noticed) that could cause this to happen? Some QMenu / QMenuBar flag I am missing?
It is very bad for my users, because now they are locked out of certain operations (like copy and paste!) if I don't have a toolbar counterpart to the menu item.
This is on Windows 10, using either Qt 5.5 and 5.6, MS Visual Studio 2013. I have not reverted to Qt 5.4 to see if this problem exists there (yet).
The enabled state for most of the QAction instances is set to false when the app first starts. As the user performs certain operations, the data needed by the actions becomes available, so the action should be enabled. I do this in the hovered() events - I check to see if the required data is available, and enable the QAction if it is.
The weird behaviour I am seeing is that since Qt 5.5 (I think), hovering over a disabled menu item will not cause the hovered() signal to fire (or at least my slot doesn't get called). If I hover over the same item on a toolbar, the hovered() signal is emitted whether the action is enabled or not.
If the hover slot does not enable the action, then the action on the menu stays unresponsive. If the hover slot enables the action, then the menu action becomes responsive and emits the hovered signal.
There are some menu items that do not have toolbar counterparts. I cannot get these to respond to hovered() signals no matter what changes in the program.
It does not seem to matter whether other items on the menu are enabled or disabled, either dynamically or set to enabled on creation. The items that start disabled stay unresponsive only until their corresponding icons are hovered and thereby enabled.
Has anyone else seen similar behaviour? Has something changed in QMenu since Qt 5.4 (or maybe it has been since Qt 5 and I haven't noticed) that could cause this to happen? Some QMenu / QMenuBar flag I am missing?
It is very bad for my users, because now they are locked out of certain operations (like copy and paste!) if I don't have a toolbar counterpart to the menu item.
This is on Windows 10, using either Qt 5.5 and 5.6, MS Visual Studio 2013. I have not reverted to Qt 5.4 to see if this problem exists there (yet).