Results 1 to 2 of 2

Thread: Weird behaviour of mouse events and QMenu pop-ups

  1. #1
    Join Date
    Jul 2007
    Qt products
    Qt3 Qt4

    Default Weird behaviour of mouse events and QMenu pop-ups

    I'm experiencing a weird behavior on some pop-up menus I'm using. Sorry if the explanations is longish, but I want to be sure to provide all the information. All this is with Qt 4.2.

    - The application is basically a big GLwidget which draws stuff. Some parts of the drawing are "active", in the sense that you can drag'n'drop from/to them and you can right-click on them to get a context menu.
    - since I need to have my statusbar updated with the properties of the "active area" the cursor is in, I have enabled Mouse Tracking and I use mouseMoveEvent to determine in which area the cursor is sitting. The information on the area is saved, so any other event which needs it can reuse it.
    - when I receive a contextMenuEvent, I use the stored information about the area to determine where the cursor is, and open up the appropriate context menu.
    - unfortunately, it seems that while the pop-up menu is open, no mouseMoveEvents are sent to the parent widget EVER. So if the user right-clicks on area "A", obtaining the "A" pop-up, then moves to area "B" and right-clicks again, the pop-up of "A" appears again, since no mouseMoveEvent was ever emitted (resulting in my area information to be out-of-date).
    - I've worked around this by forcing the update of the "active area" in the beginning of contextMenuEvent with the new event coordinates and it seems to work.

    - a stranger and similar behavior happens with drag'n'drop. When an item from area "A" is picked up and dropped on area "B", the "A to B" context menu appears, this context menu is generated from a mouseReleaseEvent, which uses the information on the drag source as well as the "current" active area to decide what to display.
    - now, I was expecting that if the user left-clicks OUTSIDE the pop-up menu, then none of the QActions is triggered, but for some reason what I get is:
    - - a mousePressEvent with the current mouse coordinates (note that I didn't have any mouseMoveEvents indicating me that the cursor was moved)
    - - the QAction which is at around the same y as the point where the button was pressed gets triggered (even if the user clicked outside the menu!!)
    - - a mouseReleaseEvent, again with the mouse coordinates.
    - this screws up stuff in my application, even if I expected receive a mousePressEvent from the GLwidget display while a pop-up menu is active (in case the user clicks outside), I didn't expect the action to be triggered after a mouse-click.

    What is going on? Why are some mouse events masked while a pop-up is open (mouseMove) while others are passed (mousePress)? Why the menu (which has a deafaultAction = 0) still triggers my QActions even when clicking outside?

    Thanks in advance.

  2. #2
    Join Date
    Feb 2006
    Oslo, Norway
    Thanked 1,518 Times in 1,388 Posts
    Qt products
    MacOS X Unix/X11 Windows Symbian S60 Maemo/MeeGo

    Default Re: Weird behaviour of mouse events and QMenu pop-ups

    Both QDropEvent and QContextMenuEvent provide position information of their own. Why not use them instead of relying on old mouse events?
    J-P Nurmi


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.