Klassen über Modulgrenzen hinaus instanziieren

[QuickAndDirty]

Der grund warum BPLs funktionieren ist weil sie im Speicherbereich der Anwendung geladen werden.
Damit das alles passt müssen BPLs und deine Anwendung z.b. Auch mit den Selben Defines kompiliert
sein. bzw. keinen Bedingt kompilierten Code enthalten. Das halte ich für extrem hinderlich.
Ich bin für interfaces, wenn möglich.

Deine RTTI werden immer noch zum Serialisieren taugen. Denn Die RTTI des DLL-Objects und die des Anwendungs-objects sind
die gleichen und sie sind auch im Zugriff. nur leider fragt der "is" operator ab ob die SELBEN sind...zwei gleiche RTTI zu
haben reicht ihm nicht aus, die Adresse an der sie zu finden sind ist entscheidend.

[xaromz]

Hallo,

Zitat von QuickAndDirty:

Der grund warum BPLs funktionieren ist weil sie im Speicherbereich der Anwendung geladen werden.

Jede DLL befindet sich im gleichen Speicherbereich wie die aufrufende Anwendung. Der wahre Grund ist vielmehr, dass die gesamte Klassenhierarchie von beiden Modulen gemeinsam verwendet wird und somit identisch ist.

Gruß
xaromz

[QuickAndDirty]

Nein, denn mehrere Anwendungen können eine DLL Benutzen. Aber es werden
wie ich hier erfahren habe gewisse teile der DLL bei benutzung (Copy on Write) kopiert.

Aber du hast natürlich recht das da eine BPL quasi Teil der Anwendung wird die Klassen
Hirarchie nicht nur die gleiche sondern auch die selbe ist, die RTTI funktionieren.

RTTI gibt es für jede Windows Anwendung oder DLL seperat.
Der Code in der System Unit legt das im übrigen
auch nahe.
Hier erkannt man eindeuteutig das ein Zeiger auf die RTTI den IS operator ausmacht.

Ich hab es nämlich ausprobiert und es Funktioniert wenn beide Module die Klassen Kennen
und kein IS operator Daten aus zwei verschiedenen Modulen vergleicht, ansonnsten geht es
nicht.
Fehler : "TStringlist ist nicht vom Typ TStringlist" (erst muste ich lachen, dann wurde es harte Arbeit)