@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
)
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.
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)
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
)