[Techno-Demo]Von Dll auf VCL-Objekte der Anwendung zugreifen

[chaosben]

Oft gibt es ja Diskussionen darüber, warum man von einer DLL nicht auf die Komponenten des aufrufenden Programms zugreifen kann. Das Ganze wurde hier auch schon erklärt.

Wir haben nun eine Art "Framework" geschrieben um Objekte aus der Hauptanwendung in die DLL (und umgedreht) zu exportieren. Innerhalb der DLL kann man fast alle windigen und nicht-windigen Sachen mit den importierten Objekten machen.
Aber es gibt auch die folgende Einschränkung: Wenn eine Eigenschaft/ein Objekt selbstständig Speicher allociert, kann es sein, das beim Beenden der Anwendung Zugrifssverletzungen entstehen. Die betrifft zum Beispiel die Font-Eigenschaft. Das bedeutet, das man diese Eigenschaften einfach ignorieren soll.
Wichtig ist auch, dass innerhalb der DLL allocierte Strings (auch durch einfache Zuweisung) am Ende (finalization) freigegeben/auf '' gesetzt werden. Aber seht euch einfach die Sourcen der Demo an und probiert ein wenig herum. (Und in der Demo einfach mal auf die Hints schauen. )

Liste der möglichen Fallstricke:

• DLL und Programm müssen mit exakt den selben Sourcen und dem gleichen Compiler erstellt werden
• to be continued ...

[chaosben]

Ok, ich sehe immer noch nicht ein, das ich andere Leuts Projekte zerlegen (was für mich einen destruktiven Charakter hat) darf und dann noch als freundlicher Member gelte, aber ich werde das akzeptieren.

Das DLL und Programm vom gleichen Compiler stammen müssen, war mir so sonneklar, das ich vergessen habe, es dazu zu schreiben. Sorry, ich trage es sofort nach.

Zitat von Lukie:

Führt eure persöbnliche Diskussion bitte per pN weiter und diskutiert im Forum den Code sachlich weiter.

Ja, Sir.

[Luckie]

Zerlegen bedeutet kritisieren und daran ist nichts unfreundliches. Unfreundlich wäre es, die Fehler nicht zu erwähnen und zukünftige Forenmitghleider ins offene Messer laufen zu lassen. So, das wars es jetzt aber von meiner Seite.

[hanspeter]

Zitat:

Hmm.. ich sehe es irgendwie immer noch nicht, warum hier DLLspraktischer als Packages sein könnten. Kannst du das mal etwas genauer erklären?

Dafür gibt es schon genügend Gründe. BPL ist die Potentizierung der Dll Hölle.
Delphi prüft Abhängigkeiten bei der Compilierung automatisch.
Hat man dann nicht die Übersicht, welche BPL mit neu compiliert wird, dann kann es passieren, dass
beim Anwender das ganze Programm nicht läuft.
BPL funktionieert nur wenn alle Programmteile mit Delphi compiliert werden. Also genau die gleiche
Forderung wie in dem vorgestellten Framework.
Wir stellen unsere größte Application jetzt z.B. auf Dll um.
Framwork in Delphi, Geschäftslogik in Delphi aber in einer Dll.
Das hat den Hintergrund, das bei der unsicheren Zukunft von Delphi ein schrittweiser Umstieg auf ein
anderes Framwork einfacher wird.
Wir planen den Übergang zu C# und Chrome unter VS.
Allerdings übergeben wir keine Objekte sondern haben eine Aufruf procedure in der DLL.

Gruß Peter

[Elvis]

Zitat von hanspeter:

Allerdings übergeben wir keine Objekte sondern haben eine Aufruf procedure in der DLL.

Und schon sind wir wieder bei sprachunabhängigen Calls angekommen, für die DLLs nunmalda sind.

Edit: Verquottelt...