Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   PlugIn laden / Verständnis (https://www.delphipraxis.net/80921-plugin-laden-verstaendnis.html)

TheMiller 17. Nov 2006 14:39


PlugIn laden / Verständnis
 
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo,

hab ja gesagt, dass ich PlugIns lade. Jetzt hier nochmal der Quelltext, der mein PlugIn läd. Ist das so korrekt von der vorgehensweise? Der Code ist momentan (zum Lernen) aus Sakura's PlugIn-Tut. Habe ein Schema drangehängt und nochmal eine Frage, ob er an der Stelle, die markiert ist, wirklich das macht, was ich aufgeschrieben habe. Hätte dazu gerne nochmal eine genauere Erklärung.

Delphi-Quellcode:
procedure TForm1.LoadPlugin(DLLName: string);
var
  TempHandle: Cardinal;
  ProcAddr: Pointer;
  LoadPlugInProc: TLoadPlugIn;
  TempPlugIn: TPlugIn;
begin
  // load library
  TempHandle := LoadLibrary(PChar(DLLName));
  if (TempHandle <> INVALID_HANDLE_VALUE) and (TempHandle <> 0) then
  begin
    // library loaded, load register function
    ProcAddr := GetProcAddress(TempHandle, 'LoadPlugIn');
    if ProcAddr = nil then
    begin
      // register function not exported
      FreeLibrary(TempHandle);
      Exit;
    end;
    LoadPlugInProc := TLoadPlugIn(ProcAddr); //<------DIESE STELLE
    try
      TempPlugIn := nil;
      LoadPlugInProc(Application.Handle, TempPlugIn);
    except
      // register function invalid
      FreeLibrary(TempHandle);
      Exit;
    end;
    // add to array of plug-ins
    SetLength(FPlugIns, Succ(Length(FPlugIns)));
    FPlugIns[High(FPlugIns)].Handle := TempHandle;
    // test for plug-in object
    if TempPlugIn <> nil then
    begin
      // plug-in object exists, add to menü
      FPlugIns[High(FPlugIns)].PlugIn := TempPlugIn;
      FPlugIns[High(FPlugIns)].MenuItem := TMenuItem.Create(Self);
      FPlugIns[High(FPlugIns)].MenuItem.Caption := TempPlugIn.GetPlugInName;
      PlugIns1.Add(FPlugIns[High(FPlugIns)].MenuItem);
      FPlugIns[High(FPlugIns)].MenuItem.OnClick:=ExecutePlugIn;

    end else begin
      // plug-in does not exist
      FPlugIns[High(FPlugIns)].PlugIn := nil;
      FPlugIns[High(FPlugIns)].MenuItem := nil;
    end;
  end else
  begin
    FreeLibrary(TempHandle);
    Exit;
  end;
end;
Danke

Brainshock 17. Nov 2006 15:17

Re: PlugIn laden / Verständnis
 
Hallo,

gibt es zu dem Thread einen vorhergehenden? Alles ein bisschen abgehackt hier.


DIESE STELLE ------> castet nach meinem Verständnis den untypisierten Funktionszeiger ProcessAddr auf die Funktion LoadPlugInProc vom Typ TLoadPlugIn. Es wird also kein Objekt erstellt. Das ist aber nur eine Vermutung, da ich nur dein Stück Quelltext kenne und das Tutorial von Sakura nicht suchen will.

Gruß

TheMiller 17. Nov 2006 15:24

Re: PlugIn laden / Verständnis
 
Der Quelltext ist aus Sakuras großen Plug-In-Tutorial. Die TLoadPlug-In-Funktion ist aus einer Klasse, die sowohl das hauptprogramm, als auch das Plug-In kennen muss. Aber diese Stelle im Code sagt mir nichts...

Der_Unwissende 17. Nov 2006 15:42

Re: PlugIn laden / Verständnis
 
Zitat:

Zitat von DJ-SPM
Der Quelltext ist aus Sakuras großen Plug-In-Tutorial. Die TLoadPlug-In-Funktion ist aus einer Klasse, die sowohl das hauptprogramm, als auch das Plug-In kennen muss. Aber diese Stelle im Code sagt mir nichts...

Ist die Codestelle so in dem Projekt? Wie ist denn der Typ TLoadPlugIn deklariert?

Jedenfalls hat Brainshock ja schon gesagt, dass an der Stelle kein Objekt erzeugt wird. An sich sieht dein Schema an einigen Stellen nicht ganz korrekt aus.

Zitat:

Zitat von DJ-SPM
Delphi-Quellcode:
    // Hier holst du dir einfach nur die Adresse des Einsprungpunkts 'LoadPlugin'
    // da wird kein Speicher reserviert oder sonst etwas importiert
    ProcAddr := GetProcAddress(TempHandle, 'LoadPlugIn');

    // hier prüfst du ob die zurückgegebene Adresse gültig ist
    // wenn nicht, dann gibt es einfach keine solche exportierte Funktion
    // oder ein Fehler ist aufgetaucht
    if ProcAddr = nil then
    begin
      // register function not exported
      FreeLibrary(TempHandle);
      Exit;
    end;

    // LoadPlugInProc ist ein Funktionszeiger!
    // hier wird (wie Brainshock schon sagte) der ungetypte Zeiger
    // in den entsprechenden Funktionszeiger gecastet
    LoadPlugInProc := TLoadPlugIn(ProcAddr); //<------DIESE STELLE

    try
      TempPlugIn := nil;
      // hier wird dann die Funktion auf die TempPlugin zeigt angesprungen
      // es entspricht also dem Aufruf einer normalen Funktion,
      // aber du kennst hier direkt die Adresse
      LoadPlugInProc(Application.Handle, TempPlugIn);
    except
      // register function invalid
      FreeLibrary(TempHandle);
      Exit;
    end;

Gruß Der Unwissende

[edit]
sorry, falscher Name (hab an diese eine Prog.Sprache gedacht
[/edit]

TheMiller 17. Nov 2006 15:47

Re: PlugIn laden / Verständnis
 
Das finde ich ja mal lustig:

Zitat:

Jedenfalls hat Brainfuck ja schon gesagt
Er heißt Brainshock :thumb:

Ok, das ist alles noch etwas neu für mich. Danke für deine Erklärung. Aber was ist ein ungetypter/ungecasteter Zeiger?

Der_Unwissende 17. Nov 2006 16:07

Re: PlugIn laden / Verständnis
 
Zitat:

Zitat von DJ-SPM
Ok, das ist alles noch etwas neu für mich. Danke für deine Erklärung. Aber was ist ein ungetypter/ungecasteter Zeiger?

Also ein Zeiger ist einfach nur eine Adresse (Pointer). Du zeigst wirklich auf eine bestimmte Adresse. Jetzt besagt der Typ Pointer, dass du, wenn du ihm folgst an einer bestimmten Stelle im Speicher landest, soweit so gut. Dummerweise weißt du jetzt nicht was sich an dieser Stelle im Speicher befindet. Da kann so ziemlich alles sein, nichts, eine Klasse, ein Record, ein Array, ein String, ein Integer,....
Natürlich machst du zu keinem Zeitpunkt etwas anderes als auf Speicher zuzugreifen, auch wenn du ein i: Integer verwendest und hier i einen neuen Wert zuweißt, wirst du irgendwo auf den Speicher zugreifen. Aber hier weiß das Programm, dass du ein Integer-Wert setzt. Damit ist die Typprüfung möglich, aber es passiert noch mehr. Du kennst die Adresse nie direkt, Delphi übernimmt das für dich. Weißt du i einen Wert zu, so wird einfach die Adresse der Variablen genommen und hier die 4 Byte (auf einer 32 Bit Maschine) als ein Integer interpretiert.

Typisierte Zeiger sind einfach Zeiger, von denen du weißt worauf sie zeigen. z.B. könntest du auf ein Integer zeigen. Dann kannst du hier nur die Adresse eines Integers zuweisen, versuchst du das gleiche mit der Adresse eines Strings, wird der Compiler das nicht zulassen.
Natürlich hat das den Vorteil, dass du so wieder eine Typprüfung hast. Greifst du auf den Wert zu, auf den der typ. Zeiger zeigt, so weiß Delphi wie dieser Wert zu interpretieren ist.

Auch Funktionen haben eine bestimmte Adresse. Was beim Aufruf einer Funktion gemacht wird ist auch wieder ganz einfach. Die Variablen werden auf eine bestimmte Art so abgelegt, dass die Funktion sie finden kann. Das wie hängt dabei von der Aufrufkonvention (z.B. Pascal, cdecl, stdcall) ab. Dann wird zu der Adresse gesprungen, an der sich der Code der Funktion befindet und diese abgearbeitet.
Während die Adressen (zumindest die virtuellen) deines Programms statisch sind, brauchst du beim dyn. Laden von Bibliotheken eine Möglichkeit die Sprungadresse erst zur Laufzeit zu ermitteln (das steckt in dem Code den du gepostet hast).
Jetzt kann eine DLL ganz beliebige Funktionen enthalten, der Entwickler legt fest welche und was diese für Argumente erwarten. Windows liefert dir also nur die Adresse der Funktion. Dies kann nur eine allgemeine Adresse sein. Willst du jetzt die entsprechende Funktion aufrufen, muss Delphi erst wissen was sich hinter der Adresse verbirgt. Eine allgemeine Adresse kann zwar eine Funktion sein, aber eben auch ein Integer, ein String...
Deswegen castest du die Adresse und legst damit den Typ dessen fest, was sich an der Adresse befindet.

Gruß Der Unwissende


Alle Zeitangaben in WEZ +1. Es ist jetzt 21:40 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz