Abarbeitungsreihenfolge Modale Ereignisse

[DSCHUCH]

Hallo,

ich habe eine Form, welche Modal geöffnet wird. Diese hat 2 Buttons mit mrOk und mrAbort. Es gibt ein Ereignis "OnClose" mit Action=caFree;

Wenn ich jetzt folgenden Code aufrufe:

Delphi-Quellcode:

If MyModalForm.ShowModal=mrOk then
   MyModalForm.GetUserinput;

Wird ja durch das ModalResult offenbar zuerst die Form geschlossen, mein Code weiterabgearbeitet und anschliessend erst das Close mit caFree aufgerufen. (durch Debugmessages soweit ausgetestet)

Wie ist das technisch gelöst? Das Close Ereignis scheint hier irgendwie zeitversetzt - nach dem eigenen Code aufgerufen zu werden? Wird dies über Messages gelöst?

Theoretisch könnte ich ja auch:

Delphi-Quellcode:

If MyModalForm.ShowModal=mrAbort then
   MyModalForm.Close; // Free????? => Unterschied?

aufrufen, wäre dies dann möglicherweise ein Doppelaufruf des Destruktors, da das eigentliche ModalResult auch noch versucht die Form zu Closen?

[Mavarik]

Das cafree im onClose ist eher für MDIClient-Fenster oder nicht modale Fesnter gedacht...

Modale Fenster würde ich immer selber mit einem .free ausstatten...

Delphi-Quellcode:

MyWin := TMyWin.Create(Application);

try
  if MyWin.Showmodal = MROK then
    MyWin.Foo;

finally
  MyWin.free;
end.

[himitsu]

Grundsätzlich darf sich das Fenster "niemals" selber freigeban (caFree oder Dergleichen) wenn nach dem ShowModal nochmal auf das Fenster, bzw. die Form-Variable zugegriffen wird!

[sx2008]

Ich greife hier das Beispiel von Mavarik auf und habe dazu noch Ergänzungen:

Delphi-Quellcode:

var
  MyWin : TMyWin;  // *1
begin
  MyWin := TMyWin.Create(nil {*2});
  try
    MyWin.Property1 := ...;  // *3
    MyWin.Property2 := ...;
    if MyWin.Showmodal = MROK then  /* 4
    begin
      x := MyWin.Property1;  // *5
      y := MyWin.Property2;
    end;
  finally
    MyWin.free;
end.

*1) man sollte immer eine lokale Variable für das modale Formular verwenden
die globale Variable, die Delphi imer automatisch anlegt sollte man auskommentieren.
*2) immer nil als Owner übergeben. Übergibt man Application als Owner ist das messbar langsamer
weil unter Umständen mehrere 100 - 1000 Mal die Methode Notify aufgerufen wird.
*3) optional Werte vorbelegen
*4) Immer das modale Result abfragen
*5) Werte vom modalen Formular entgegennehmen und speichern
Bei sehr vielen Werten am Besten einen Record oder eine Klasse verwenden.

[DSCHUCH]

Hallo, danke für die Antworten.

Theoretisch schön und gut. Praktisch fehlt mir die technische Validierung der Aussagen. ;)

1) Ist irgendwo niedergeschrieben / technisch validiert, dass ich caFree in CloseAction nicht für Modale Formulare nehmen darf? Ich glaube das nämlich nicht, da es A) richtig funktioniert und B) ich erwarten würde, das dann eine Exception ala "eine sichtbare Form kann nicht modal gemacht werden" wirft.

2) Ist die frage, wieso es nachgewiesener maßen in der richtigen Reihenfolge abgearbeitet wird. Ein ModalResult löst ein Close (hier caFree), dieses aber kein direktes Destroy der Form aus. Der Code wird richtig abgearbeitet und erst anschliessend wird das Modale Form destroyed (siehe Bsp im Anhang)

2.1) Interessanterweise passiert etwas mergwürdiges, wenn man MessageBoxes einbaut: diese werden nämlich in der falschen Reihenfolge angezeigt. Bsp siehe Anhang: Vergleiche Ausgaben im DebugMemo und die MessageBoxes, bei aktivierter CheckBox "Bei Close und Free MessageBox"

3) zusäzlich habe ich das ganze im Bsp im Anhang nochmal in eine DLL gepackt. Über die beiden Buttons kann man das gleiche Form nun einmal innerhalb der Exe und einmal über DLL-Aufruf starten. Dabei fällt auf, dass das Verhalten komplett anders ist: Anwendungsicon der Form fehlt (soweit klar, keine Ressource) ABER: das Modale Form verhält sich anders: es blinkt nicht, wenn man auf das dahinterliegende Hauptform clickt, weiterhin passiert hier genau der effekt, dass die Anwendung plötzlich die Z-Reihenfolge verliert: klickt der Anwender jetzt einmal unten auf den falschen TaskbarIcon, ist die Anwendung geblockt da das modale Formular im Hintergrund verschwunden ist. (besonders interessant, wenn kein TaskbarIcon...)

Zitat:

Zitat von sx2008 (Beitrag 1205158)

*2) immer nil als Owner übergeben. Übergibt man Application als Owner ist das messbar langsamer
weil unter Umständen mehrere 100 - 1000 Mal die Methode Notify aufgerufen wird.

dazu gibt es einen sehr ausführlichen artikel auf about.com: http://delphi.about.com/od/kbcurt/ss...iccreateno.htm

[DSCHUCH]

Es ist wie vermutet: die Form wird durch das Modal nur Unsichtbar. Close mit caFree sendet nur ein CM_RELEASE wodurch die Form erhalten bleibt, bis die anwendung das nächste mal Idle wird (bzw Application.Process/Handle- Messages ?? => noch nicht geprüft)

http://stackoverflow.com/questions/2...rm-release-nil

wie Modal überhaupt abgebildet wird, sieht man ja in Forms.pas => "function TCustomForm.ShowModal: Integer;"

Ich kann zwar noch nicht finden, wodurch überhaupt das Close aufgerufen wird, da die Schleife ja nur ein Hide am Ende aufruft, nie ein Close.
aber wird es ja offensichtlich....
... ich kann somit keinen technischen Grund sehen, wieso caFree bei Modalen Formen nicht verwendet werden sollte.?

[Sir Rufo]

Wenn man weiß, was man da macht, dann darf man alles mögliche.

Delphi-Quellcode:

with

ist ok

Delphi-Quellcode:

caFree

bei einer modalen Form ist ok

Allerdings gibt es hier implizierte Funktionalitäten, die Seiteneffekte nach sich ziehen können und dann ist das Geschrei groß.

Wenn du robusten und wartbaren (auch durch andere) Code schreiben möchtest, dann lässt man dieses einfach weg.

It's up to you

[sx2008]

Zitat:

Zitat von DSCHUCH (Beitrag 1205217)

... ich kann somit keinen technischen Grund sehen, wieso caFree bei Modalen Formen nicht verwendet werden sollte.?

1.) Formular (lokal) erzeugen
2.) optional Werte voreinstellen
3.) Formular modal anzeigen
4.) Werte übernehmen und weiterverarbeiten (falls ModalResult= mrOK)
5.) Formular freigeben

Jede Abweichung von diesem Ablauf verschlechtert die Codequalität weil unerwünschte Effekte möglich werden.