Delpi2007->XE2 geänderte Ereignis-Parameterliste

[Keldorn]

Hallo,

ich habe eines meiner Projekte von Delphi2007 zu XE2 umgestellt.
Bsp, sahen 2 Ereignismethoden bei HTTPRio so aus

Delphi-Quellcode:

    procedure HTTPRioBeforeExecute(const MethodName: string; var {!} SOAPRequest: WideString{!});
    procedure HTTPRIOAfterExecute(const MethodName: string;SOAPResponse: TStream);

unter DelphiXE2 ist HttprioBeforeExecute jetzt so:

Delphi-Quellcode:

procedure HTTPRIO1BeforeExecute(const MethodName: string;SOAPRequest: TStream);

der Soaprequest ist jetzt auch ein Stream und kein Var-Parameter und widestring.
Prinzipiell ja nicht unschön, ist es wenigstens schön einheitlich und die notwendige Änderung ist auch schnell gemacht.

Großes Problem ist aber: Das Projekt wird trotzdem mit der alten Mehodenschreibweise kompiliert und gestartet.
Ich habe schon alle DCU´s gelöscht, mache Projekt erzeugen usw, nix, Delphi meckert nicht. Erst, wenn ich innerhalb der Proc etwas ändere (leerzeichen reicht schon) und dann nochmal kompiliere bekomme ich den erwarteten Fehler

Zitat:

Die <methodenname>, aufgerufen von <formularname>.<ereignisname> hat eine inkompatible Parameterliste. Soll der Aufruf entfernt werden?

was muß ich tun, damit ich solche (evtl. weiteren ?!) geänderten Ereignisparamterlisten finde oder mir das Delphi anzeigt?

Danke Frank

[himitsu]

Die Signatur der Events in der DFM werden nicht geprüft.

Erst beim Zugriff/Aufruf mit der falschen Parametersignatur, knallt es, aufgrud der falschen Typen.

Leider scheint es keine komplett automatische Lösung dafür zu geben.


Ohne daß die Units neu kompiliert werden, wird es nicht geht, denn die DFMs werden ja sonst nicht geprüft. (nur die PAS wird auf ihre Änderung geprüft, aber nicht DFMs)
Alles neu erzeugen und dann müßte man den Methodennamen nehmen, sich aus der PAS die zugehörige Parametersignatur raussuchen und mit der Signatur des Ereignisses vergleichen.
(könnte man ja mal erstellen und via OTA reinschmuggeln)


manuelle Lösung selbstgefundener Fehler:
Entferne diese Methode und lasse sie neu erstellen (mit den richtigen Parametern)
z.B. die alte Methode im OI umbenennen, kurz eine andere Methodenvariable selektieren (damit wirklich umbenannt wird), dann zurück und den Methodennamen ganz rauslöschen.
Danach doppelt draufklicken (neu erstellen), und nur noch den Code umkopieren und anpassen.
Wenn die alte Methode nun leer ist (kein Code und keine lokalen Variablen), dann löscht Delphi diese später.

[Keldorn]

ok, wenn ich so ein ereignis weiß, ist die Vorgehensweise klar.
aber wie kann ich solche Ereignisse finden, ohne das es später im Programm knallt?
Oder gibt es irgendwo eine Liste, wo einer solche geänderten Ereignisse sammelt?
Ist dir da was bekannt?

[jaenicke]

Die Fehler zeigt Delphi ja schon an. Im Zweifelsfall das Projekt neu erstellen, dann werden die Units neu kompiliert. Aber da du ja noch keine von XE2 hattest, hätte das eigentlich ohnehin passieren müssen.

[himitsu]

'ne Testmöglichkeiten hab ich grade reineditiert, aber nativ ist das in Delphi nicht vorhanden.

Bin selber mal darauf reingefallen, als ich eine Signatur änderte.

Bisher die einzige Lösung ist: Man darf keine Signaturen verändern! (wer das macht, ist fahrlässig blöd oder hinterhältig)
Nur altes Event löschen und unter einem anderem Namen mit der neuen Signazur veröffentlichen ist sicher.


Ich weiß nicht wie das in XE2 ist, aber in XE und 2010 bekommt der Compiler, selbst beim Neuerzeugen nicht immer mit, ob die Signatur paßt.

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1147439)

Ich weiß nicht wie das in XE2 ist, aber in XE und 2010 bekommt der Compiler, selbst beim Neuerzeugen nicht immer mit, ob die Signatur paßt.

Kann er nicht wissen. Die DFM Liegt als Ressource vor und die nimmt der Compiler, erzeugt Binärdarstellung und packt sie als Ressource in die Exe rein.

[Keldorn]

Zitat:

Zitat von jaenicke (Beitrag 1147438)

Die Fehler zeigt Delphi ja schon an. Im Zweifelsfall das Projekt neu erstellen, dann werden die Units neu kompiliert. Aber da du ja noch keine von XE2 hattest, hätte das eigentlich ohnehin passieren müssen.

Das habe ich ja.
weder Projekt erstellen noch alle DCU´s löschen führte zu irgendeiner Fehlermeldung. es gibt auch keine Warnungen

Ich kann das auch problemlos reproduziere.
- Delphi2007-> neues Projekt
- HttpRio auf die Form, onbefore und onafterexecute doppelklick und einen Kommentar rein, damit die Procs bleiben
- das Projekt dann in XE2 öffen komplilieren/erzeugen-> geht alles.
- erst, wenn in BeforeExecute was geändert wird, kommt es zur Fehlermeldung

Ich häng mal das Delphi2007 Projekt dran.

[Furtbichler]

Kann man kein grep über die DFM laufen lassen, da man die in Frage kommenden Signaturen bzw. Komponenten kennt? Alternativ im Code die richtige Signatur automatisch einbauen? Dann hagelt es beim Kompilieren Fehler, aber das will man ja gerade.

Könnte sogar mit RegEx gehen.

[himitsu]

In der DFM stehen keine Signaturen ... nur "Komponentennamen.Methodenname" oder maximal "Komponentennamen.Methodenname".

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1147466)

In der DFM stehen keine Signaturen ... nur "Komponentennamen.Eventname".

Der Parser müsste die DFM durchsuchen und das Eventpropertie festzustellen welche Methoden auf Problematische Events gemappt sind. Dann in die Pas schauen wie die signatur der Methode aussieht.

[himitsu]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1147468)

Der Parser müsste die DFM durchsuchen und das Eventpropertie festzustellen welche Methoden auf Problematische Events gemappt sind. Dann in die Pas schauen wie die signatur der Methode aussieht.

Und sich auch Propertynamen merken, dieses in der Komponente suchen und alles mit der Signatur des Property-Types vergleichen.
(hatte ich schonmal so ähnlich erwähnt)

[uligerhardt]

Mit der "Open/Close all forms"-Funktion von DFMCheck kannst du zumindest sicherstellen, dass du keinen Fall übersiehst. (Oder funktioniert's sogar mit "Check DFM files"?)

[Keldorn]

Zitat:

Zitat von uligerhardt (Beitrag 1147472)

Mit der "Open/Close all forms"-Funktion von DFMCheck kannst du zumindest sicherstellen, dass du keinen Fall übersiehst. (Oder funktioniert's sogar mit "Check DFM files"?)

Danke, das würde gut aussehen, geht aber leider bis XE...

[uligerhardt]

Zitat:

Zitat von Keldorn (Beitrag 1147600)

Zitat:

Zitat von uligerhardt (Beitrag 1147472)

Mit der "Open/Close all forms"-Funktion von DFMCheck kannst du zumindest sicherstellen, dass du keinen Fall übersiehst. (Oder funktioniert's sogar mit "Check DFM files"?)

Danke, das würde gut aussehen, geht aber leider bis XE...

Mist. Aber einen Strohhalm hab ich noch :-D: Geht das "Command line tool DFMCheck.exe" auch ohne unterstützte IDE?

[Keldorn]

Zitat:

Zitat von uligerhardt (Beitrag 1147668)

Mist. Aber einen Strohhalm hab ich noch :-D: Geht das "Command line tool DFMCheck.exe" auch ohne unterstützte IDE?

ja, das geht:-). aber ich bin mir da irgendwie nicht wirklich sicher, was ich mit dem Ergebnis anfangen soll.

Mich hat das aber auf ne kleine Idee gebracht, das wird aber noch etwas dauern, melde mich nochmal

Gruß Frank

[Keldorn]

Hallo,

wie ihr das mit den Signaturen meint, ist mir zwar noch nicht ganz klar :oops:, aber ich habe mir aus den verschiedenen genannten Ansätzen ein kleines Prog gebastelt. Es parst die dfm nach allen Ereignissen und sucht die dazugehörige Methode in der Pas.
Das ganze wird dann in eine eigene unit + Klasse packt. Die Ereignis-methoden werden dann per code zugewiesen, dort meckert dann auch der Compilier, daß die Paramterliste anders ist.

Konnte damit aber keine weiteren geänderten Parameterlisten finden.

Gruß Frank