12

Do I miss any Qt functionality if I substitute QApplication::exec() with standard Windows message loop implementation? This should clarify what I mean:

The ususal “Qt” way to run event processing:

int main(int argc, char *argv[])
{
 QApplication a(argc, argv);
 Window w;
 w.show();
 return a.exec();
}

“Windows” way to run event processing:

#include <Windows.h>

int main(int argc, char *argv[])
{
 QApplication a(argc, argv);
 Window w;
 w.show();

 MSG msg;
 while(GetMessage(&msg, 0, 0, 0)){
    TranslateMessage(&msg);
    DispatchMessage(&msg);
 }

 return msg.wParam;
}

The above demonstrates having external message loop with respect to QApplication instance, while QApplication instance itself doesn’t even have its own event loop at all.

In other words, if I have main.exe program (knowing nothing about Qt) with message loop and a .dll with Qt GUI and QApplication instance inside, will it be ok to let the external message loop from main.exe to handle events for Qt GUI? Thanks in advance!

EDIT 1: I’ll just answer myself in case it’s usefull for somebody: We have a main .exe module written in C# under .NET that runs event loop processing, and we have a couple of .dlls written in Qt/C++ that have a GUI “inside” (and a QApplication instance that is shared). QApplication::exec() is never called but all the events are successfully dispatched by the main .exe (.NET) module’s event loop and all the Qt functionallity is present( signals/slots, threads, etc.)

EDIT 2: That worked for Qt 4.8.2 but for Qt 5.1.0 things are a little bit different. Now you have to call QApplication::processEvents() once because it performs some initial initialization on its first call( installs WindowsHook on GetMessage or PeekMessage ). And after that whoever calls GetMessage in your application Qt events get processes and you are golden :)

Terenty Rezman
  • 357
  • 2
  • 12
  • You can create a test Qt DLL that just shows a dialog, and execute it from a test windows application that also shows a dialog, and see how it works. – sashoalm May 14 '13 at 11:30
  • I did and it seemed to work fine, but I am not sure if the full functionality is enabled – Terenty Rezman May 14 '13 at 11:55
  • is the class `Window` a custom class? – UmNyobe May 14 '13 at 12:29
  • @UmNyobe yes, its a custom class derived from `QMainWindow` – Terenty Rezman May 14 '13 at 13:27
  • Your application will no longer be able to use socket connections. Those are handled by the event dispatcher on the GUI thread through a call to `MsgWaitForMultipleEvents`. You neither have access to the event object, nor does the framework emit the respective signals. Don't try this at home, unless you're happy with a system that mostly works. Which is basically Qt's normal mode of operation anyway. – IInspectable Sep 02 '14 at 15:21

1 Answers1

1

The first thing which comes to my mind is that calling slots across threads won't work because the Qt event loop is executing those calls.

But the more important question is probably: Why do you want to do it like this especially since in qeventdispatcher_win.cpp is doing essentially the same thing?

  • Thanks for the answer. I am supposed to create GUI dlls that are going to be used by a .NET application which already has its own message loop. – Terenty Rezman May 14 '13 at 14:13
  • 2
    @Terenty Rezman In that case, you can periodically call QCoreApplication::processEvents(). You may also need to construct a dummy QApplication or QCoreApplication object when your DLL loads. It's been a while since I did something similar (Qt in a DLL running within an MFC app), but mostly worked when I did it. – darron May 14 '13 at 14:42