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

[Malyushytsky, Alex]

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