Side effects of contextual menus in Qt

This post is rather short and almost more like so I don’t forget than anything else, but here it goes.

When a context menu is displayed on a Qt widget, it takes ownership of the mouse (grabMouse) which prevents the other widgets that have requested to continuously follow the cursor movement (QWidget::mouseTracking) to not receive the event while the context menu is displayed.

As a practical example, let’s imagine a widget that renders its own graphic elements, such as an OpenGL widget, and that through MouseMove events changes the state of the elements that are below the cursor (such as highlighting the current element). When displaying the context menu for that element, the widget stops receiving the MouseMove event so, if when the context menu is hidden the mouse is in another position, there is an inconsistency between the highlighted element and the cursor, since the position of this one has not been notified to the widget to update the state of the scene.

As a solution, the menus have a QMenu::aboutToHide() signal that, as the name implies, is issued just before If the menu is hidden, either by selecting an entry from the menu or by deactivating the menu. With this signal you can update the status of the elements by forcing a MouseMove event with the current cursor position. However, this event is emitted before calling the method associated with the menu entry, so if it needs the current state (for example, the highlighted item) this fact must be taken into account. Obviously this does not apply when the menu has been deactivated.