Qt-Programm beenden (besteht nur aus Dialog)

[dead-raven]

Hallo,

mir ist nicht ganz klar, wie ein Qt-Programm im Zusammenhang mit modalen bzw. nicht modalen Dialogen beendet wird.

Nach diversen Versuchen konnte ich folgendes Verhalten feststellen:

Beispiel 1: Programm wird nach schließen des Dialogs beendet:

Code: Alles auswählen

#include <QApplication>
#include "filedialog.h"

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);

    FileDialog w;
    w.show();

    return a.exec();
}

Beispiel 2: Programm wird nach schließen des Dialogs nicht beendet:

Code: Alles auswählen

#include <QApplication>
#include "filedialog.h"

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);

    FileDialog w;
    w.exec();

    return a.exec();
}

Soweit ich das verstehe, wird im ersten Beispiel der nicht modale Dialog erst mittels a.exec() angezeigt. Wieso wird hier Qt::WA_QuitOnClose nicht zum beenden der Applikation benötigt?

Im zweiten Beispiel startet der modale Dialog jedoch eine local event loop, welche vor der loop von a.exec() ausgeführt wird. Ist es richtig, dass die event loop der Applikation "a" erst dann startet, nachdem die des Dialogs abgeschlossen ist (durch schließen des Interfaces)?
Sollte dies der Fall sein, wird dann überhaupt "a.exec()" benötigt, oder wäre ein "return 0;" sinnvoller?

Gruß
DeaD-RaveN

[RHBaum]

Im zweiten Beispiel startet der modale Dialog jedoch eine local event loop, welche vor der loop von a.exec() ausgeführt wird.

Koennte man so sehen ...
Weiss ned genau wie es die Qt intern macht, aber die win32 API haengt bei nem globalen Dialog dessen eventschleife in die globale Main Eventschleife ein, und gibt den focus erst zurueck, wenn sich der modale dialog beendet.

denk mal die qt macht es aehnlich ....

das sich dein beispiel 1 beendet, haengt sicher damit zusammen, das deine qt so eingestellt ist, das wenn das letzte Fenster geschlossen ist, sich auch die Application schliesst ....
Da dein dialog da nicht modal ist ... haengt sich der dialog sicher auch in den eventmechanismus ein, blockiert aber ned die eventschleife ... ergo wird die globale eventschleife danach auch gestartet.
Schliesst du nun dein nichtmodales fenster, bekommt das auch die Applikation mit, die merkt das es dein einzigstes und letztes fenster war, und schickt sich auch das exit.
Das verhalten kann man uebrigens abstellen ^^

Beispiel 2 iss klar, warum sich die app ned beendet ... der aufruf des dialogs blockiert, und deine App kriegt das schliessen deines einen fensters gar ned mit, weil deren eventqueue ja noch ned gestartet wurde, die kann sich also ned beenden ^^

Sollte dies der Fall sein, wird dann überhaupt "a.exec()" benötigt, oder wäre ein "return 0;" sinnvoller?

wenn deine anwendung aus nur einem modalen dialog besteht, brauchst die (globale)Eventloop der Application ned starten ....
Die application selber wirst aber brauchen, weil die die eventloop selber erzeugt, die Dein modales fenster wahrscheinlich benutzt. Aber das exec auf der App brauchst definitiv ned ausfuehren.

Auf der anderen seite, macht es meistens keinen Sinn in einer App nur einen modalen dialog zu starten.
Klar koenntest du dein eigenes QMainWIndow implementieren, welches von QDialog ableites und gleich modal hochschiesst.
Bei einfachen anwendungen waer das fuer den user kein unnerschied. Aber auch nicht notwendig. Dafuer verzichtest du aber auf die vorteile einer globalen eventqueue ... die koenntest keine timer nutzen, und keinerlei QT Objecte benutzen, die assynchrone funktionalitaet ueber die eventqueues (und damit auch signal slot mechanismus ueber threads hinweg) bieten (QSocket z.b.)
Auf der anderen seite gewinnst ned viel ... App erzeugen, Nichtmodalen dialog starten, App-Eventqueue starten, bei schliessen des hirarich obersten Fensters (QMainWindow meist) auch die EventQueue der Application beenden ... resultiert ja in quasi modaler Verhaltensweisse der user merkt da keinen unnerschied

Es gibt sogar Anwendungsfaelle wo ich es umgekehrt machen muss ....
nen modaler dialog blockiert deine eventqueues. Will ich aber in der zeit wo der modale dialog offen ist ... trotzdem assynchrone events (beispielweisse timer oder statusaenderungen an nem socket oder anederung an nem filesystem von ausen ... etc) zeitecht empfangen, und nicht alles gesammelt sobald ich den dialog schliesse, dann geht das mit nem modalen dialog ned, sondern ich muss die modalitaet an einem nichtmodalen dialog nachprogrammieren, zumindest das was der user von der modalitaet sieht, und das nur um die eventqueue am laufen zu halten.

Ciao ...

[dead-raven]

kk vielen dank!

mfg
DeaD-RaveN