Na dann mal willkommen 8)
Ich versuch mal Deine Fragen vorsichtig zu beantworten.
Was bedeutet dies? und vor allem wann wird er denn beendet.
Was verstehst du unter beenden ???
QT Gui Objecte interagieren mit dem BS. Das heisst, dein QDialog, das auch nen QWidegt ist, und damit auch nen QPaintdevice wird im hintergrund sicher irgendwo nen handle auf nen BS spezifisches fensterObject haben.
Wann das zeugs "freigegeben" wird, iss sicherlich ned so einfach zu bestimmen.
Genau so kann es eigene Klassen im hintergrund weiter behandeln ...
Dieses Caching iss normal. Wichtig iss das du es nicht beachten solltest, und erst recht ned zu benutzen. Wenn du ressourcen frei gibst .. sind sie fuer dich weg ! Was die QT macht, wurscht !
Was bedeutet dies?
Fuer dich eben eigentlich nix !
rufst du einen QDialog modal mit exec() auf.... und due beendest den intern durch ein accept / reject, dann kehrt in dem moment dein Exec zurueck.
Dein QDialog selber iss noch gueltig, du koenntest den nochmal mit exec aufreufen ... erst wenn du den QDialog leoschst, also bei dynamischer erzeugung ueber delete bzw statisch wenn deine variable ausm scope rennt, dann kommst nimmer drauf. Und was der im hintergrund tut .. oder er die GUI objecte wirklich freigibt, oder nur auf invisible setzt ... iss egal.
Rauskriegen kann man das, in dem man mal mit dem windows spy z.b. schaut, was da alles fuer systemnachrichten fliessen. aber verwenden sollte man die erkenntnisse keinenfals. nur vielleicht im hinterkopf behalten.
Mit show wird ja einfach nur das Window angezeigt,
nein, es wird auf sichtbar gesetzt ... zum anzeigen brauchst du meist eine lauffaehige eventloop. ... es wird sicher an der stelle nix angezeigt.
Stell dir vor, du machst nur das show, laesst einfach das exec nie laufen, oder verzeoegerst es ... das heisst, dein fehster wuerde entweder unvollstaendig oder gar nicht gezeichnet(paint event) und keiner deiner GUI Objecte (buttons z.b.) koennte ne usereingabe machen.
Das show wird dir eigentlich nur nachrichten generieren, die dein fenster sichtbar machen. Aber biss in die eventloop eintrittst, werden die nur in der schleifen vorhanden sein, aber nie irgendwas bewirken. erst wenn die eventloop startest (exec) werden die befehle darin abgearbeitet und and das BS durchgereicht, und auch erst dann kommst du in die paintereignisse der subfenster, so dass ueberhaupt was benutzerdefiniertes zeichnen koennetest.
also Klicks und so und dies an die richtigen Klassen weiterleitet
Genau das macht die eventqueue. Wobei du in dem fall eigentlich 2 hasst. Die von der winapi und die von QT, wobei die sicher gut verzahnt miteinander sind.
Und das Programm endet dann eben mit quit().
wenn deine QApplication ein Quit bekommt (es gibt mehrere events, die wenn sie fertig sind ein quit an die App schicken koennen) stigst du aus der eventquee aus, sprich deine exec() funktion kommt zurueck. Alles andere spielt sich eigentlich aus sicht der main() im aufruf von exec() ab
dialog->setAttribute( Qt::WA_QuitOnClose )
Damit setzt du eine eigenschaft des Dialogs. Das heisst, nix anderes, als wenn dieses fesnter geschlossen wird (also die dazugoehirigen Gui elemente auf Hide gesetzt werden, oder auch gleich freigegeben) wird danach noch der Application das Quit ereigniss geschickt. damit fliegt die Application aus der Schleife, quasi dein exec beendet sich, und in normalen qt programmen iss dann auch schluss, das heisst dein main lauft aus, alle objecte fleiegen ausm scope, die main beendet sich, die globale aufraeumroutine wird aufgerufen um evtuelle globale scahen noch zu bereinigen und dein programm wird dann beendet, schickt paar signale ans BS, worauf das BS wiederum den prozess aufraeumt ...
Damit ersparst du dir eigentlich ne seperate verbindung. Gibt nochn anderen weg, du kannst die app sich auch beenden wenn es kein aktives fenster mehr gibt. dann kann die app sich selber auch das quit schicken ...
machst du das ned, und deine fenster wuerden schliessen, wuerde deine loop sich nie beenden, und dein exec ned auslaufen, deine app sich nie beenden, du muesstest die killen.
alternativ zu den komfortablen dingen , kannst auch das close event von dem fenster mit dem application quit verbinden, das hat den selben effekt.
Ciao ...
