Warnung ModalResult und Delphi-Update

[Rainer Wolff]

Oder Modal-Result und auf die Schnauze fallen.

Zur Warnung an alle unbedarften:

Irgendwo zwischen XE und Berlin wurden die ModalResult-Konstanten teilweise geändert.

In der dfm werden aber keine Konstanten, sondern absolute Zahlen gespeichert. Somit bekommt ein Button, in einer neueren Version geöffnet, plötzlich eine andere Konstante als ModalResult.
Und bei einer Abfrage:

if Form.ShowModal = mrYesToAll then ...

trifft plötzlich die Bedingung nicht mehr zu, da ShowModal immer noch den alten Zahlenwert (hier 10) zurückgibt, mrYesToAll aber mit 14 neu definiert ist.

[Daniel]

Bist Du sicher, dass die Quelle der Konstanten identisch ist oder hast Du eine Unit eingebunden, die diese Konstanten ihrerseits auch - und eben anders - definiert?

[Rainer Wolff]

Zitat von Daniel:

Bist Du sicher, dass die Quelle der Konstanten identisch ist oder hast Du eine Unit eingebunden, die diese Konstanten ihrerseits auch - und eben anders - definiert?

Eigentlich schon. Die Konstanten waren früher in der controls.pas definiert.

Code:

mrOk     = idOk;
mrCancel = idCancel;
etc.

Heute in Controls.pas:

Code:

mrOk     = System.UITypes.mrOk;
etc.

Und in der System.UITypes wurden dann einige Konstanten dazwischengeschoben, so daß z.B. mrYesToAll einen neuen Wert bekommen hat.
Die "simplen" Konstanten, die häufig verwendet werden, haben ihren Wert behalten (mrOk, mrCancel...)

[himitsu]

In dem Fall wäre ein Enum besser, anstatt dem Integer mit den vielen Konstanten, nur das geht nicht, wegen der nutzerdefinierten Buttons, z.B. im TaskDialog.


Aber ein Mapper (IdentToStr/StrToIdent) für die DFM würde Abhilfe schaffen, wie z.B. bei TColor (vor allem in den Property-Editoren), wo der Name und nicht die Zahlen gespeichert werden, falls der Name bekannt ist.

Sowas knallt dann aber auch wieder, wie man wunderschön an den Color-Werten im FMX sah, als dort plötzlich überall der Präfix entfernt wurde und dann die Namen nicht mehr bekannt waren.
(wenn man vergisst für StrToIdent die alten Namen als Alias drin zu lassen)



Oder man macht keine Breaking-Changes und hängt die neuen Werte immer nur hinten an.

[KodeZwerg]

Vcl.StdCtrls.TCustomButton.ModalResult besagt

Zitat:

Changes to ModalResult Values at XE2 Release
The XE2 release introduced three new ModalResult values: mrContinue, mrHelp, and mrTryAgain.

In addition, four of the existing ModalResult values changed at XE2. If your applications use any of the following four ModalResult values for TButton, you need to make code changes: mrClose, mrAll, mrNoToAll and mrYesToAll. Since these values are stored as numbers in .dfm files, the values change when you migrate a project to XE2. The values have changed as follows:

Before XE2:
mrClose=11
mrAll=8
mrNoToAll=9
mrYesToAll=10
In XE2:
mrClose=8
mrAll=12
mrNoToAll=13
mrYesToAll=14
The following table lists the constants of type TModalResult that are defined for the ModalResult property, along with their values in the XE2 release and XE release (that is, any release before XE2):

Ausführlicher gehts im Link weiter.

[Luckie]

Autsch, das

Zitat:

In addition, four of the existing ModalResult values changed at XE2.

ist aber böse. Wer rechnet denn mit so was?

[himitsu]

Der, welcher immer die What's New komplett durchliest?

[KodeZwerg]

Ich habe da eben mal ein Paar Varianten durchgespielt.

Ausgangsquelle ein Delphi 2009 Source mit alten Button-Codes.

Normal-Fall: 1x dpr, 1x pas, 1x form = Tokyo wandelt alles brav um
Steigerungs-Fall: 1x dpr, Xx pas, Xx form (stehen in .dpr) = Tokyo wandelt alles brav um
Fehler-Fall: 1x dpr, Xx pas, Xx form (per runtime) = Tokyo wandelt nur Hauptformulare um = Buttons sind nicht mehr gut drauf.
Genereller Fehler: Alte dll die auf neuen Code hören soll, da hilft nur dll recompilieren.

[Luckie]

Wie viel hundert Bildschirmseiten müsste ich mir denn dann durchlesen, wenn ich jetzt von meinem aktuelle BDS2006 auf ein aktuelles Delphi umsteige? Alte Zöpfe abschneiden, kann durchaus sinnvoll sein, aber das? Konstanten heißen ja nicht umsonst Konstanten.

Zitat:

Normal-Fall: 1x dpr, 1x pas, 1x form = Tokyo wandelt alles brav um

Aaaaah. Jetzt erscheint es in einem etwas anderen Licht. Scheint nur nicht ganz fehlerfrei zu funktionieren.

[KodeZwerg]

Hallo Luckie!
Es geht nicht um Deine Units und deren Code, es sei denn der ist Hardcoded.
Es geht um die .frm Dateien die einen Dezimalwert für Buttons nutzen.
Ich testete wie gut Tokyo die alten Nummern umwandelt.