MessageDLg beantwortet sich selbst?

[SearchBot]

Hallo,

ich habe ein seltsames Verhalten, weiß nicht, warum das so ist und wie ich es beheben kann... :pale:

Delphi-Quellcode:

procedure TForm1.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
   CanClose:=false;
   if Editor.Modified then
    case MessageDlg('Text im Editor wurde bearbeitet. Soll vor dem Beenden dieser Text gespeichert werden?',mtConfirmation,[mbYes,mbNo,mbCancel],0) of
     idYes: begin btn_saveClick(btn_save); CanClose:=true; end;
     idNo: CanClose:=true;
     idCancel: CanClose:=false;
    end
   else CanClose:=true;

Ich habe den Dialog jetzt zunächst mit Cancel beantwortet, weil ich noch was nachgucken wollte.
Wenn ich jetzt die Anwendung wieder schließen will, poppt das Dialogfenster kurz auf und wieder weg. Im Debugger sehe ich, daß die Antwort einfach ohne Zutun auf idCancel springt.

Kann mir das Verhalten nicht erklären :cry:

[Glados]

Das Problem muss woanders liegen. Ich habe deinen Code eben in ein leeres Projekt kopiert und kann den Fehler so nicht nachstellen.
Nutzt du noch andere Events die dazwischenfunken könnten?

[mikhal]

Muss das nicht mrYes statt idYes heißen? Natürlich die anderen beiden Resultate respektive.

Grüße
Mikhal

[Aviator]

Wie wird denn das Schließen der Form initiiert? Über einen anderen Button oder über das Schließen X?

Wenn über einen anderen Button, dann wird der Fehler sicherlich dort irgendwo liegen. Weil ein MessageDlg wird nicht 2x angezeigt. Hast du evtl. bei dem zweiten Button (oder irgendwo anders) schon einen ModalResult Wert vergeben der das Schließen der Form auslöst?

Zudem halte ich es für keine gute Idee, einen Event-Handler eines Buttons manuell aufzurufen. Lagere deine Speichern Funktion in eine gesonderte Procedure aus und rufe diese auf. Siehe Beispiel:

Delphi-Quellcode:

procedure TForm1.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
  CanClose := False;
  if Editor.Modified then
    case MessageDlg('Text im Editor wurde bearbeitet. Soll vor dem Beenden dieser Text gespeichert werden?', mtConfirmation, [mbYes, mbNo, mbCancel], 0) of
     idYes:
     begin
       SaveChanges();
       CanClose := True;
     end;
     
     idNo: CanClose := True;
     
     idCancel: CanClose := False;
    end
  else
    CanClose := True;
end;

procedure TForm1.btn_saveClick(Sender: TObject);
begin
  SaveChanges();
end;


procedure TForm1.SaveChanges();
begin
  Memo1.Lines.SaveToFile();  // Oder welche Komponente auch immer bzw. wie auch immer der Speichervorgang ablaufen soll
end;

[Glados]

Zitat:

Muss das nicht mrYes statt idYes heißen? Natürlich die anderen beiden Resultate respektive.

Beides ergibt am Ende dasselbe: 6.

[hsg]

Zitat:

Zitat von Aviator (Beitrag 1382561)

Zudem halte ich es für keine gute Idee, einen Event-Handler eines Buttons manuell aufzurufen. Lagere deine Speichern Funktion in eine gesonderte Procedure aus und rufe diese auf. Siehe Beispiel:

Warum? Ich muss gestehen, dass ich tatsächlich die Event-Handler direkt aufrufe. Brauche ich die Information, ob der Benutzer den Button betätigt hat, dann kann ich das Argument Sender prüfen. Ist es nil, dann kam der Aufruf direkt aus dem Source.

[Glados]

An btn_saveClick wird es meiner Meinung nach nicht liegen.
Irgendetwas passiert vorher schon. Daher ja die Frage, welche anderen Events du noch benutzt.

[Aviator]

Zitat:

Zitat von hsg (Beitrag 1382565)

Zitat:

Zitat von Aviator (Beitrag 1382561)

Zudem halte ich es für keine gute Idee, einen Event-Handler eines Buttons manuell aufzurufen. Lagere deine Speichern Funktion in eine gesonderte Procedure aus und rufe diese auf. Siehe Beispiel:

Warum? Ich muss gestehen, dass ich tatsächlich die Event-Handler direkt aufrufe. Brauche ich die Information, ob der Benutzer den Button betätigt hat, dann kann ich das Argument Sender prüfen. Ist es nil, dann kam der Aufruf direkt aus dem Source.

Du musst nicht. Es geht auch so. Aber es ist meiner Meinung nach nicht besonders schön gelöst. Der Event-Handler ruft die Methode auf, die nur zum Speichern gedacht ist. Eventuell werden beim Button Click vorher noch Prüfungen durchgeführt die in einem anderen Fall nicht durchgeführt werden müssen. Und schon hast du den Salat. Deshalb macht man ja kleine und kompakte Funktionen die dann leichter erweiterbar sind und nicht überall direkt voll reingrätschen. Aber jedem das Seine. Ich mache es so wie ich es im Beispiel gezeigt habe und so machen es auch sehr viele andere Leute. Aber es bleibt dir überlassen wie du programmieren willst.

Aber nichts desto trotz. An dem Event-Handler liegt es sicherlich nicht. Das habe ich auch so nie gesagt. Ich habe eher das Stichwort ModalResult im Kopf. Aber auch hier bringt es nichts, dadrüber zu philosophieren. Der TE sollte sich da mal konkret du den Vorschlägen äußern und ggf. mehr SourceCode posten.

[Uwe Raabe]

Zitat:

Zitat von hsg (Beitrag 1382565)

Ich muss gestehen, dass ich tatsächlich die Event-Handler direkt aufrufe. Brauche ich die Information, ob der Benutzer den Button betätigt hat, dann kann ich das Argument Sender prüfen. Ist es nil, dann kam der Aufruf direkt aus dem Source.

Wenn du Zeit und Lust hast, dann lies mal diesen Artikel zu dem Thema: When, What, Why!

[Redeemer]

Es ist schon nicht so einfach, mit Delphi-Mitteln einen modalen Dialog zu schließen. Als ich das mal machen musste, um einen Öffnen-Dialog beim Auswählen eines bestimmten Dateityps in den Ordner zu schicken, in dem sich diese Dateien ausschließlich befinden konnten, habe ich ein Alt+F4 oder Esc per Tastendruck an den Dialog geschickt.
Ich würde auf ein anderes Programm tippen oder einen kurzzeitigen Bug im Tastaturtreiber tippen.

Letztendlich enthält dieser Thread ab mikhals Post nur Offtopic. Man könnte z.B. auch noch die völlig sinnlose erste Zeile im Quelltext diskutieren.