PDA

View Full Version : mouse events and nested widgets



tuli
6th November 2012, 22:21
Hi,

i have a custom widget, that consists of three single widgets. Ie. w1 contains w2, which contains w3.
This works just fine.

The problem: w3 receives TWO mousemove events for every MouseMove.
The two event positions are slightly different, suggesting that the events are fired by w1 and w2, and that the position is relative to the causing widget.


This seems to only happen with "mouseMoveEvent( QMouseEvent *event )" events.

What to do about this? :/

tuli
7th November 2012, 15:27
c`mon guys, dont ignore me... :D

pkj
7th November 2012, 16:20
Event propogation differs in QWidgets and QGraphicsItem related classes. Assuming that you are dealing with QWidgets here. The event is dispatched to the object (lowest level in hierarchy) first, if no event filters are installed. Basically lowest level object's event function is called and depending on the event type it is given to specific function which in your case happens to be mouseMoveEvent().
Now the way event propogates is if event->ignore() is called, it goes to the parent. if event->accept() is called it doesnot. Now the default version of your QWidget version of mousemoveevent() function or other functions like it calls event->ignore() in it. So if in your QWidget subclass you happen to call the base version of function, it will lead to propogation.
So bottomline is, for the case you have handled in mouseMoveEvent(), AVOID calling the base class version from it. You will not need to call event->accept() becoz it is done by default.
Hope it helps.

tuli
7th November 2012, 17:47
AVOID calling the base class version from it.

what do you mean by base class version here? I dont call anything myself...
There is a mistake in my first post, it`s actually a QAbstractScrollArea that is encapsulated by two widgets.
so: Qwidget(Qwidget(QAbstractScrollArea))).

In my QAbstractScrollArea-class i have a function "mouseMoveEvent", which is called twice as described above. The two widgets QAbstractScrollArea is wrapped in dont handle mouseMoveEvent at all.

Note that the problem is not directly propagation, the two mouseMoveEvents i receive are for two different locations. However, it seems that relative to the two wrapping widgets, it`s the same event/position.

pkj
8th November 2012, 07:46
what do you mean by base class version here? I dont call anything myself...
There is a mistake in my first post, it`s actually a QAbstractScrollArea that is encapsulated by two widgets.
so: Qwidget(Qwidget(QAbstractScrollArea))).

I mean in ur QWidget inherited class where you write mouseMoveEvent function, don't write QWidget::mouseMoveEvent(). Doing so results in propogation up the parent tree.


Note that the problem is not directly propagation, the two mouseMoveEvents i receive are for two different locations. However, it seems that relative to the two wrapping widgets, it`s the same event/position.

mouseMoveEvents come in a continuous stream. Because it is mouseMoveEvent!! QMouseEvent::pos() depends upon widget being mouse tracked off or on. Unless you show some code, it will be difficult to help.

Santosh Reddy
8th November 2012, 09:09
The problem: w3 receives TWO mousemove events for every MouseMove.
How can you say so?

The two event positions are slightly different, suggesting that the events are fired by w1 and w2, and that the position is relative to the causing widget.
Show an example

tuli
8th November 2012, 11:48
How can you say so?
When i breakpoint mouseMoveEvent is break twice for one mousmove, usually i break once.
Additionally, the y coordinate differs, even though i only moved the mouse vertically.

I`ll try to reproduce this on a smaller scale now.

wysota
8th November 2012, 12:00
Please show your mouseMoveEvent() implementation. And tell us which class it belongs to.

tuli
9th November 2012, 20:49
sorry, i cant check out the problematic code right now, i`ll be back monday.

tuli
23rd November 2012, 15:56
hi guys, sorry for the delay.

Our servers were down for some time, then i was gone for two days - and pof - the problem disappeared, even though i cannot see any relevant changes to the code in question.
I´ll be searching through commits some more next week.