automation DLL - Verständnisfrage

[moelski]

Moin !

Es gibt ja die Möglichkeit einer bestehenden Applikation ein automation object hinzuzufügen.
Soweit so klar ... Der Automation Server ist in dem Fall in der EXE - out-of-process automation server.

Nun besteht aber auch die Möglichkeit eine DLL (automation in-process servers) zu erzeugen.
Da verstehe ich aber gerade die Zusammenhänge noch nicht ganz.

Ich habe eine Anwendung. Wird dann die ganze Anwendung (inkl. Formular) in die DLL transferiert?
Oder ist es eher so das zu meiner bestehenden EXE eine automation in-process DLL erstellt wird. Und die DLL nutzt dann wiederum (z.B.) das Formular der EXE?
Es gibt zu dem ganzen Thema ja hier eine schön Seite: http://www.gekko-software.nl/Delphi/

Aber das mit dem automation in-process server will sich mir gerade noch nicht ganz erschließen.
Könnte da jemand mal ein paar Worte zu verlieren?

[Elvis]

Zitat:

Zitat von moelski

Aber das mit dem automation in-process server will sich mir gerade noch nicht ganz erschließen.
Könnte da jemand mal ein paar Worte zu verlieren?

Ist gar nicht so schwer.
Du bewegst deinen Code aus der Echse in die Library.
Deine Echse ruft dann also die Library genauso auf, wie es eine andere Echse tun würde, die damit etwas anstellen will.

Höchstwahrscheinlich wandert praktisch alles aus deiner aktuellen Echse in die Automations-Library, und die Echse wird wohl nur eine Instanz dein XyzApplication erzeugen, es modal sichtbar machen und dadurch warten bis XyzApplication beendet wird.
Oder wie auch immer du es lösen willst. Vllt willst du, dass deine Echse besser damit interagieren als es andere Programme, etc..

[moelski]

Moin !

Zitat:

Du bewegst deinen Code aus der Echse in die Library.
Deine Echse ruft dann also die Library genauso auf, wie es eine andere Echse tun würde, die damit etwas anstellen will.

Nuja, so einfach ist die Welt nicht :)

Ich beschreibe mal unser Szenario ...
Wir haben da eine Anwendung die - vereinfacht gesagt - Kurven plottet. Sinn der Übung ist nun, das man von extern die Anwendung mit Daten füttern kann um eben Kurven zu zeichnen.
Also sowas in dem Stil hier (just a sample):

Delphi-Quellcode:

LV.CreateChart
LV.CreateLine("Heizung Wärmespeicher Temp")
LV.AddChart(1, "33.5;33.7;33.5;33.4;")

Wenn ich nun all meinen Code in die DLL frachte, dann würde sich ja unsere Anwendung "auflösung" - das geht aber nicht. Die brauchen wir ja nachwievor.

Ich hatte eher gehofft, das ich das COM Objekt in eine in-process automation DLL auslagere. Dann ist mir aber noch nicht klar wie das COM Objekt mit der Anwendung spricht. :gruebel:

[Bernhard Geyer]

Wenn du die Exe immer noch haben willst dann las es so wie es ist und nimm den Automation Server.
Die DLL-Lösung ist wenn du das als Komponenten allgemein zur verfügung stellen willst ohne eigenständige Exe.

[moelski]

Moin Bernhard,

das habe ich mir ja schon fast gedacht ...

Aber eine Frage hätte ich noch. Es gibt eine Software DPlot : http://www.dplot.com/index.htm
Dort gibt es eine DLL welche in eigene Anwendungen eingebunden werden kann. Die DLL wiederum steuert dann DPlot.
Siehe dazu auch hier: http://www.dplot.com/lib/index.htm

Wie haben die das wohl gelöst? Hat da dann die EXE ein COM Objekt und die DLL greift auf das COM Objekt zu?
Wobei dann könnten sie auch direkt das COM Objekt beschreiben / freigeben.

Any ideas? :gruebel:

[Bernhard Geyer]

Bei VS (ATL?) besteht die möglichkeit Marshall-DLL's erstellen zu lassen um komplexere Datenstrukturen über COM zu übertragen. Dieser Weg steht den Delphi-Entwicklern nicht offen. Delphi-Anwendungen sind auf die Möglichkeiten des standard COM-Marsharlers beschränkt.

[moelski]

Ok Danke für die Erklärung.

Was mich nur wundert ist die Tatsache das in der DLL auch noch Funktionen stecken, die auf die Anwendung zugreifen.
Können die dann ebenfalls dort untergebracht werden?

Und noch ne Frage zum Verständnis. Im Grunde ist aber immer noch so, dass ein COM Objekt existiert, welches von der DLL genutzt wird. Und über das COM Objekt erfolgen auch die Zugriffe auf die Anwendung, oder!?