Addresse eines var Parameters ermitteln

[TurboMagic]

Und wie ist das jetzt mit dem Ermitteln der Adresse Zwecks Anzeige?

[Uwe Raabe]

Was ist denn da genau das Problem? Die Adresse einer Variable ist ein Pointer, den du z.B. über Format('(%p)', [theVarPtr]) in einen String umwandeln kannst.

[Andreas13]

Hallo TurboMagic,
sollte der Aufruf Deiner DLL von VBA aus erfolgen, dann muß das erste Element als ByRef und mit dem passenden Variablen-Typ des Elements übermittelt werden.

[hoika]

Hallo,
ist das die einzige Funktion, die Probleme bereitet?
Vielleicht benutzt das andere Programm einfach nur die falsche Aufruf-Konvention?

Wie sieht dein Exports aus und wie der Imports des fremden Programmes?
In welcher Sprache ist es überhaupt?

[himitsu]

Zitat von hoika:

Wie sieht dein Exports aus und wie der Imports des fremden Programmes?
In welcher Sprache ist es überhaupt?

Das Problem lässt sich leicht lösen.

Einfach nur mit 64 Bit kompilieren.
Da gibt es dann nur noch eine Konvention (die zufällig sehr pascallig aussieht).

[TurboMagic]

Hallo,

nix falsche Aufrufkonvention. Die Nutzer haben tatsächlich mit NULL aufgerufen.
Mit der von Uwe angegebenen Format-String Ausgabe kann ich das bestimmt auch
im Log nachweisen, aber es wurde jetzt auch drüber gesprochen diesen Parameter
optional zu machen, was bedeutet, dass ich rausbekommen muss, ob der NULL ist.

Mit Assigned geht es nicht. Es wäre evtl. die Option diese Formatstring Ausgabe
abzuprüfen, da müsste ja für NULL dann '0x00000000' zurückkommen.

Da es die DLL per4spektivisch auch in 64 bit geben wird müsste ich zusätzlich
auch auf '0x0000000000000000' prüfen.

Oder gibt's nicht doch eine bessere Alternative?
Möglichst eine, bei der ich die Deklaration dieses Var-Parameters nicht
abändern muss.

Grüße
TurboMagic

[jaenicke]

Du kannst doch einfach einen Pointer daraus machen. Das ist im Hintergrund auch nichts anderes und so wird es in anderen Sprachen ja bei der Übersetzung ohnehin deklariert (weshalb dann dort auch null übergeben werden kann).

Wenn du die Adresse mit @ abfragst, sollte die aber auch nil sein.

// EDIT:

Delphi-Quellcode:

procedure Test(var a: Int32);
begin
  ShowMessage(IntToHex(NativeUInt(@a), 8) + ' - ' + BoolToStr(Assigned(@a), True));
end;

type
  PInt32 = ^Int32;

procedure TestA(a: PInt32);
asm
  call Test;
end;

procedure ExecTest;
var
  b: Integer;
begin
  b := 42;
  Test(b);
  TestA(@b);
  TestA(nil);
end;

[TiGü]

Zitat von TurboMagic:

Oder gibt's nicht doch eine bessere Alternative?
Möglichst eine, bei der ich die Deklaration dieses Var-Parameters nicht
abändern muss.

Mach aus

function DeineFunktion(var AParameter: UInt32): TRückgabewert;
vernünftigerweise sowas:
function DeineFunktion(AParameter: PUInt32): TRückgabewert;

So kannst du in deiner Funktion prüfen:

Delphi-Quellcode:

function DeineFunktion(AParameter: PUInt32): TRückgabewert; 
begin
  if AParameter <> nil then
  begin
  // ...
  end;
end;

EDIT: Siehe auch jaenickes Beitrag über meinen.

[himitsu]

Klar sollte Assigned natürlich auf NIL (C-isch als NULL) prüfen kommen.
Oder meinst das Variant-NULL?

Assigned macht ja auch nur <>nil.
Einzige Ausnahme sind Methoden-Zeiger, wo es zwei nil gibt.



Und was ist denn nun null?
* der Inhalt der Variable
* oder haben sie bösartig die Adresse zur Variable gelöscht?

Letzteres dürfte dir aber egal sein, da es außerhalb keine Wirkung hat und die veränderte Adresse des VAR-Parameters nur innerhalb deren Funktion besteht. (die wird ja quasi dennoch als CONST und None-Reference übergeben ... außer du hast einen Zeiger auf einen Zeiger auf die eigentliche Speicherstelle )