DLL wegen RTTI zu einem Package umbauen

[Sir Rufo]

Und bei einer DLL wäre das anders?

[Gruber_Hans_12345]

Hmmmmm... ich hatte halt die Hoffnung

Wenn ich nun eine DLL habe die hat ja dein ihre eigene RTTI.

Sagen wir in der DLL habe ich folgendes Objekt.

Delphi-Quellcode:

type TMeinDLLObject = class
published
  Lines : TStringList;
  Text : string;
end;

in der EXE habe ich nun ein Objekt : TMeinDLLObjekt

Kann ich nun in der EXE rausfinden, das das Objekt eine RTTI hat die nicht in der EXE zu finden ist?
Und es sind dann AUTOMATISCH alle properties (in dem Fall Lines : TStringList) auch in der RTTI der DLL zu finden oder?

Bzw grob gesagt alles was in der DLL mit .Create erzeugt wird hat die RTTI in der EXE und umgekehrt oder?

[himitsu]

Rausfinden ob ein Objekt (dessen Klasse) in der RTTI der EXE ist, lässt sich leicht.
Du fragst einfach nach der RTTI zu dieser Klasse und es wird natürlich Keine gefunden.

Aber nur weil die Klassen in beiden Modulen (EXE/DLL) die gleiche/selbe Deklaration haben, müssen die Instanzen und die RTTI nicht kompatibel sein.

Beispiel:
In der EXE wird auf ein Feld/Methode nicht zugegriffen, also lässt der Compiler das weg und schon ist alles Nachfolgende verschoben.
Die Offsets zu den nachfolgenden Feldern/Variablen/VirtuellenMethoden stimmen nicht mehr überein und die Zugriffe gehen auf falsche Adressen.

Zitat:

Warum sollte das notwendig sein? (Neuerzeugung BPL, wenn Exe sich ändert)

Garnicht.

Da die EXE sich auf die BPL bezieht, braucht man nichts machen, wenn man an der EXE etwas ändert.
Ändert sich was an der BPL, dann muß man auch nicht sofort die EXE neu kompilieren, solange sich keine öffentlichen/geteilten Schnittstellen ändern.
Und wenn sich Schnittstellen ändern,dann muß man sowohl EXE, als auch BPL neu kompileren, aber mit dem Unterschied, daß bei der BPL ein Fehler geworfen wird, sobald die Schnittstellen nich zusammenpassen, was bei der DLL nicht passiert und man sich somit mit der DLL schöne Laufzeitfehler einfangen kann.