Hi John:
Thanks:) Actually we have some problem with the resize and move also, I can
understand most of your solution, but could you explain more about why
calling doing this part
moving = true;
movedWidget = somewidget;
somewidget->move();
return <whatever>;
inside of a event filter?
Thanks,
-Yili
On Fri, Oct 31, 2014 at 11:56 AM, John Weeks <j...@wavemetrics.com> wrote:
> It's the same situation with Move and Resize events. In Qt 4, you could do
> this:
>
> bool myclass::eventFilter(QObject * target, QEvent *event)
> {
> static bool moving = false;
>
> case QEvent::move:
>
> // In Qt 4, the move event comes synchronously, so we know
> that only our call to QWidget::move
> // can cause a reentrant call here.
> if (moving)
> return;
>
> moving = true;
> ... call QWidget::move ....
> moving = false;
> }
>
>
> But in Qt 5 the Move event is put on the queue and delivered
> asynchronously. So now I have this sort of code:
>
> class myclass
> {
> ...
>
> private:
> bool moving;
> QWidget * movedWidget;
> };
>
> bool myclass::eventFilter(QObject * target, QEvent *event)
> {
> somewidget = qobject_cast<QWidget *>(target);
>
> case QEvent::move:
> // in Qt 5, the call to QWidget::move doesn't cause a
> reentrant call here, it triggers
> // another move event later on. So we have to store away
> info on this call to QWidget::move,
> // and detect that move event later on when it looks like
> other move events.
> if (moving && somewidget == movedWidget)
> {
> moving = false;
> movedWidget = NULL; // not at C++11
> yet!
> return false;
> }
>
> moving = true;
> movedWidget = somewidget;
> somewidget->move();
> return <whatever>;
> }
>
> I put in a check on the widget that was moved out of paranoia that some
> other move event could sneek in while I was waiting. In our case, we have
> the same filter on multiple widgets.
>
> Warning: I could have made some typo in the process of abstracting the
> method from much more complex code...
>
> -John Weeks
>
> On Oct 31, 2014, at 7:35 AM, Yili Pan <pyl0...@gmail.com> wrote:
>
> > Hi Bo:
> >
> > Thank you for the reply!
> >
> > I do not want to filter out all the WindowActivate or FocusIn event
> tough, only these are triggered by calling QWidget::show(). But because the
> events are processed asynchronously in Qt5, when I catch them in the
> eventfilter, I don't know whether they are originated from calling show()
> or they are spontaneous event caused by manual interaction. I also tried to
> filter out the event by telling whether they are spontaneous, but
> unfortunately no matter where they originate from, they are spontaneous
> (could this be a bug??). Any thoughts or suggestion :)
> >
> > Thank you!
> >
> > -Yili
> >
> > On Fri, Oct 31, 2014 at 4:01 AM, Bo Thorsen <b...@vikingsoft.eu> wrote:
> > Den 30-10-2014 20:30, Yili Pan skrev:
> > > Hi:
> > >
> > > We want to block the widget's WindowActivate and FocusIn event
> > > triggered by calling its show() function, with Qt4, we used to do
> > > that by setting flag before and after show() and filter out the event
> > > in eventfilter based on the flag. But with Qt5, the events are
> > > processed asynchronously, we cannot block the event in the same way
> > > anymore.
> > >
> > > Any ideas how I can identify those events that are caused by calling
> > > QWdiget::show() and filter them out?
> >
> > You can use an event filter for this. Take a look at the documentation
> > for QObject::installEventFilter, it should be simple to follow.
> >
> > Bo.
> >
> > --
> > Viking Software
> > Qt and C++ developers for hire
> > http://www.vikingsoft.eu
> >
> > _______________________________________________
> > Interest mailing list
> > Interest@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
> >
> > _______________________________________________
> > Interest mailing list
> > Interest@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
>
> -John
>
>
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
