Vermisse ich eine Qt -Funktionalität, wenn ich QApplication::exec() durch die Standard-Implementierung der Windows-Meldungsschleife ersetze? Dies sollte verdeutlichen, was ich meine:
Der übliche "Qt" -Weg zur Ausführung der Ereignisverarbeitung:
%Vor%"Windows" Möglichkeit, die Ereignisverarbeitung auszuführen:
%Vor% Das obige Beispiel zeigt eine externe Nachrichtenschleife in Bezug auf QApplication instance, während QApplication instance selbst gar keine eigene Ereignisschleife hat.
Mit anderen Worten, wenn ich main.exe program (keine Ahnung von Qt) mit Nachrichtenschleife und .dll mit Qt GUI und QApplication instance innerhalb habe, ist es in Ordnung, die externe Nachrichtenschleife von% zu lassen co_de% um Ereignisse für Qt GUI zu behandeln?
Vielen Dank im Voraus!
EDIT 1: Ich antworte nur, falls es für jemanden nützlich ist: Wir haben ein Haupt-.exe-Modul, geschrieben in C # unter .NET, das die Verarbeitung von Ereignisschleifen ausführt, und wir haben einige in Qt / C ++ geschriebene .dlls, die eine GUI "innen" haben (und eine QApplication-Instanz, die geteilt wird). QApplication :: exec () wird nie aufgerufen, aber alle Ereignisse werden erfolgreich durch die Ereignisschleife des Hauptmoduls .EXE (.NET) ausgelöst und alle Qt-Funktionen sind vorhanden (Signale / Slots, Threads, usw.) .)
EDIT 2: Das funktionierte für Qt 4.8.2, aber für Qt 5.1.0 sind die Dinge ein bisschen anders. Jetzt müssen Sie QApplication :: processEvents () einmal aufrufen, da es beim ersten Aufruf eine initiale Initialisierung durchführt (installiert WindowsHook auf GetMessage oder PeekMessage). Und danach, wer auch immer GetMessage in Ihrer Anwendung ruft Qt-Ereignisse bekommen Prozesse und Sie sind golden:)
Das erste, was mir in den Sinn kommt, ist, dass das Aufrufen von Slots über Threads nicht funktioniert, weil die Qt-Ereignisschleife diese Aufrufe ausführt.
Aber die wichtigere Frage ist wahrscheinlich: Warum willst du es so machen, besonders weil qeventdispatcher_win.cpp im Wesentlichen dasselbe macht?