Standardverhalten von Dialogen (ab)ändern

[Alter Mann]

Hallo

Ich habe ein Formular mit dem BorderStyle = bsDialog und zwei Buttons (OK und Abbrechen).
Der OK-Button soll zwei Funktionen übernehmen, wenn Caption = Suche mache das und wenn Caption = Stop mache dies.

Beispiel:

Delphi-Quellcode:

procedure TSuchDialog.btnOKClick(Sender: TObject);
begin
  if (cboColumns.Text = '') or (cboFindText.Text = '') then Exit;
  if btnOK.Caption = '&Suche' then
  begin
    if (FSearchObj is TListView) and (not FSearching) then
    begin
      btnOK.Caption     := '&Stop';
      btnCancel.Enabled := false;
      SearchListView;
    end;
  end
  else
  if btnOK.Caption = '&Stop' then
  begin
    Close;
    ModalResult := mrOK;
  end;
end;

Doch egal welche Caption der btnOk hat, der Dialog wird immer geschlossen, auch wenn die erste Bedingung erfühlt ist.

Falls jemand meint CloseQuery hilft hier, das sieht so aus:

Delphi-Quellcode:

procedure TSuchDialog.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
  CanClose := not FSearching;
end;

FSearching wird mit dem Beginn von SearchListView auf 'true' gesetzt und beim beenden der Procedure auf 'false'.

Wie wird es also Richtig gemacht?

Gruß

[NickelM]

Hast du genau '&Suche' eingegeben???
Wenn du im Caption nämlich 'Suche' eingegeben hast dan nimmt er es nicht an

Auserdem ist FSearchObj wirklich TListView oder ein abgeleite klasse von TListView??
Wenn das eine etwas dumme Frage ist dan tut es mir leid dachte nur das du es vieleicht vergessen hast :oops:

[Luckie]

Nutze die Eingenschaft Tag des Buttons, dann bist du unabhängig von der Beschriftung der Schaltfläche und du kannst mit case die Funktion abfragen, die er haben soll.

[grenzgaenger]

wo meinst du denn, dass er geschlossen wird???

wenn du ModalResult := mrOK gesetzt hast?

das ist in der tat so, wenn ModalResult einen wert <> mrNone hat, wird der zugehörige Dialog geschlossen. ist aber schon immer so ...

[alzaimar]

Wäre es nicht -sagen wir- marginal sauberer, zwei Buttons zu verwenden? Einen für 'Stop' und einen für 'Suche'. Sie liegen übereinander uns sichtbar ist entweder der eine oder der andere.

Das Event für den 'Suchen' Knopf verbirgt diesen und macht den "Stop"-Knopf sichtbar und umgekehrt. Über zwei separate und einfach zu verstehende Klick-Events kann man auch die Logik übersichtlich steuern. Denn die Lösung mit den Captions knallt ja, wenn irgendwer die Knöppe mit anderen Beschriftungen versieht (z.B. Internationalisierung). Die Lösung mit der 'Tag'-Eigenschaft ist da schon besser.

[Alter Mann]

Hallo

@NickelM

Klar, verschreiben kann man sich immer!
Nicht aber im diesen Fall.

@Lukie
Das mit der Tag-Eigenschaft ist klar, nur ändert das nichts am Problem.

@grenzgaenger

Nee, sobald SerachListView abgearbeitet und damit 'FSearching = true' ist.

[edit] 'zwischengefunkt'
@alzaimar

Ja und Nein.

Warum zwei Button für die gleiche Aufgabe verwenden?
Im Zeitalter von Quad-Core und Co. mach es zwar egal sein, aber von der Funktionalität nicht.
[/edit]

@All

Mal so nebenbei:

Ist euch eigentlich schon mal aufgefallen, das da etwas Faul ist?

Man nehme eine Hauptform und ein Dialog, bei dem Dialog, BorderStyle = bsDialog.

Im Dialog, zwei Buttons und TEdit welches als property Text veröffentlicht ist,

Im OI : btnOK = Caption = 'OK' = ModalResult = mrOK.
btnCancel = Caption = 'Abbruch' = ModalResult = mrCancel.

Den Dialog aus 'Project->Optione->Formulare->Automatisch Erzeugen' nach 'Project->Optione->Formulare->Verfügbare Formulare'
verschieben.

Und ruft den Dialog im über einen Menüpunkt im Hauptformular etwa so auf:

Delphi-Quellcode:

procedure TForm1.DialogExecute(Sender: TObject);
var
  Ret :Boolean;
  St  : String;
begin
  Dialog  := TDialog.Create(Self);
  try
    Dialog.ShowModal;
    Ret := SearchDialog.ModalResult = mrOK;
    if Ret then St := Dialog.Text; 
  finally
    SearchDialog.Free;
  end;
end;

Angenommen Ihr habt im Edit einen Text eingegeben oder auch nicht, welchen Wert hat Ret wenn Ihr btnOk klickt?

Nicht raten, testen.

Gruß

[alzaimar]

Zitat:

Zitat von Alter Mann

@alzaimar...Warum zwei Button für die gleiche Aufgabe verwenden?

Aber das tun sie doch gar nicht:

Delphi-Quellcode:

procedure TSuchDialog.btnSearchClick(Sender: TObject);
begin
  if (cboColumns.Text = '') or (cboFindText.Text = '') then Exit;
  if (FSearchObj is TListView) and (not FSearching) then
  begin
    btSearch.Visible := false;
    btStop.Visible := true;
    SearchListView;
  end;
end;

procedure TSuchDialog.btnStopClick(Sender: TObject);
begin
  if (cboColumns.Text = '') or (cboFindText.Text = '') then Exit; // Wird das *wirklich* auch beim Stop verwendet?
  Close;
  ModalResult := mrOK;
end;

Wenn Du schon sagst,

Zitat:

Zitat von Alter Mann

...Der OK-Button soll zwei Funktionen übernehmen

dann solltest/kannst Du genau diese Funktionalität auch so umsetzen. Wozu sollte man sich mit schizophrenen MPS*-Buttons rumschlagen? (*MPS=Multiple PersönlichkeitsStörung)

Das hat alles im Übrigen mit Quadcores etc. nichts zu tun, sondern mit der direkten Umsetzung der Funktionalität ("zwei Funktionen"). Es kann auch Knöpfe geben, die ihre Beschriftung ändern, aber in Abhängigkeit der Beschriftung funktional sehr ähnliches ausführen. Dann würde ich auch nur einen Knopf nehmen.

Zu deiner Frage: Neben den üblichen Flüchtigkeitsfehlern ('Dialog' vs. 'SearchDialog') kannst Du das Funktionsergebnis der Methode 'ShowModal' auswerten und nicht den Wert der Eigenschaft 'ModalResult' (kommt aber -denke ich- aufs Gleiche heraus). Bei mir funktioniert es jedenfalls so wie erwartet.
[edit]Der Linker eliminiert übrigens die Zuweisung 'St := ...' sowie 'Rt := ...', da diese irrelevant sind. [/edit]

[Alter Mann]

Hi,

Überredet.

MPS*-Buttons :thumb: Werde ich mir merken.

[grenzgaenger]

auch auf die gefahr hin, dass die psychologen selbst 'ne persönlichkeitsstörung bekommen... hier mal 'n beispiel eines MPS Dialogs ...

wichtig dabei ist, dass man den kopf vom körper trennt... der eine lenkt der andere teil arbeitet... aber nix mischeln ... :witch:

[Alter Mann]

So, So

MPS Dialog: OK.

Habe da auch einen der nur ein wenig MPS ist, aber dafür anders.

[grenzgaenger]

wenn du den wert ModalResult <> MrNone setzt, wird dein form geschlossen. wenn du dann beim button click noch mals den modalresult setzt, wird dein vorheriger überschrieben...

wenn du also den modalresult im button setzt (wie in deinem beispiel), darfst du das close nicht mehr verwenden, wenn du das ergebnis auswerten möchtest.

<HTH> GG

[TBx]

Hallo Alter Mann,

das Phänomen erklärt soich wie folgt:

Vor Aufruf des OnClick-Ereignisses wird der Wert aus ModalResult an die Form weitergegeben.
In Deiner Ereignisbehandlung ruftst Du Close auf. Close besetzt modalResult mit mrCancel (2).
Damit ist der Wert von Modalresult schon wieder geändert, bevor dieser ausgewertet wird.

Gruß

Thomas

[Alter Mann]

Hallo Thomas

genau das meinte ich.

Was mich an der ganzen Sache stört ist der Ablauf als solches.
Weise ich den Buttons keine Ereignisbehandlung zu, werden die ModalResult-Werte der Buttons
zurückgegeben ansonsten immer mrCancel. Super Logik.

Gruß

[TBx]

Zitat:

Zitat von Alter Mann

Weise ich den Buttons keine Ereignisbehandlung zu, werden die ModalResult-Werte der Buttons
zurückgegeben ansonsten immer mrCancel. Super Logik.

Stimmt so nicht ganz, andere Befehle als Close werden durchaus ausgedführt und dann Modalresult nach Abarbeitung der Ereignisbehandlungsrutine behandelt.
Aber in der Procedure Close wird Modalresult für Modale Fenster explizit gesetzt.
In einem Aktuellen Projekt gebe ich in der OnClick-Rutine Eines Buttons per Showmessage eine Nachricht aus. Der Button hat ModalResult = mrOk eingestellt.
Nach bestätigen der Showmessage, schließt sich aufgrund des Modalresult die Form.

Gruß

Thomas

[grenzgaenger]

was du machen könntest, wäre die close methode deiner form zu überschreiben und die rückgabewerte entsprechend zu setzen...

[Alter Mann]

Ist schon Okay.

Es reicht jetzt :thumb:

Wir haben das Thema genug erörtert, ich habe etwas dazu gelernt und gut.

Schönes Wochenende und

Tschüß :cheer: