| Autor |
Beitrag |
Beiri22
Beiträge: 42
|
Verfasst: Fr 14.04.06 01:58
Genau das ist meine Frage: Kann man eine Klasse in eine Dll auslagern(evtl. ActiveX)? Wenn ja, wie macht man das, und wie bindet man sie wieder in ein Programm ein.
|
|
Spaceguide
Beiträge: 552
(D3/D7/D8) Prof.
|
Verfasst: Fr 14.04.06 02:07
Eine DLL kann AFAIK keine Klassen nur Funktionen etc. exportieren ...
Da gebe ich doch mal schnell "Klasse DLL" in die schlecht sichtbare Suchfkt. hier ein ...
www.delphi-forum.de/...highlight=klasse+dll
|
|
BenBE
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: Fr 14.04.06 09:54
Nimm anstatt einer DLL lieber ein Package... Das ist MZ\PE-Technisch das gleiche, jedoch wird bei deiner VMT und DMI-Table automatisch eine Korrektur vorgenommen, d.h. es funktioniert wenigstens 
Achso, zur Nutzung:
Du schreibst einfach dein Hauptprogramm und bindest dabei die Unit, in der die Klasse deklariert ist, ein. Unter Projekt\Optionen schaltest Du "Mit Laufzeit-Packages compilieren" ein und ergänzt dort den Namen deiner zusätzlichen Packagedatei. Diese zusätzliche Package-Datei muss alle Units enthalten, die nicht in der VCL\RTL enthalten sind (sprich zu deinem Programm gehören) und Source enthalten, der von dieser Klasse referenziert wird.
Das Package-Konzept von Delphi ist kompliziert gemacht, relativ mächtig, aber blöd umgesetzt... Oft hat man damit mehr Aufwand als nötig, weshalb es sich nur in großen Projekten wirklich lohnt. Für Plugin-Schnittstellen, solltest Du dich einmal hier im Forum umschauen, da gab es IIRC mal ein Beispiel, wie das mit Packages zur Laufzeit nachladen für Plugins ging... _________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
MrSaint
Beiträge: 1033
Erhaltene Danke: 1
WinXP Pro SP2
Delphi 6 Prof.
|
Verfasst: Fr 14.04.06 10:11
Es gäbe auch noch das Component Object Model (COM). Damit geht das auch. Die EXE kennt dann sozusagen die Header der Klasse in der DLL (in dem Fall läuft das dann aber nicht mit Klassen sondern mit interfaces, welche eben in der DLL realisiert werden). Ist aber etwas aufwändiger. Um da rein zu kommen, habe ich das Buch "COM/COM+/DCOM mit Delphi" von Andreas Kosch benutzt. Online fällt mir gerade keine gute Ressource ein...
MrSaint
_________________ "people knew how to write small, efficient programs [...], a skill that has subsequently been lost"
Andrew S. Tanenbaum - Modern Operating Systems
|
|
MrSaint
Beiträge: 1033
Erhaltene Danke: 1
WinXP Pro SP2
Delphi 6 Prof.
|
Verfasst: Fr 14.04.06 10:34
Es geht noch viel einfacher, sozusagen mit OOP-Bordmitteln  :
Du hast eine Klasse die du exportieren willst (z.B. ein PlugIn). Dann schreib erst mal eine neue Klasse in der die gleichen public Methoden etc vorkommen, nur dass alles abstrakt ist, also so:
  Delphi-Quelltext
1:
2:
3:
4:
| TPlugInAbstract = class
public
procedure LegLos; abstract;
end; |
Diese Klasse packst du in eine eigene Unit, welche sowohl die EXE, als auch die DLL kennt. Dann nimmst du deine Klasse von vorher her (die du ursprünglich exportieren wolltest) und leitest sie von der neuen, abstrakten Klasse ab. Diese Klasse packst du in die DLL.
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
| TPlugin = class (TPlugInAbstract)
public
procedure LegLos;
end;
...
Procedure TPlugin.LegLos;
begin
...
end; |
Nun schreibst du in die DLL noch eine Funktion wie diese:
Delphi-Quelltext
1:
2:
3:
4:
| function CreatePlugInObject: TPlugInAbstract;
begin
Result := TPlugInAbstract(TPlugin).Create;
end; |
Und diese Funktion expoertierst du in der DLL.
Nun machst du es in deiner EXE einfach so:
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
| function CreatePluginObject: TPlugInAbstract; external 'DLLNAME.dll';
var
meinePlugInInstanz: TPluginAbstract;
begin
meinePlugInInstanz := CreatePlugInObject;
end; |
Und schon wäre es fertig
MrSaint _________________ "people knew how to write small, efficient programs [...], a skill that has subsequently been lost"
Andrew S. Tanenbaum - Modern Operating Systems
|
|
BenBE
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: Fr 14.04.06 10:54
@MrSaint: Diese Methode sollte man meiden, da es sehr witzige Effekte in Bezug auf den Is-\As-Operator provoziert So Fehler wie "TFont kann nicht zu TFont zugewiesen werden." ... Wie man sie eben kennt ^^ _________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
MrSaint
Beiträge: 1033
Erhaltene Danke: 1
WinXP Pro SP2
Delphi 6 Prof.
|
Verfasst: Fr 14.04.06 11:06
@BenBE: Was hat das damit zu tun? Diese von dir angesprochene Meldung kommt doch nur, wenn ich Assign aufrufe und für die entsprechende Klasse das Assign halt nicht implementiert ist, oder? Und wenn er festsetzt, dass wirklich jede abstrakte Methode auch implementiert werden muss, dann sollte das wunderbar funktionieren. Wenn er natürlich dann ein PlugIn schreibt, dass eine Methode nicht implementiert, kann es zu Problemen ("Abstrakter Fehler") kommen... Aber das ist dann ein Problem des PlugIn-Verfassers und nicht des Host-EXE-Verfassers...
MrSaint
_________________ "people knew how to write small, efficient programs [...], a skill that has subsequently been lost"
Andrew S. Tanenbaum - Modern Operating Systems
|
|
BenBE
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: Fr 14.04.06 19:47
Nope Das ist sehr wohl ein Problem der Host-Anwendung: Jede DLL in Delphi enthält jegliche Klassen aus allen Units, die eingebunden wurden (in die DLL) Somit kommt es zu Code-Dopplungen und u.a auch zu der Situation, dass man in der DLL TObject.Create aufruft und meint, dieses ist mit dem TObject der Hauptanwendung kompatibel - da Delphi aber Klassen-Kompatibilität anhand der VMT-Adressen vergleicht (die ja bei DLL und EXE verschieden sind), bringt Delphi einen Fehler ...
Daher sollte man das Klassen-Sharing zwischen Host-Anwendung und jeglichen DLLs IMMER vermeiden, da es potenziell zu diesem Problem führt. Daher schreib ich meine Plugins (sofern nötig) immer über Packages, weil dann TObject wirklich immer eindeutig rtl70.$xp$14System@TObject ist. _________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
MrSaint
Beiträge: 1033
Erhaltene Danke: 1
WinXP Pro SP2
Delphi 6 Prof.
|
Verfasst: Fr 14.04.06 20:22
_________________ "people knew how to write small, efficient programs [...], a skill that has subsequently been lost"
Andrew S. Tanenbaum - Modern Operating Systems
|
|
Beiri22 
Beiträge: 42
|
Verfasst: Fr 14.04.06 22:10
Nochmal eine Frage zu deiner Methode MrSaint: Wie kann man die Klasse im Programm wieder freigeben?
|
|
MrSaint
Beiträge: 1033
Erhaltene Danke: 1
WinXP Pro SP2
Delphi 6 Prof.
|
Verfasst: Fr 14.04.06 22:32
Hmm.. Also erst mal hatte BenBE ja drauf hingewiesen, dass die Methode nicht wirklich gut ist... Aber freigeben tut man ein Objekt normalerweise mit .Free oder FreeAndNil aus der SysUtils-Unit _________________ "people knew how to write small, efficient programs [...], a skill that has subsequently been lost"
Andrew S. Tanenbaum - Modern Operating Systems
|
|
Beiri22
Beiträge: 42
|
Verfasst: Fr 14.04.06 22:46
Das hab ich ja probiert, aber nachdem ich es im Programm freigegeben habe, ließ es sich immernoch
verwenden. Auch als ich eine Procedure in der Dll hatte und diese mit dem Objekt aufgerufen habe, so
dass die es in der dll freigibt, lief es noch weiter.
|
|
MrSaint
Beiträge: 1033
Erhaltene Danke: 1
WinXP Pro SP2
Delphi 6 Prof.
|
Verfasst: Fr 14.04.06 22:51
Also nachdem du Free aufgerufen hast ist der Speicher freigegeben. Es kann evtl. nur sein, dass der Speicher noch nicht von einem anderen Objekt überschrieben wurde.
Wenn du nur .Free aufgerufen hast und nicht FreeAndNil, zeigt deine Variable immer noch an die alte Speicherstelle und wenn die noch nicht überschrieben wurde kannst du auf das Objekt noch zugreifen. Sollte man aber eigentlich nicht machen
MrSaint _________________ "people knew how to write small, efficient programs [...], a skill that has subsequently been lost"
Andrew S. Tanenbaum - Modern Operating Systems
|
|
Beiri22
Beiträge: 42
|
Verfasst: Fr 14.04.06 23:02
Ich schau mal nach und probiers
|
|
Beiri22
Beiträge: 42
|
Verfasst: Sa 22.04.06 16:43
Titel: An MrSaint und alle die es wissen
Hallo, ich habe mal noch eine Frage. Kannst du mir noch was über dieses COM erzählen,
klingt interessant. Wäre sehr nett.
|
|
MrSaint
Beiträge: 1033
Erhaltene Danke: 1
WinXP Pro SP2
Delphi 6 Prof.
|
Verfasst: Sa 22.04.06 17:07
Die ganze Sache ist ziemlich umfangreich und mächtig. Damit kann man z.B. auch die (MS) Office-Anwendungen "fernsteuern".. Ich hab jetzt mal kurz gesucht und hab das hier gefunden: delphi.about.com/od/comoleactivex/ Weiß aber nicht in wie weit das taugt... Ansonsten eben das Buch von Andreas Kosch, wie oben schon erwähnt: www.amazon.de/exec/o.../303-4585554-3121854 Wenn du Glück hast findest du auch eins davon bei eBay.
Leider kann man davon nicht nen Crashkurs in ein paar Zeilen schreiben...
MrSaint _________________ "people knew how to write small, efficient programs [...], a skill that has subsequently been lost"
Andrew S. Tanenbaum - Modern Operating Systems
|
|
Beiri22
Beiträge: 42
|
Verfasst: So 23.04.06 12:32
danke erstmal, ich schua mir die seite mal an.
|
|
|
