D12: Type mystring = string erzeugt nun imkompatible Parameter bei Events

[Rolf Frei]

Bin gerade am Upgraden meiner Projekte auf D12 und dabei auf einen seltsamen Fehler gestossen. Alle Events die einen Type verewenden, der als type x=y definiert ist, erzeugen nun in der IDE den Fehler "The itrTaskListNodeLoaded method referenced by itrTaskList.OnNodeLoaded has an incompatible parameter list. Remove the reference?". Was ist hier denn nun schon wieder los und wie kann ich das beheben?

Das Folgende ist ein Beispiel, passiert aber auch bei andereren Komponenten, z.B. THtmlViewer, wo Type ThtString=string gesetzt wird.

Folgender Code stammt aus einer verwendeten Komponente:

Delphi-Quellcode:

type
  TBaseInfoNode = dcntree.TDCTreeNode;
  TNodeLoadedEvent  = procedure (Sender : TObject; Node : TBaseInfoNode) of object;

In D11 und älter wurde damit folgendes Event erzeugt:

Delphi-Quellcode:

procedure TfrmMain.itrGroupsNodeLoaded(Sender: TObject; Node: TDCTreeNode);
begin
end

D12 erzeugt nun daraus folgendes:

Delphi-Quellcode:

procedure TfrmMain.itrTaskListNodeLoaded2(Sender: TObject; Node: TBaseInfoNode);
begin
end;

Die IDE kommt hiermit nicht mehr zurecht und erzeugt den obigen Fehler, sobald ich kompilieren will. Wenn ich da sage, dass er die Referenz nicht entfernen soll, kompilliert das Programm und alles scheint zur Runtime normal ohne Fehler zu laufen. Die Event funktinoierenren also. Wo liegt hier der Fehler? Ist das ein Bug der IDE oder kann ich die Type Definition irgenwie anders angeben, damit die IDE wieer checkt, dass TDCTreeNode und TBaseInfoNode das selbe sind?

[QuickAndDirty]

Sind die Gültigkeitsbereiche und defines in dem Projekt so gesetzt wie du es erwartest?

[Rolf Frei]

Ja alles so wie es sein soll. Ich kann ja kompilieren, nur darf ich die Event Referenzen nicht löschen, wenn er mir das anzeigt, sonst würden ja die Event nicht mehr laufen. Zur Runtime läuft alles ganz normal, nur in der IDE hat er ein Problem damit.

[himitsu]

Seit Delphi 12 wird bei Typen auch der Alias-Name genommen, nicht der Name des eigentlichen Typs.
Wird nun also ein Event generiert, dann verwendet es den AliasNamen in der generierten Signatur.

Für den Designer sieht es so aus, als wäre es ein TBaseInfoNode = type dcntree.TDCTreeNode; .

Dem Compiler ist es egal, da es der "gleiche" Typ ist,
aber die Hilfsfunktionen des Form-Designers, meckern hier bissl rum.

Vielleicht ist dir aufgefallen, dass auch CodeInsight und HelpInsight dir nun den Alias zeigen, anstatt den "echen" Typ.
z.B. beim PostMessage das LPARAM, WPARAM und LRESULT, anstatt Integer, wie früher.



https://quality.embarcadero.com/brow...ncompatible%22
Siehe die Antwort von Marco Cantù.
Bin mir sicher, dass es da auch noch dutzende andere Issues dazu gab.

[Rolf Frei]

Wirklich ab D11? In D11 hatte ich mit der gleichen Eventsignatur noch nie ein Problem.

[Rolf Frei]

Soeben mal geschaut was passiert, wenn ich da das Event auf TBaseInfoNode in D11 anpassen, damit ich den selben Code in D11 und D12 nutzen kann. Geht nicht!!! Danach bekomme ich in D11 den Fehler. So ist es unmöglich Formen mit Events in D11 und D12 zu sharen. Lasse ich es wie es ist erhalte ich in D12 eine Fehler, wenn ich es auf den andern Type ändere geht es in D11 nicht mehr. Wie sind die denn auf diesen Unsinn gekommen und haben das geändert? Hiermit bricht man eine seit D1 geltende Regel und macht das Sharen von Formen zwichen Delphi Version inkompatibel. So muss man ja nun für alle betroffen Formen die man mit älteren Delphi Versionen sharen will, zwei unterschiedliche DFM's machen. Das kann doch nicht wahr sein!!!

Als Komponentenentwickler ist das doch der absolute Horror! Da verstehe ich den TRichView Entwickler, der den Bug eröffnet hat, zu 100%.

[himitsu]

12
vertippt

Also wie im verlinkten Bugreport erwähnt.
Siehe dort in den Kommentaren ... da gibt es irgendwo eine Datei, wo man im 12 solche Mappings auflösen kann.

[Rolf Frei]

Ja habe das in der erwähnten Datei so eingetragen, aber wirklich lösen tut es das Problem eben nicht. Siehe letzte Nachricht vom TRichView Entwickler. Ich kann zwar nun ohne Fehler kompilieren, aber so bleiben kann das meiner Meinung nach nicht. Da hat Emba Mist gebaut.

[himitsu]

Es gab noch ein paar andere und mindestens einen ganz langen Report dazu, mit ganz vielen Antworten drunter, so weit ich glaube mich zu erinnern ... nur finden müsste man das jetzt noch.