Moin !

Wir haben in unserer Software eine Klasse. Vereinfacht schaut die so aus:

zusammenfalten · markieren

Delphi-Quellcode:

type TLVDevice = class(TPersistent)
  public
    DeviceID: TLVDeviceID; // ID des Gerätes
    Name : ShortString; // Name des Gerätes

    constructor Create(Owner: TObject);
    procedure Free; virtual;
    procedure InitValues(Kanal: TLVKanal); virtual;

    function GetMaxKanal: TLVKanal; virtual;
  published
  protected
end;

Dann haben wir Units in denen ebenfalls eine Klasse definiert wird, welche die Klasse TLVDevice erbt:

markieren

Delphi-Quellcode:

type
  TLVTEST = class(TLVDevice)
    public
      constructor Create(Owner: TObject);
      
      function GetMaxKanal: TLVKanal; override;
    private

    end;

Ist alles stark verkürzt, aber es geht eh nur ums Prinzip.

Im Programm selber wird dann irgendwann eine Instanz der Klasse erzeugt mittels:
PresentDevice := TLVTEST.Create(MainForm); Wäre es nun möglich, dass man die Klasse TLVTEST in eine DLL auslagern würde?
Was wäre dabei alles zu beachten, wenn es denn geht?

Klassen und DLLs sind nicht unbedingt Konzepte, die gut zusammenpassen. Da DLL und Anwendung unterschiedliche Speichermanager benutzen, ist ein Objekt, welches in der DLL erzeugt wurde nicht gleich dem Objekt, welches in der Anwenung dann benutzt wird oder benutzt werden soll. Eine Ausnahme stellt das COM/ActiveX Konzept dar. allerdings wird hie rmit Interfaces gearbeitet.

Auch hier stellt sich mir erstmal wieder die Frage: Warum? Warum eine DLL?

Moin !

Zitat:

Warum eine DLL?

Es sind im Laufe der Zeit einige Units zusammen gekommen. Und die würden wir in Zukunft gerne aus dem Programm auslagern.

Wenn du das machst musst du auf jedenfall gemeinsamme Runtimepackages (BPL's) verwenden.
Ansonsten gibt es immer Probleme. Hatten erst den Fall das eine solche Einbindung (Objekt aus DLL ohne Runtimepackages) an einer komplett andere Stelle gekracht hat. Fehlersuche ist natürlich damit sehr schwer.

Zitat von moelski:

Es sind im Laufe der Zeit einige Units zusammen gekommen. Und die würden wir in Zukunft gerne aus dem Programm auslagern.

Und warum? Du handelst dir damit mehr Probleme und Arbeit ein, als dass es dir Vorteile bringt. Ginge es um einfache Funktionen könnte ich das nioch verstehen, aber gerade Klassen in DLLs verkomplizieren das ganze doch erheblich.

Moin !

Ok, dann währe wohl folgendes sinnvoller ....

In der Anwendung eine abgeleitete Klasse von TLVDevice erstellen. In den Methoden werden dann aber einzelne Funktionen / Proceduren einer DLL verwendet.
Also dann in etwa so:

markieren

Delphi-Quellcode:

function TLVTEST.GetMaxKanal: Integer;
begin
  GetMaxKanal := DLL_GetMaxKanal;
end;

Damit hätten wir eine allgemein gültige Geräteklasse und je nach Gerät werden da Methoden aus einer Geräte DLL gemappt.

das würde noch gehn

markieren

Delphi-Quellcode:

function TLVTEST.GetMaxKanal: Integer;
begin
  GetMaxKanal := DLL_GetMaxKanal;
end;

oder nimm lieber gleich Interfaces


ich hab zwar auch schon eine Klasse in EXE/DLL verteilt, aber da stecken Monate an Arbeit drin und selbt jetzt weiß ich nichtmal, ob wirklich alles geht.
> in der einen DLL-Version von himXML verbaut

aber dafür waren Umleitungen des Speichermanagers (ist recht leicht und unter Anderem als ShareMem bekannt) und vorallem ein Verbiegen der RTTI nötig (welches nicht grad tivial ist)

das sind noch die harmlosesten Probleme, welche sich mir in diesem Zusammenhang stellten
http://www.delphipraxis.net/internal...791&highlight=
http://www.delphipraxis.net/internal...601&highlight=
und welche ich grad mal schnell fand

Zitat von moelski:

Damit hätten wir eine allgemein gültige Geräteklasse und je nach Gerät werden da Methoden aus einer Geräte DLL gemappt.

Und dann ergänzt du in der Exe ein Methode an der falschen stelle und vergisst die DLL neu zu kompilieren und es kracht beim Zugriff. Willst du wirklich eine DLL-Hölle in dein Programm einbauen?

Moin !

Zitat:

Und dann ergänzt du in der Exe ein Methode an der falschen stelle

Also das was in den Units passiert ist besteht jetzt in der Form schon eine geraume Zeit. Das sich da was grundlegendes ändert ist eher unwahrscheinlich.

In den Units geht es im Grunde nur um das Zerlegen eines Strings in seine Bestandteile und deren Auswertung.
Wir haben dafür eine Struktur die sich jetzt wie gesagt schon lange bewährt hat.

Zitat:

Willst du wirklich eine DLL-Hölle in dein Programm einbauen

Mal abwarten. Damit das alles funktioniert müssen eh erst noch die Units vereinfacht werden. Dort stehen direkte Zugriffe auf Komponenten drin. Erst wenn das alles sauber (entfernt) ist werden wir eine Umstellung testen.

Zitat von moelski:

Zitat:

Willst du wirklich eine DLL-Hölle in dein Programm einbauen

Mal abwarten. Damit das alles funktioniert müssen eh erst noch die Units vereinfacht werden. Dort stehen direkte Zugriffe auf Komponenten drin. Erst wenn das alles sauber (entfernt) ist werden wir eine Umstellung testen.

Um in Delphi vernünftig zu modularisieren kommt man, glaube ich, an der Com - Technologie nicht vorbei.
Ein Com Object ist in sich gekapselt und braucht keine Laufzeit - Bpl.
Hier ist sogar das möglich, was in Delphi selbst absolut unmöglich ist , z.B. aus D2009 ein
in D7 entwickeltes Modul verwenden.
Einen weiteren Vorzeil hat die Com- Technologie. Ich bekomme Net und Delphi in beiden Richtungen zueinander.
In D2009 ist das Handling etwas verbessert worden.
Von DLL und erst recht BPL würde ich bei der Modularisierung die Pfinger lassen. Wir sind damit gehörig auf die Nase
gefallen, da jede BPL gegen die gleiche Compilerversion compiliert sein muss.
(Z.B. Drittkomponenten ohne Versionsnummer im BPL-Namen )

Gruß
Peter