![]() |
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:
Danke
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; |
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ß |
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...
|
Re: PlugIn laden / Verständnis
Zitat:
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:
[edit] sorry, falscher Name (hab an diese eine Prog.Sprache gedacht [/edit] |
Re: PlugIn laden / Verständnis
Das finde ich ja mal lustig:
Zitat:
Ok, das ist alles noch etwas neu für mich. Danke für deine Erklärung. Aber was ist ein ungetypter/ungecasteter Zeiger? |
Re: PlugIn laden / Verständnis
Zitat:
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 17:27 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz