![]() |
Re: DLL-Funktionen in Lazarus/FP einbindbar / wie einzubinde
Zitat:
Und folgender Code von dir zum dynamischen Laden mit LoadLibrary ist ziemlicher Unsinn (siehe Kommentare):
Delphi-Quellcode:
procedure TForm1.FormCreate(Sender: TObject);
var DLLHandle,hProcessSnap: THandle; Beispielfunktion: function(dwFlags:Integer;th32ProcessID:Integer):THandle;//alternativ Funktionsergebnistyp:Pointer, mit dem klappt es aber auch nicht begin DLLHandle := LoadLibrary(kernel32); if (DLLHandle < HINSTANCE_ERROR) then showmessage('DLL konnte nicht geladen werden!') else begin Beispielfunktion := @GetProcAddress(DLLHandle, 'CreateToolhelp32Snapshot'); //Du möchtest nicht mit dem Pointer auf GetProcAddress arbeiten //hProcessSnap:=CreateToolHelp32SnapShot(2{TH32CS_SNAPPROCESS},0); FreeLibrary(kernel32) //Du willst die Funktion doch noch verwenden, also darfst du die Bibliothek nicht entladen end end; |
Re: DLL-Funktionen in Lazarus/FP einbindbar / wie einzubinde
Danke auch für Deine Mühe!
Zitat:
Zitat:
Ich möchte einfach nur eine Funktion einer DLL benutzen. Diese muß ich anscheinend in der Weise extrahieren, daß ihre Funktionalität einer anderen Funktion übergeben wird, damit letztere (die neue, selbstdefinierte Funktion) die Funktionalität der ersteren übernimmt. Ich begreife nicht, warum das so kompliziert ist und der Lazarus/FP-Compiler sich so hartnäckig weigert. Sicher, irgendetwas stimmt nicht, doch was, weiß ich immer noch nicht. Zitat:
|
Re: DLL-Funktionen in Lazarus/FP einbindbar / wie einzubinde
Die ganze Kunst scheint darin zu bestehen, den Kommandozeilenschalter
Delphi-Quellcode:
zu verwenden, damit scheint es erstmal zu klappen.
{$mode DELPHI}
Tausend Dank für die Geduld an alle! Problem (erstmal?) geklärt.... |
Re: DLL-Funktionen in Lazarus/FP einbindbar / wie einzubinde
"External" sollte auch ohne {$MODE DELPHI} funktionieren.
Schau dir mal die folgenden Header an, vielleicht helfen die dir: OGG-Header (wird mit FPC mitgeliefert, statisches Laden): ![]() Acinerella Header (von mir, statisches Laden): ![]() Libao Header (von mir, dynamisches Laden, AcGetProcAddress ist (fast) nur ein Synonym für GetProcAddress) ![]() |
Re: DLL-Funktionen in Lazarus/FP einbindbar / wie einzubinde
Zitat:
Delphi-Quellcode:
mit der Fehlermeldung
function OpenThread; external kernel32 name 'OpenThread';
Delphi-Quellcode:
ab. Auch alle Bemühungen, den Fehlermeldungen des Compilers entsprechend, diesem die Codezeile schmackhaft zu machen (und sich damit immer mehr vom ursprünglichen Delphi-Quelltext bzw. der Delphi-Syntax zu entfernen), schlugen fehl.
unit1.pas(32,20) Fatal: Syntax error, ":" expected but ";" found
Danke für die Mühe, aber bei Dingen, die ich nur knapp bewältige, die eher mich regieren als umgekehrt, bin ich Dünnbrettbohrer. Bin froh, daß es jetzt überhaupt läuft... |
Re: DLL-Funktionen in Lazarus/FP einbindbar / wie einzubinde
Eine Funktion benötigt auch einen Rückgabewert. Und im verlinkten OGG-Header von FPC geht es auch ohne "Mode DELPHI".
|
Re: DLL-Funktionen in Lazarus/FP einbindbar / wie einzubinde
So... *Ärmel hochkrempelt*
Delphi-Quellcode:
Ich erkläre dir mal die Ursache im ObjFPC-Modus:
procedure TForm1.FormCreate(Sender: TObject);
var DLLHandle,hProcessSnap: THandle; Beispielfunktion: function(dwFlags:Integer;th32ProcessID:Integer):THandle;//alternativ Funktionsergebnistyp:Pointer, mit dem klappt es aber auch nicht begin DLLHandle := LoadLibrary(kernel32); if (DLLHandle < HINSTANCE_ERROR) then showmessage('DLL konnte nicht geladen werden!') else begin Beispielfunktion := @GetProcAddress(DLLHandle, 'CreateToolhelp32Snapshot');//klappt auch nicht, wenn ich das „@“ weglasse //hProcessSnap:=CreateToolHelp32SnapShot(2{TH32CS_SNAPPROCESS},0); FreeLibrary(kernel32) end end; Das Problem ist hier, dass du der Variable "Beispielfunktion" einen Verweis auf die GetProcAddress-Funktion übergibst, welche sich natürlich unterscheiden. Richtig wäre hier folgendes:
Delphi-Quellcode:
Ich weiß jetzt allerdings nicht aus dem Stegreif, ob der Code so dann auch unter Delphi funktioniert.
procedure TForm1.FormCreate(Sender: TObject);
type // wir benötigen einen Typ, zu dem wir casten können TCreateToolhelp32SnapshotProc = function(dwFlags: Integer; th32ProcessID: Integer): THandle; stdcall; // vergiss hier das stdcall nicht! var DLLHandle,hProcessSnap: THandle; Beispielfunktion: TCreateToolhelp32SnapshotProc; begin DLLHandle := LoadLibrary(kernel32); if (DLLHandle < HINSTANCE_ERROR) then showmessage('DLL konnte nicht geladen werden!') else begin // hier müssen wir jetzt auf den korrekten Typ casten Beispielfunktion := TCreateToolhelp32SnapshotProc(GetProcAddress(DLLHandle, 'CreateToolhelp32Snapshot')); //hProcessSnap:=CreateToolHelp32SnapShot(2{TH32CS_SNAPPROCESS},0); // aufrufen würdest du sie jetzt so: hProcessSnap := Beispielfunktion(2, 0); FreeLibrary(kernel32) end end; Du hast folgenden Code als Beispiel gepostet:
Delphi-Quellcode:
Das Problem hier ist, das dies in meinen Augen eine Unsauberkeit des Delphi-Compilers ist. Dies sehen auch die Entwickler von Free Pascal so, weswegen sie dies nur im Delphi-kompatiblen Modus erlauben. Sowohl unter Delphi, als auch unter FPC (egal ob Modus ObjFPC oder Delphi) funktioniert folgender Code:
interface
function OpenThread(dwDesiredAccess: DWORD; bInheritHandle: BOOL; dwProcessId: DWORD): THandle; stdcall; implementation function OpenThread; external kernel32 name 'OpenThread';
Delphi-Quellcode:
Hier stehen beide Angaben im Interface, was meiner Ansicht nach auch sauberer aussieht.
interface
function OpenThread(dwDesiredAccess: DWORD; bInheritedHandle: BOOl; dwProcessId: DWORD): THandle; stdcall; external kernel32 name 'OpenThread'; implementation Und jetzt noch ein Tip am Rande: Unter Free Pascal findet sich die CreateToolHelp32SnapShot Funktion in der Unit jwatlhelp32.pas, die sich im Ordner %FPCDIR%\packages\winunits-jedi\src befindet (wobei %FPCDIR% z. B. "C:\lazarus\fpc\2.2.4" sein kann). Du brauchst den Pfad allerdings nicht mit angeben, da die Units in den Unterverzeichnissen von Packages alle in der Konfiguration von Free Pascal eingetragen sind (insofern sie für die jeweilige Plattform kompiliert wurden). Allgemein finden sich - meines Wissens - fast alle WinAPI Funktionen in winunits-jedi. Ein Teil davon bzw die übrigen sind dann in packages/winunits-base oder rtl/win zu finden. Gruß, Sven |
Re: DLL-Funktionen in Lazarus/FP einbindbar / wie einzubinde
Das war/ist mehr, als das kühnste Horoskop zu träumen bwz. zu prognostizieren wagte, tausend Dank(s), JamesTKirk!
So ungefähr kann ich auch alles nachvollziehen. Das wichtigste ist aber, daß ich auf die Unit „tlhelp32.pas“ bzw. auf die Verrenkungen, einzelne ihrer Funktionen zu extrahieren und woanders einzubinden, verzichten kann, wenn die mit Lazarus mitgelieferte Unit „jwatlhelp32.pas“ eine ähnliche oder sogar die gleiche Funktionalität liefert. Bevor mir diese Informationen vorlagen, gelang es mir, die Unit „tlhelp32.pas“ mit dem o.g. Delphi-Compilerschalter fehlerfrei zu compilieren. Mit deren Funktionen wäre wohl auch ein Weiterarbeiten möglich gewesen, aber ich benutze natürlich lieber die Lazarus-Lieferpakete. Zuguterletzt sind die in dieser Diskussion gespeicherten Kenntnisse hoffentlich auch für andere nützlich. Die 1:1-Mal-Eben-So-Portiert-Kompatibilität zwischen Delphi und Lazarus sieht in der Praxis eben doch ganz anders aus: Der Teufel steckt auch hier, wie bekanntlich (fast) überall, im Detail. |
Re: DLL-Funktionen in Lazarus/FP einbindbar / wie einzubinde
Schön, dass ich dir weiterhelfen konnte. :mrgreen:
Möchtest du eigentlich an dem Programm, in dem du tlhelp32 benötigst, parallel mit Delphi und Lazarus arbeiten oder nur mit Lazarus? Bei ersterem hätte ich noch zwei verschiedene Vorschläge, mit denen du dir dein Leben erleichtern könntest. Gruß, Sven |
Re: DLL-Funktionen in Lazarus/FP einbindbar / wie einzubinde
Zitat:
Aber mit Vorschlägen mußt Du trotzdem keinesfalls geizen, die können - wem auch immer - in Situationen helfen, die man vorher gar nicht ahnt. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:13 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