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.