On Saturday 14 December 2013 00:45:20 Roland Winklmeier wrote: > Hi there, > > I'm working on an application using Qt5 for its window framework. The > requirement for this application is to run standalone and as a plugin > for a native application. > While the case standalone application is easy, I'm struggling a bit with > the plugin part. I have the following in mind: > > The plugin is loaded by a native application as a plugin. After the > plugin is attached as a shared library a QApplication object is created > and a dialog is shown, when the user selects it from the menu. Since I > cannot run Qt's event loop with QApplication::exec() - I dont want the > plugin to block the parent application - I try to trigger the event loop > externally. The two options I have are: > > qApp->sendPostedEvents(); > or > qApp->processEvents(); > > The second one is not a good idea, since it calls PeekMessage(..., > PM_REMOVE) which removes any message.
You can try to use QThread::setEventDispatcher before initializing the QApplication, and set your own event dispatcher that reimplements QAbstractEventDispatcher that propagates the right events for you, that way you can still call processEvents. This may be a bit of work and is not so much documented, but maybe worth a try. Note: if really you want to try to use the thread approach, you should not use QThread to start the thread, use native thread like std::thread and from there you can initialize the QApplication and call exec. But it's not that simple, because the application must be created in the "main" thread because there might be global objects. So you may want to dlopen Qt from the new thread to initialize the global object from that thread. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
