![]() |
Warnung ModalResult und Delphi-Update
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. :wall::wall::wall::wall::wall::wall::wall: |
AW: Warnung ModalResult und Delphi-Update
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?
|
AW: Warnung ModalResult und Delphi-Update
Zitat:
Code:
Heute in Controls.pas:
mrOk = idOk;
mrCancel = idCancel; etc.
Code:
Und in der System.UITypes wurden dann einige Konstanten dazwischengeschoben, so daß z.B. mrYesToAll einen neuen Wert bekommen hat.
mrOk = System.UITypes.mrOk;
etc. Die "simplen" Konstanten, die häufig verwendet werden, haben ihren Wert behalten (mrOk, mrCancel...) |
AW: Warnung ModalResult und Delphi-Update
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. :stupid: (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. :stupid: |
AW: Warnung ModalResult und Delphi-Update
![]() Zitat:
|
AW: Warnung ModalResult und Delphi-Update
Autsch, das
Zitat:
|
AW: Warnung ModalResult und Delphi-Update
Der, welcher immer die What's New komplett durchliest?
|
AW: Warnung ModalResult und Delphi-Update
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. |
AW: Warnung ModalResult und Delphi-Update
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. :roll:
Zitat:
|
AW: Warnung ModalResult und Delphi-Update
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:45 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz