Formular in dll auslagern

[Cogito]

Hallo zusammen,

ich möchte gerne ein Formular in eine dll auslagern und dieses dann innerhalb des Hauptprogramms modal öffnen können. Dabei sollte möglichst auf das Vorhandensein dieser dll geachtet werden, denn es soll so eine Art Zusatz (Addon Feature) zum Hauptprogramm sein, dass ich einfach hinzukopieren kann. Falls die dll nicht da ist sollte der Aufruf aber nicht das ganze Programm zum Einsturz bringen. Ich weiss dass darüber schon einiges hier im Forum geschrieben wurde, was ich aber bräuchte wäre eine Art Programmgerüst (dll gerüst + Hauptprogramm mit den entsprechenden Aufrufen). Es sollte nur eine dll mit Dummy-Formular + Hauptprogramm das dieses Formular dann startet sein, keinerlei Funktionalität. Hat jemand sowas in seinem Fundus oder kann es kurz zusammenklicken?

[lbccaleb]

Lade die Dll Dynamisch, wie in dem Assarbad Tutorial hier:

Delphi DLL´s

und füge das dem laden der dll einfach ein Abfrage zu, welche kontrolliert ob die Dll vorhanden ist:

Delphi-Quellcode:

//bsp aus der verlinkten pdf....
Procedure GetEntryPoints;
var
  lib:THandle;
begin
  if not FileExists('deinedll') then Exit;  //<------
  lib := LoadLibrary(@szNameDLL[1]);
  case lib = 0 of
    TRUE:
      begin
        @OneFunction_CDECL := @whatifnoentry;
//....

wenn du dann dein procedure aufrufst, checkst du vorher noch mit "assigned" ob sie auch zugewiesen ist, und alles ist gut :)
freimachen nicht vergesen....

[himitsu]

Abgesehn davon, daß FileExsist nicht die selben Suchpfaden, wie LoadLibrary benutzt (eigentlich nutzt FileExists garkeine Suchpfade):

Delphi-Quellcode:

var
  Lib: THandle;
  Proc: .... // Prozedur-/Funktionszeiger

function GetEntryPoints: Boolean;
GetProcAddress 
begin
  lib := LoadLibrary(@szNameDLL[1]);
  if Assigned(lib) then
  begin
    Proc := GetProcAddress(Lib, 'Prozedurname');
  end
  else
    Proc := nil;
  Result := Assigned(Proc);
end;

Und dann solltest du dir noch einige der Threads ansehen, wo jemand versuchte Teile der VCL über externe Quellen zu laden.

Es kommt darauf an, was du genau willst und wie weit die beiden VCLs interagieren sollen.
> Vieles geht einfach nicht (so leicht), da die DLL grudsätzlich erstmal ihren eigenen Speichermanager und ihre eigene RTTI besitzt, welche nicht mit denen der EXE zusammenarbeiten, bzw. sich einfach nicht verstehen.

[hanspeter]

Zitat:

Zitat von himitsu

> Vieles geht einfach nicht (so leicht), da die DLL grudsätzlich erstmal ihren eigenen Speichermanager und ihre eigene RTTI besitzt, welche nicht mit denen der EXE zusammenarbeiten, bzw. sich einfach nicht verstehen.

Lass die Finger von Delphi und dll. Du handelst dir nur Frust ein.
Das Modulkonzept von Delphi ist schon lange nicht mehr zeitgemäß.
Entweder als BPL, das gibt dann noch mehr Probleme.
Bei beiden Verfahren bist Du auf Laufzeit-BPL angewiesen und die müssen gegen die gleiche Compilerversion und Quelltextstand compiliert sein.

Entweder man verwendet ein externes(teures) Pluginsystem.
Ich habe da mit Hydra gute Erfahrungenm gemacht.
Oder man setzt auf der Com-Technologie (ActiveX) auf.
Ein Outofprocess-Server ist völlig unabhängig von der jeweiligen Delphiversion.

Gruß
Peter

[hoika]

Hallo,

naja, soo schlimm ist es auch wieder nicht.

Speicher-Manager: Mit FastMM4 gibt es kaum Probleme.

Die Frage ist, was wird übergeben.

Strings
-> neeehhh (trotz FastMM4).


Interaktion mit dem Hauptprogramm
-> nicht direkt, kann aber über Messages gelöst werden.


Heiko

[himitsu]

Wenn man bestimmte Dinge beachtet, dann kann man schon auch Formulare in eine DLL exportieren.
Aber über BPLs läßt sich da leichter arbeiten, auch wenn es dort eine Beschränkungen gibt (wie es schon genannt wurde).

Einfacher ist es da aber, wenn man die VCL nur im Hauptprojekt verwaltet und in der DLL nur die Informationen ablegt, wie die nötige Form aussehen soll.
Ansonsten sollte man halt beide VCLs/RTTIs getrennt halten. Für den Speichermanager gibt es da das Thema Shared-Memory als Hilfmittel.

Delphi-Quellcode:

Strings
-> neeehhh (trotz FastMM4).

Entweder WideString, denn dieser ist ein Sonderfall ('ne Kapselung des "OLE-String" der OLE32Auth.dll)

ansonsten verträgt sich alles bis Delphi 2007 oder alles ab Delph 2009 (in 2009 wurde eine echt bescheuerte Neuerung eingebaut, weswegen diese Typen nun nicht mehr kompatibel zu den Alten sind)

[hathor]

Ein Formular (TForm) aus einer DLL aufrufen/anzeigen:
http://warnecke.xxlspeed.de/code-ora..._anzeigen.html

[uligerhardt]

Zitat:

Zitat von lbccaleb

Delphi-Quellcode:

//bsp aus der verlinkten pdf....
Procedure GetEntryPoints;
var
  lib:THandle;
begin
  if not FileExists('deinedll') then Exit;  //<------
  lib := LoadLibrary(@szNameDLL[1]);
  case lib = 0 of
    TRUE:
      begin
        @OneFunction_CDECL := @whatifnoentry;
//....

case BoolescherAusdruck of??? case ist das neue if, oder wie? :mrgreen:

[Cogito]

Na gut, also besser keine dll. Ist von der Performance vielleicht sogar noch besser wenns gleich im Programm steckt.
Wäre es denn wenigstens möglich, diesen Part des Programms mit seinen Formularen aus Entwickler-Sicht in ein eigenes Projekt auszulagern und dann aus dem Hauptprogramm das Formular modal aufzurufen? Falls ja wie geht das (bitte step by step Anleitung oder kleines Sample)?

[lbccaleb]

Zitat:

Zitat von uligerhardt

case BoolescherAusdruck of??? case ist das neue if, oder wie? :mrgreen:

"If" ist im Compiler immer nur "case" ;)