Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Win32/Win64 API (native code) (https://www.delphipraxis.net/17-win32-win64-api-native-code/)
-   -   Delphi Probleme mit Datentypen bei einer DLL (https://www.delphipraxis.net/168978-probleme-mit-datentypen-bei-einer-dll.html)

mcinternet 21. Jun 2012 13:30

AW: Probleme mit Datentypen bei einer DLL
 
Zitat:

Zitat von shmia (Beitrag 1171927)
Zitat:

Zitat von DeddyH (Beitrag 1171921)
Normalerweise übergibt man einen Speicherbereich, den man selbst reserviert hat,...

In dem konkreten Fall wäre die Art der Datenübergabe aber schon plausibel.
Es gibt ja offensichtlich mehrere Fehlermeldungen, die über einen errorCode ausgewählt werden.
Die Strings liegen in dem Fall hartcodiert im Speicherbereich der DLL und der Aufrufer bekommt lediglich einen Zeiger zurück.
Delphi-Quellcode:
function xyzErrMsg(errorCode : Word): PAnsiChar; stdcall; external xyzdll name 'ErrMsg';

var
  Meldung : AnsiString; // nicht PAnsiChar !
  Fehlernummer : Word;
Begin
  Fehlernummer := 42; // nicht vergessen die Fehlernummer zu setzen!!!
  Meldung := xyzErrMsg(Fehlernummer); // Zeiger auf 0-terminierten String wird automatisch in einen Delphi-String umgewandelt. (Compiler Magic)
  ShowMessage(Meldung);

Bei dieser Version bekomme ich immer eine Zahl ( immer die gleiche, egal welchen Code ich übergebe ) zurück => 1180672

Gruss
McInternet

NickelM 21. Jun 2012 18:08

AW: Probleme mit Datentypen bei einer DLL
 
Liegt dir nicht der Original export vor?
In dem Buch wird doch sicher irgendwie ein Beispiel oder sonstwas stehen, oder wenn sie von C++ kommt poste mal die Dekleration von dort.
Das Ding ist nämlich, bei PAnsiChar's gibt es 2 Mögliche aufrufe.
- Erstens du übergibst die Variable, wo der Pointer "gespeichert" bzw. hinterlegt wird. Die DLL legt ggf. den Speicher fest und übergibt dir den Pointer (Adresse);
- Du musst einen Speicher festlegen. Dazu müsstest du die Größe wissen, also wie Lang der Text sein wird. Du legst den Speicher fest und übergibst die Variable an die Funktion. Diese schreibt in die Adresse die Daten.

In deinem Fall würd ich auf das erste Tippen. Versuch mal folgendes:
Delphi-Quellcode:
function xyzErrMsg(errorCode : Word): Pointer; stdcall; external xyzdll name 'ErrMsg';
//oder mal das
function xyzErrMsg(errorCode : Word): Pointer; cdecl; external xyzdll name 'ErrMsg';
//oder mal einen von den Beiden
function xyzErrMsg(const errorCode : Word): Pointer; stdcall; external xyzdll name 'ErrMsg';
function xyzErrMsg(const errorCode : Word): Pointer; cdecl; external xyzdll name 'ErrMsg';
//noch eine Möglich aber unwahrscheinlich
function xyzErrMsg(var errorCode : Word): Pointer; stdcall; external xyzdll name 'ErrMsg';
function xyzErrMsg(var errorCode : Word): Pointer; cdecl; external xyzdll name 'ErrMsg';
//Bei allen Möglchkeiten lass das Pointer mal hintendran.

var
  Meldung : PAnsiChar;
  P : Pointer;
  ErrorCode : Word;
Begin
  for ErrorCode := 0 to High(Word) do
  begin
    P := xyzErrMsg(ErrorCode);
    If P <> nil then
    begin
      Meldung := P; //Setz mal hier ein Breakpoint
      ShowMessage(Meldung);
    end;
  end;
So bei irgendeinem Wert muss er ja einen Text zurückgeben. Und alle Imports mal durchgehen mit diesem Code.

EDIT: Sorry, überlesen, hast ja schon gesagt, dass es keine Doku oder sonstwas gibt. Das sie in C geschrieben ist, sollte einer der cdecl; oben vielleicht eher funken.
Vielleicht Funkt dan irgendwas.

Gruß NickelM

himitsu 21. Jun 2012 18:27

AW: Probleme mit Datentypen bei einer DLL
 
CONST bringt bei Word nicht viel (ändert garnichts).

"ErrMsg" ... C++ baut gerne auch die Parametersignatur in den Exportnamen ein. Eventuell heißt es ja nicht "ErrMsg". ( ist das eigentlich CaseSensitiv? )

Statt Pointer kann man auch gleich PAnsiChar nehmen.
PWideChar wird es mit großer Wahrscheinlichkeit nicht sein.

Neben cdecl und stdcall gibt es noch ein paar Varianten mehr, aber Anderes hab ich hier auch noch nicht gesehn. (außer selten mal savecall und in Delphi natürlich pascal)

NickelM 21. Jun 2012 18:48

AW: Probleme mit Datentypen bei einer DLL
 
@himitsu : Ich weis, wegen Pointer. Wollte nur mal gugen, ob sich der Pointer immer ändert, ob er ungleich nil ist und wenn der Pointer existiert, ich die Adresse dann erst übertrage.
Wenn es dan funkt mit irgendeinem Funktionsaufruf, kann man immernoch Pointer durch PAnsiChar ersetzten.
Stimmt CONST bringt bei PWideChar,PAnsiChar oder sonstwo nur was, wenn sie als Paramter übergeben werden richtig? Was macht das dan eigentlich für einen Unterschied? Ich denke mal CONST bringt, das bei PAnsiChar,PWideChar z.b. der Text im Speicher der Funktion liegt und nicht die Adresse des Textes oder?
@Thread : Was mir gerade einfällt, so beim schreiben grad, wegen dem Namen der Funktion.
Ich kenn die Dll nicht vielleicht heist die Funktion ja "ErrMsgA".
Zumindest ist es oft bei WinAPIs so. Neuere Dlls, so ab Win2000 haben dann eine "ErrMsgA" und eine "ErrMsgW". Das "A" steht für ANSI und das "W" für Wide also PWideChar.

Das wären jetzt meine einizg letzen Ideen.

Gruß NickelM

Blup 22. Jun 2012 08:33

AW: Probleme mit Datentypen bei einer DLL
 
Raten bringt hier nicht viel.
Entweder mit dem Debugger in die DLL-Funktion springen und sich den Code anschaun oder gleich die ganze DLL diassemblieren (Windasm o.ä.).

mcinternet 2. Jul 2012 09:23

AW: Probleme mit Datentypen bei einer DLL
 
Problem ist gelöst.
da ich in die dll definitiv nicht hereinschauen kann, habe ich eine eigene Fehlercodetable aufgebaut :oops:

danke an alle für die Tipps.

Gruss

mc


Alle Zeitangaben in WEZ +1. Es ist jetzt 09:15 Uhr.
Seite 2 von 2     12   

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