DLL wegen RTTI zu einem Package umbauen

[jbg]

Zitat von QuickAndDirty:

Du scherzt . Das wäre viel zu einfach. *Hoffnung*

Nein, ich scherze nicht. So mache ich das auch bei DelphiSpeedUp und DDevExtensions (beides DLLs, die gegen vcl.bpl und rtl.bpl gelinkt sind)

[Gruber_Hans_12345]

Zitat von jbg:

Zitat von QuickAndDirty:

Du scherzt . Das wäre viel zu einfach. *Hoffnung*

Nein, ich scherze nicht. So mache ich das auch bei DelphiSpeedUp und DDevExtensions (beides DLLs, die gegen vcl.bpl und rtl.bpl gelinkt sind)

Hallo, bin gerade daruf gestossen

schaffe ich es auch damit (wenn ich EXE und DLL mit rtl und vcl packages compiliere), das ich in einer "normalen" DLL eine Objekt samt RTTI erzeuge, dieses Objekt dann in ner Funktion der EXE gebe und die EXE kann dann per RTTI auf die properties zugreifen?

Oder hab ich dieses Aussage falsch verstanden?

[Sir Rufo]

Wenn alles mit Runtime-Packages und alles mit dem absolut gleichen Kompiler erzeugt wurde, dann ja.

Dann kannst du aber auch gleich ein Package anstatt einer DLL verwenden.

[mkinzler]

Man sollte nie Objekte im Interface einer Dll verwenden. Für diesen Zweck wurden die Bpls entwickelt (technisch handelt es sich ja um Dlls, mit erweitertem Interface)

[Gruber_Hans_12345]

Ich habe bei den BPL's Angst, das wenn sich viel in der EXE tut ich jedesmal die BPL's erneut erzeugen muss

Der Kompiler würde eh immer gleich sein/bleiben ...

Nur muss ich eben von 2-3 Stellen dynamisch diese Objekte erzeugen und dynamisch auf RTTI Properties zugreifen können

[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.

[mkinzler]

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

[Gruber_Hans_12345]

Zitat von mkinzler:

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

Weil ich es so rausgelesen haben prinzipielle....

Zitat:

When you want to update your DLL (change some function's implementation), you simply compile it, export some new routines and ship the new version. All the applications using this DLL will still work (unless, of course, you've removed existing exported routines). On the other hand, when updating a package, you cannot ship a new version of that package without also updating the executable