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

Cyril C. cyril.mailing.list at gmail.com
Thu Nov 5 13:17:46 CET 2009


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
>>>>     
>>>>         
>>>   
>>>       
>
>   




More information about the Qt-interest-old mailing list