[Qt-interest] QEventLoop and QEvents

[Frank Hemer]

On Friday 19 February 2010 22:27:12 Eric Clark wrote:
> > -----Original Message-----
> > From: qt-interest-bounces at trolltech.com [mailto:qt-interest-
> > bounces at trolltech.com] On Behalf Of Frank Hemer
> > Sent: Friday, February 19, 2010 3:21 PM
> > To: qt-interest at trolltech.com
> > Subject: Re: [Qt-interest] QEventLoop and QEvents
> >
> > On Friday 19 February 2010 20:21:07 Eric Clark wrote:
> > > When I say that it is a little bit of time, it is milliseconds. This
> >
> > is how
> >
> > > it HAS to work. Without going into great detail, this particular
> >
> > widget is
> >
> > > a GLWidget. There is an active 3D simulation going on in the widget
> >
> > and
> >
> > > when you click on the widget, a 3D ray-trace is performed to find the
> >
> > 3D
> >
> > > object that was clicked on. During the active simulation, there are
> >
> > events
> >
> > > that happen that cause manipulation of the 3D objects, such as
> >
> > cutting
> >
> > > holes in the objects, or possibly removing the object from the viewer
> >
> > all
> >
> > > together. The simulation runs on a separate thread than the GUI and
> >
> > as
> >
> > > such, it is VERY unsafe to allow the ray-trace to happen while the
> > > simulation is active. Instead, the 3D viewer reacts to mouse events
> >
> > when it
> >
> > > repaints. During repainting of the GLWidget, the simulation is
> >
> > temporarily
> >
> > > paused and any events that occurred between painting will also be
> > > processed. Believe me, I know what I am doing as far as deferring the
> > > events. The time between repaints is so fast that no user will ever
> >
> > notice
> >
> > > the delay in reaction of a mouse click. Not only that, what happens
> >
> > when
> >
> > > you click on an object is that it gets highlighted in the 3D viewer,
> >
> > this
> >
> > > highlighting would even be ok if it did take longer than normal, but
> >
> > the
> >
> > > reaction time now is on the order of milliseconds and no human eye
> >
> > can
> >
> > > possibly see the delay.
> > >
> > > Now that everyone knows what is really going on. I would love for
> >
> > someone
> >
> > > to answer my question. Is there any way to tell Qt to not delete the
> >
> > event?
> >
> > > Or do I need to make a copy of the event?
> >
> > You can catch events (mouse and key) in an QApplication-installed
> > eventHandler, store a copy and  post them later.
> > That works quite well, however be aware of some surprising effects if
> > for ex.
> > a Window pops up right before the events get posted.
> > This will most likely NOT work for other system-internal events though.
>
> I am actually using an event handler to catch the events. That is how I
> defer them. I was trying to take the event and post it to a different event
> loop that I could call processEvents on when it was time to do so. However,
> the events were being deleted before it was time to call processEvents on
> them. So, I tried to make a copy of the event and post it to the other loop
> from within my event handler, but that seemed to cause some very strange
> behavior. Maybe I did something wrong, I am not sure...

An eventloop is _PROCESSING_ the events, its not a storage class.

Use a QQueue to store the event copies and their receiver.
And post them later using QApplication::postEvent.

Frank