Es ist nicht unmöglich, aber es gibt viele Fallstricke, besonders, wenn es sich um eine visuelle Komponente handelt. Viel hängt auch davon ab, wie das Hostprogramm die Komponente verwendet. Falls das Hostprogramm die Klasse der Komponente kennen muss, um mit ihr zu arbeiten (d.h. Du kannst sie nicht als Instanz der
VCL-Basisklasse behandeln, von der sie abgeleitet wurde) hast Du ja zwei unterschiedlich kompilierte Versionen des Sourcecodes, die im Host-Programm eingebundene und die aus der
DLL. Ein Aufruf einer statischen Methode im Hostprogramm würde den Code im Hostprogramm aufrufen, eine virtuelle Method dagegen den in der
DLL. Und bei größeren Sprüngen in den verwendeten Delphi-Versionen kann das in-memory layout der von der
DLL erzeugten Instanz sogar von dem abweichen, was das Hostprogramm erwartet.
Das Ganze ist ein Minenfeld, in das ich mich nicht vorwagen würde
.
Was so halbwegs funktioniert ist folgendes: Du definierst einen Interface-Type für die Interaktion mit der Komponente in einer separaten
Unit, die sowohl von Hostprogramm als auch von der
DLL verwendet wird. Die
DLL exportiert eine Funktion, die eine Instanz der Komponente anlegt und das Interface dafür zurückgibt. Falls es eine visuelle Komponente ist übergibst Du der Funktion das Windows-
Handle des Host-Controls und verwendest den CreateParented-Constructor um das Control (muss ein TWinControl sein!) zu erzeugen. Alle Interaktion des Hosts mit dem Control erfolgt über das Interface, oder durch Senden von Messages. Dadurch ist sichergestellt, dass es keine Konflikte durch unterschiedlichen Code in
VCL oder
RTL gibt. Trotzdem sollte man bei den Parametern in den Methoden des Interfaces auf compiler-managed types wie String oder array of <type> verzichten, den sonst brauchen beide Module auch noch einen gemeinsamen Memory manager, was auch nicht problemfrei machbar ist, wenn beide mit unterschiedlichen Delphi-Versionen kompiliert wurden.