[Qt-interest] qt event loop in a DLL for thread signal slot mechanism

Lars Friedrich Lars lars-friedrich at gmx.net
Thu Nov 5 13:30:29 CET 2009


Hello again,

the sent example is not really comparable with the situation in my DLL as my code is not that 'serial' as the code in the example is. Therefore, I certainly do not have to stupidly wait for the end of a thread or so as shown in the modified example. The life-time of my threads is rather controlled by a central singleton ('thread pool') which only needs to get the right signals without interfering with my Delphi-app - and this is exactly what I was looking for.
However, if the worst comes to the worst, I will have a closer look on your recommendation regarding the periodic QCoreApplication calls. Thanks for this suggestion!

regards,

lars


-------- Original-Nachricht --------
> Datum: Thu, 05 Nov 2009 13:17:46 +0100
> Von: "Cyril C." <cyril.mailing.list at gmail.com>
> An: Lars Friedrich Lars <lars-friedrich at gmx.net>
> CC: qt-interest at trolltech.com, imikejackson at gmail.com
> Betreff: Re: [Qt-interest] qt event loop in a DLL for thread signal slot mechanism

> Thanks for your answer.
> I get it now. However this leads to some brutal coding like killing 
> threads, or polling for thread status. I wonder if you can't just simply 
> simply simulate QCoreApplication::exec() with periodic calls to 
> QCoreApplication::processEvents() and 
> QCoreApplication::sendPostedEvents(), which are non-blocking. This may 
> trigger all pending slot calls in your main thread if any, and possibly 
> totally emulate a Qt-eventloop-driven behavior.
> HTH
> Cyril
> 
> 
> Lars Friedrich Lars a écrit :
> > Hi cyril (?),
> >
> > this was my first notion too, but then I did some experiments with the
> original code and recognized that it is simply not true that the example
> relies on QCoreApplication::exec(). However, it relies on the instantiation of
> a QCoreApplication-object, but this is no problem (at least for my
> situation).
> > In the concrete example of Bradley Hughes, consequently, we cannot use
> the line
> > app.connect(&producerThread, SIGNAL(finished()), SLOT(quit()));
> > anymore, but this is not important (at least not for my DLL-framework).
> >
> > I attached the zip with my experimental changes to Bradley's source (I
> use CMake for building). I think this piece of code will show you, that we
> do not rely on running QCoreApplication::exec().
> >
> > Hope that helps,
> >
> > lars
> >
> >
> > -------- Original-Nachricht --------
> >   
> >> Datum: Thu, 05 Nov 2009 12:13:17 +0100
> >> Von: "cyril.mailing.list" <cyril.mailing.list at gmail.com>
> >> An: Lars Friedrich Lars <lars-friedrich at gmx.net>
> >> CC: Mike Jackson <imikejackson at gmail.com>, qt-interest at trolltech.com
> >> Betreff: Re: [Qt-interest] qt event loop in a DLL for thread signal
> slot	mechanism
> >>     
> >
> >   
> >> Hi, I am also interested by the answer to that problem but I did not
> get 
> >> it since the producer-consumer sample code written by Bradley Hughes 
> >> still relies on instanciating and executing QCoreApplication...
> >> How did you work around that to solve your eventloop conflict ?
> >>
> >>
> >> Lars Friedrich Lars a écrit :
> >>     
> >>> Hello Mike,
> >>>
> >>> thank you very much for your suggestion!
> >>> I modified the code of producerconsumer2.tar.gz a bit to simulate my
> >>>       
> >> needs and packed it into my DLL. Tests showed that this mechanism
> avoids the
> >> Qt event loops to 'eat' my key press events of the calling
> >> Delphi-application, and that is exactly what I need.
> >>     
> >>> However, now I have to adapt my real code to conform to the suggested
> >>>       
> >> lines of code ...
> >>     
> >>> Thank you again!
> >>>
> >>> regards,
> >>>
> >>> lars
> >>>
> >>> -------- Original-Nachricht --------
> >>>   
> >>>       
> >>>> Datum: Wed, 4 Nov 2009 10:47:42 -0500
> >>>> Von: Mike Jackson <imikejackson at gmail.com>
> >>>> An: qt-interest at trolltech.com
> >>>> Betreff: Re: [Qt-interest] qt event loop in a DLL for thread signal
> >>>>         
> >> slot	mechanism
> >>     
> >>>>     
> >>>>         
> >>>   
> >>>       
> >>>> I ran into something similar in the last few weeks. I was trying to 
> >>>> send signals across threads and needed the event loop running in the 
> >>>> thread.
> >>>>
> >>>>
> http://labs.trolltech.com/blogs/2007/07/05/qthreads-no-longer-abstract/
> >>>>
> >>>> http://chaos.troll.no/~bhughes/producerconsumer2.tar.gz
> >>>>
> >>>> That code more or less worked for what I wanted to do.
> >>>>
> >>>> Mike Jackson
> >>>>
> >>>>
> >>>> On 2009-11-04 02:23:00 -0500, "Lars Friedrich Lars" 
> >>>> <lars-friedrich at gmx.net> said:
> >>>>
> >>>>     
> >>>>         
> >>>>> Hi Alex,
> >>>>>
> >>>>> unfortunately replacing QApplication by QCoreApplication does not
> fix 
> >>>>> the problem. The behavior is exactly the same.
> >>>>>
> >>>>> regards,
> >>>>>
> >>>>> lars
> >>>>>
> >>>>> -------- Original-Nachricht --------
> >>>>>       
> >>>>>           
> >>>>>> Datum: Tue, 3 Nov 2009 15:25:43 -0800
> >>>>>> Von: "Malyushytsky, Alex" <alex at wai.com>
> >>>>>> An: "qt-interest at trolltech.com" <qt-interest at trolltech.com>
> >>>>>> Betreff: Re: [Qt-interest] qt event loop in a DLL for thread 
> >>>>>> signal	slot	mechanism
> >>>>>>         
> >>>>>>             
> >>>>>>>> - Why does the Qt event loop 'steal' the keypress events although
> >>>>>>>>                 
> >> it
> >>     
> >>>>>>>>             
> >>>>>>>>                 
> >>>> is
> >>>>     
> >>>>         
> >>>>>> not a GUI application?
> >>>>>>
> >>>>>> Never done what you are trying to do, but QApplications always
> means
> >>>>>>         
> >>>>>>             
> >>>> GUI
> >>>>     
> >>>>         
> >>>>>> related initialization.
> >>>>>> If you don't need GUI, try to use QCoreApplication instead and see
> if
> >>>>>>         
> >>>>>>             
> >>>> it
> >>>>     
> >>>>         
> >>>>>> solves your problem.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Alex
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: qt-interest-bounces at trolltech.com
> >>>>>> [mailto:qt-interest-bounces at trolltech.com] On Behalf Of Lars
> >>>>>>             
> >> Friedrich
> >>     
> >>>>>>         
> >>>>>>             
> >>>> Lars
> >>>>     
> >>>>         
> >>>>>> Sent: Tuesday, November 03, 2009 3:00 PM
> >>>>>> To: qt-interest at trolltech.com
> >>>>>> Subject: [Qt-interest] qt event loop in a DLL for thread signal
> slot
> >>>>>> mechanism
> >>>>>>
> >>>>>> Hello qt developers,
> >>>>>>
> >>>>>> I have some serious problems with Qt event loop's behavior when
> using
> >>>>>>         
> >>>>>>             
> >>>> it
> >>>>     
> >>>>         
> >>>>>> in a windows DLL as an interface for a Delphi5-application.
> >>>>>>
> >>>>>> I am wrapping some image conversion capabilities (furthermore using
> >>>>>>             
> >> the
> >>     
> >>>>>> open source toolkits ITK and VTK with cross-platform build tool
> >>>>>>             
> >> CMake)
> >>     
> >>>>>>         
> >>>>>>             
> >>>> in a
> >>>>     
> >>>>         
> >>>>>> DLL which incorporates Qt-threads. The DLL is more or less a tool
> >>>>>>             
> >> which
> >>     
> >>>>>>         
> >>>>>>             
> >>>> gets
> >>>>     
> >>>>         
> >>>>>> used by a Delphi5-application. The Delphi-application calls a
> >>>>>>             
> >> function
> >>     
> >>>>>>         
> >>>>>>             
> >>>> of
> >>>>     
> >>>>         
> >>>>>> the DLL which internally initiates a QThread which does some
> >>>>>>         
> >>>>>>             
> >>>> parametrized
> >>>>     
> >>>>         
> >>>>>> image conversion tasks in the background. In order to detect the
> end
> >>>>>>             
> >> of
> >>     
> >>>>>>         
> >>>>>>             
> >>>> a
> >>>>     
> >>>>         
> >>>>>> background thread I use QThread's finished()-signal and connect it
> to
> >>>>>>             
> >> a
> >>     
> >>>>>> DLL-internal slot which furthermore triggers a DLL-callback so that
> >>>>>>             
> >> the
> >>     
> >>>>>>         
> >>>>>>             
> >>>> calling
> >>>>     
> >>>>         
> >>>>>> Delphi-application gets notified as well.
> >>>>>> After some tests and studying the Qt-documentation, I noticed that
> I
> >>>>>>         
> >>>>>>             
> >>>> need
> >>>>     
> >>>>         
> >>>>>> an active Qt event loop within the DLL to make the signal/slot
> >>>>>>         
> >>>>>>             
> >>>> mechanism
> >>>>     
> >>>>         
> >>>>>> work. I decided to instantiate a DLL-global QApplication instance
> and
> >>>>>>         
> >>>>>>             
> >>>> call
> >>>>     
> >>>>         
> >>>>>> its (blocking!) exec()-method after loading the DLL internally. I
> >>>>>>         
> >>>>>>             
> >>>> implemented
> >>>>     
> >>>>         
> >>>>>> that by initiating a timer in the Delphi-application which calls
> the
> >>>>>> blocking (!!!) QApplication's exec()-mehod using the DLL (as I read
> >>>>>>             
> >> in
> >>     
> >>>>>>         
> >>>>>>             
> >>>> Qt's
> >>>>     
> >>>>         
> >>>>>> documentation that the event loop can only be started from the main
> >>>>>>         
> >>>>>>             
> >>>> thread!).
> >>>>     
> >>>>         
> >>>>>> However, that seems to work as the signal/slot mechanism seems to
> >>>>>>             
> >> work
> >>     
> >>>>>> correctly (I verified that with a log file).
> >>>>>>
> >>>>>> Now my problem: as soon as the Qt event loop is running it seems to
> >>>>>> seriously influence the Delphi-application's event loop (its GUI
> >>>>>>         
> >>>>>>             
> >>>> behavior):
> >>>>     
> >>>>         
> >>>>>> - Delphi's TApplication OnIdle event is no longer invoked (this
> >>>>>>             
> >> problem
> >>     
> >>>>>>         
> >>>>>>             
> >>>> is
> >>>>     
> >>>>         
> >>>>>> more or less solved because I can generate this event by myself
> using
> >>>>>>             
> >> a
> >>     
> >>>>>> timer and analyzing the message queue state)
> >>>>>> - (some essential but not all) keypress/keydown/keyup events of the
> >>>>>> Delphi-application's GUI seem to be 'stolen' by Qt's event loop -
> >>>>>>             
> >> they
> >>     
> >>>>>>         
> >>>>>>             
> >>>> do not
> >>>>     
> >>>>         
> >>>>>> arrive in the Delphi application (for example the tab-key is no
> >>>>>>             
> >> longer
> >>     
> >>>>>> recognized by the Delphi-application to navigate through its GUI's
> >>>>>>         
> >>>>>>             
> >>>> controls)
> >>>>     
> >>>>         
> >>>>>> Now, my qestions:
> >>>>>> - Did some of you tackle a similar problem?
> >>>>>> - Why does the Qt event loop 'steal' the keypress events although
> it
> >>>>>>             
> >> is
> >>     
> >>>>>> not a GUI application?
> >>>>>> - Can I 'pipe' the keypress events back to the Delphi-application's
> >>>>>>         
> >>>>>>             
> >>>> main
> >>>>     
> >>>>         
> >>>>>> thread (message queue)? Or could I connect the DLL's event loop
> >>>>>>         
> >>>>>>             
> >>>> directly to
> >>>>     
> >>>>         
> >>>>>> the Delphi-application's event loop?
> >>>>>> - Or did I completely misunderstand some Qt-fundamentals? Could I
> >>>>>> implement the signal/slot mechanism with some simpler Qt-tools than
> a
> >>>>>> QApplication?
> >>>>>> Maybe a lightweight event loop specific to thread signal/slot
> >>>>>>         
> >>>>>>             
> >>>> mechanism?
> >>>>     
> >>>>         
> >>>>>> Any comments on this issue are really really appreciated!!!
> >>>>>> Please help me.
> >>>>>>
> >>>>>> Thank you!!!!!!
> >>>>>>
> >>>>>>
> >>>>>> best regards,
> >>>>>>
> >>>>>> lars
> >>>>>>
> >>>>>> --
> >>>>>> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> >>>>>> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
> >>>>>> _______________________________________________
> >>>>>> Qt-interest mailing list
> >>>>>> Qt-interest at trolltech.com
> >>>>>> http://lists.trolltech.com/mailman/listinfo/qt-interest
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>         
> >>>>>>             
> >>
> ---------------------------------------------------------------------------------------------------
> >>     
> >>>> Weidlinger 
> >>>>     
> >>>>         
> >>>>>> Associates, Inc. made the following annotations.
> >>>>>>
> >>>>>> "This message and any attachments are solely for the intended
> >>>>>>             
> >> recipient
> >>     
> >>>>>> and may contain confidential or privileged information. If you are
> >>>>>>             
> >> not
> >>     
> >>>>>>         
> >>>>>>             
> >>>> the
> >>>>     
> >>>>         
> >>>>>> intended recipient, any disclosure, copying, use, or distribution
> of
> >>>>>>         
> >>>>>>             
> >>>> the
> >>>>     
> >>>>         
> >>>>>> information included in this message and any attachments is
> >>>>>>             
> >> prohibited.
> >>     
> >>>>>>         
> >>>>>>             
> >>>> If you
> >>>>     
> >>>>         
> >>>>>> have received this communication in error, please notify us by
> reply
> >>>>>>         
> >>>>>>             
> >>>> e-mail
> >>>>     
> >>>>         
> >>>>>> and immediately and permanently delete this message and any
> >>>>>>         
> >>>>>>             
> >>>> attachments.
> >>>>     
> >>>>         
> >>>>>> Thank you."
> >>>>>>
> >>>>>> "Please consider our environment before printing this email."
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Qt-interest mailing list
> >>>>>> Qt-interest at trolltech.com
> >>>>>> http://lists.trolltech.com/mailman/listinfo/qt-interest
> >>>>>>         
> >>>>>>             
> >>>> _______________________________________________
> >>>> Qt-interest mailing list
> >>>> Qt-interest at trolltech.com
> >>>> http://lists.trolltech.com/mailman/listinfo/qt-interest
> >>>>     
> >>>>         
> >>>   
> >>>       
> >
> >   

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser



More information about the Qt-interest-old mailing list