MessageDlg mit falschem Default

[himitsu]

Ich bin mir sicher, dass ging mal, aber gerade bemerkt, dass es nicht mehr geht.
Und ich kann mir eigentlich nicht vorstellen, dass es wirklich kaputt sein sollte, ohne dass es einer gemerkt hat...

Delphi XE + Windows Server 2016 mit aktiven Themes (10.2 teste ich heute abend auch mal),
also intern geht es auf TTaskMessageDialog. (nicht die selbstgebauten VCL-TForm aka TMessageForm / CreateMessageDialog)

Die ersten beiden Fragen sollten den [NEIN]-Button aktiviert haben, aber es ist [JA], was bei [Leerzeichen] und [Enter] nun zu Fehlern führt.

Delphi-Quellcode:

if oneonly then
  R := MessageDlg(S, mtCustom, [mbYes, mbNo], 0, mbNo)
else
  R := MessageDlg(S, mtCustom, [mbYes, mbNo, mbNoToAll, mbYesToAll, mbAbort], 0, mbNo);
case R of
  mrAbort:
    Abort;
  mrYes:
    Result := True;
  mrYesToAll: begin
    YesToAll := MessageDlg('Wirklich "JA" für Alle?', mtCustom, [mbYes, mbNo], 0, mbNo) = mrYes;
    Result   := True;
  end;
  mrNoToAll: begin
    NoToAll := True;
    Result  := False;
  end;
  else {mrNo or [X]}
    Exit(False);
end;

[Der schöne Günther]

Bei mir (10.0 Seattle) haben alle Dialoge "Nein" vorausgewählt.

[Luckie]

Hatten die nicht mal die Werte der Konstanten geändert? Da war doch mal was.

[Uwe Raabe]

Scheint ein Fehler in XE zu sein:

Delphi-Quellcode:

// aus Dialogs.pas in XE
          Default := DlgBtn = DefaultButton;

// aus Vcl.Dialogs.pas in 10.2.3 
          if DlgBtn = DefaultButton then
            Default := True;

Wirkt sich nur aus, wenn nach mbNo noch weitere Buttons kommen.

[Redeemer]

Bei D2009 ist bei der 1. und 3. Frage "Nein" ausgewählt und bei der 2. "Ja".

@Uwe: Stört hier, dass man Default überhaupt (also auch auf False) setzt?

[himitsu]

Zitat:

Zitat von Redeemer (Beitrag 1406157)

@Uwe: Stört hier, dass man Default überhaupt (also auch auf False) setzt?

Nach dem Tipp hab ich das grade mir nochmal angesehn und die Antwort ist JA.

Es wird als Property dem Button-Item zugewiesen, aber intern wird in der Liste DefaultButton:=ButtonItem gespeichert, und bei False halt DefaultButton:=NIL.
Da ist eigentlich der Fehler in der Liste, bzw. in diesem Setter, welcher beim False nur bei OwnerList.DefaultButton=Self das NIL setzen dürfte.

Das vor Aufruf des Setters (Setzen des Property) abzufangen mag hier funktionieren, aber so ganz richtig ist diese Lösung IMHO nicht.

Delphi-Quellcode:

procedure TTaskDialogBaseButtonItem.SetDefault(const Value: Boolean);
begin
  if Value then
    TTaskDialogButtons(Collection).DefaultButton := Self
  else if TTaskDialogButtons(Collection).DefaultButton = Self then
    TTaskDialogButtons(Collection).DefaultButton := nil;
end;

Im neuen Delphi wurde der Fehler also doppelt behoben. (der Setter hätte gereicht :stupid:)

Das mit dem DefaultButton in alten Delphis funktioniert somit nur, wenn es zufällig der letzte Button ist, also der mit dem höchsten Wert in TMsgDlgButtons/TMsgDlgBtn. :wall:

Meine Lösung wird wohl sein, dass ich UseLatestCommonDialogs auf False setze. (IFDEF XE ... muß am Montag nur nochmal nachsehn, dass im XE der Fehler nur im TTaskDialog liegt)

Zitat:

Zitat von Luckie (Beitrag 1406131)

Hatten die nicht mal die Werte der Konstanten geändert? Da war doch mal was.

Ich versuche sowieso immer die Konstanten zu nehmen, so dass es hier keine Probleme gibt.
Und beim Speichern in INI/Regisrty speichere ich gern die Namen, anstatt den Werten, was selten knallt.
(außer beim FMX, wo sogar die hauseigenen DFMs abrauchten, als Emba da mehrmals die Bezeichner änderte ... alTop zu TAlignLayout.Top, ohne dass das neue Delphi beide Namen lesen kann :lol:)

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1406134)

Scheint ein Fehler in XE zu sein:

Delphi-Quellcode:

// aus Dialogs.pas in XE
          Default := DlgBtn = DefaultButton;

// aus Vcl.Dialogs.pas in 10.2.3 
          if DlgBtn = DefaultButton then
            Default := True;

Jupp, ist nur ein halber Fehler, denn in CreateMessageDialog (eigene TForm) ist es so, wie im 10.2.3,
aber in der DoTaskMessageDlgPosHelp (TaskDialog-API) ist/war es falsch.

Es läst sich also ganz leicht die fehlerhafte API-Implementation deaktivieren.

Delphi-Quellcode:

// beim Programmstart
{$IF Declared(UseLatestCommonDialogs) and (CompilerVersion < 23)}
  UseLatestCommonDialogs := False;
{$ENDIF}

Allerdings wollen wir einige der anderen neuen Dialoge haben (VerzeichnisAuswahl usw.) und da bei uns sowieso fast alles nochmal weggekapselt ist, habe ich da an den wichtigstens Stellen nun sowas eingebaut.

Delphi-Quellcode:

{$IF CompilerVersion < 23}
// XE-Bugfix für DefaultButtons  https://www.delphipraxis.net/196905-messagedlg-mit-falschem-default.html
SaveULCD := UseLatestCommonDialogs;
try
  if (DefaultBtn in DlgButtons) and (Word(DlgButtons - [DefaultBtn]) > Word([DefaultBtn])) then
    UseLatestCommonDialogs := False;  // nur, wenn Default nicht der "letzte" Button ist
{$IFEND}

// z.B. MessageDlg()

{$IF CompilerVersion < 23}
finally
  UseLatestCommonDialogs := SaveULCD;
end;
{$IFEND}

[Redeemer]

Hier noch ein Beitrag zum Thema „MessageDlg macht komische Dinge bis Delphi XE“ (getestet mit 2009):

Delphi-Quellcode:

case MessageDlg('Ja oder nein?', mtWarning, mbYesNo, 0) of

end;

Wie viele verschiedene TModelResult kann der Nutzer anklicken?

Lösung (Zeile markieren): Drei, nämlich mrYes, mrNo und mrCancel.

Folgender Code funktioniert zwar in XE2, bringt einen aber in vorherigen Versionen in große Schwierigkeiten, wenn der Nutzer auf die Idee kommt, Esc zu drücken oder auf X zu klicken und sich wundert, warum alle Dateien weg sind.

Delphi-Quellcode:

if MessageDlg('Möchten Sie alle Dateien auf ihrem Computer löschen?', mtWarning, mbYesNo, 0) = mrNo then Exit;
LöscheAlleDateien();

Wer also noch mit diesen Versionen unterwegs ist und MessageDlg benutzt: Passt bloß auf! Der CnPack-Designer macht es nämlich auch falsch.

[himitsu]

Zitat:

Zitat von Redeemer (Beitrag 1413061)

wenn der Nutzer auf die Idee kommt, Esc zu drücken oder auf X zu klicken und sich wundert,

Darum macht man bei sowas auch immer nur Positivabfragen,
also auf JA prüfen (

Delphi-Quellcode:

MessageDlg(...) <> mrYes

), nach welchem auch gefragt wurde, anstatt auf NEIN (

Delphi-Quellcode:

MessageDlg(...) in [mrNo, mrCancel, mrAbort]

).

Oder eben

Delphi-Quellcode:

) = mrYes

und dieses gefährlich versteckte EXIT entsorgen, für welches jemand gesteinigt werden sollte.



Aber dass auch ESC und [X] ein Ergebnis liefern, das war schon immer so und ist auch so geblieben.

[Redeemer]

Sie liefern aber in neueren Delphis "Nein" und nicht "Abbrechen". Und außerdem nur bei MessageDlg, bei den anderen beiden derartigen Methoden kann das Fenster nicht geschlossen werden.

Mit Exit sehe ich kein Problem, CnPack macht es auch schön bunt, da fällt es auf.