Toolbar-Auslesen klappt nicht auf einem 64bit-Win7?

[r29d43]

@DeddyH

Normalerweise mache ich das zur Not dann auch. Nur an dieser spezifischen Stelle war es bisher halt unnötig, weil es da auch noch nie irgendwelche Errors gab. Zumal beim Besorgen von Handles man im Debugger ja auch gleich den Erfolg in Form einer Handle>0 sieht, bzw. bei einem Handle=0 der Error-Ort damit auch schon +/- gefunden ist. Im letzteren Fall würde ich dann natürlich auch versuchen, an das Funktionsergebnis mittels SysErrorMessage(GetLastError) dranzukommen.


@himitsu

Ein "Exit" hat mein Turbo Delphi schon, halt nur nicht dieses schöne Exit('...') mit dem man gleichzeitig auch noch das Result der zu exiten Funktion mit laden kann.

Bzgl. des IntPtr's gibt mir der Compiler trotzdem immer wieder nur eine E2015 aus: Operator ist auf diesen Operandentyp nicht anwendbar.

Und tatsächlich: In Post1 habe ich wirklich das erste Feld dieses Records vergessen mitzukopieren. Muss mir da irgendwie durch ein womöglich zu schnelles kopieren durch die Lappen gerutscht sein. Böse Sache, das *ggg*. Allerdings, mehr als so ein gewisses kleines Versehen war es auch nicht, denn sonst hätte der Compiler das Laden dieses einen vergessenen Feldes (etwas weiter unten im Code) ja sowieso gleich reklamiert.

Und bzgl. der Länge des Ur-Records sind die 32Byte schon klar. Und zwar im packed-Fall wie auch im {$Align 8}-Fall ...weil ja da kein Feld drin ist, dessen Länge >= 8Byte ist. Wenn ich diesen Record jetzt allerdings an ein Win64 abschicke, dann muss dieser LPTSTR-Pointer 8 statt nur 4 Byte lang sein. (So hatte ich das jedenfalls beim Beispiel mit dem Auslesen der Desktop-ListView gesehen ...und was da ja auch so funktionierte). Ergo habe ich an dieser Stelle dann ein int64-Type hingesetzt, was die Länge des Records dann im packed-Format auf 36 Byte erhöht. Und jetzt kommts irgendwie: Denn wenn ich das nun im {$Align 8}-Format compiliere, dann wird mir anschließend für den Record eine Länge von 40 Bytes ausgegeben ...was meiner Ansicht nach aber nicht der Fall sein dürfte, weil dieses "pszText"-Feld (dann ja ein int64-Type) nämlich beim Byte 24 des Records beginnt, also genau an einer dieser 8Byte-Schwellen, an die es sonst auch hin-aligned würde (was es deswegen jetzt ja nicht mehr muss)! ???


Und ja, jetzt wäre es wirklich super, so eine TBBUTTONINFO64-Record-Abbildung auch mal zu sehen, wie sie in einem 64Bit-Win vorliegt.

[himitsu]

Zitat von r29d43:

Und ja, jetzt wäre es wirklich super ...

Drum hatte ich gleich den Code mit gepostet.
Vielleicht kommt jemand anderes mit XE3 eher mal dazu. Bei mir wird's frühstens heute abend.

rein theoretisch würde ich es aber so vermuten

Code:

    Offset: 0    Size: 40    Type: TBBUTTONINFO64

    Offset: 0    Size: 4    Type: System.Cardinal   Name: cbSize
    Offset: 4    Size: 4    Type: System.Cardinal   Name: ewMask

    Offset: 8    Size: 4    Type: System.Integer   Name: idCommand
    Offset: 12    Size: 4    Type: System.Integer   Name: iImage

    Offset: 16    Size: 1    Type: System.Byte   Name: fsState
    Offset: 17    Size: 1    Type: System.Byte   Name: fsStyle
    Offset: 18    Size: 2    Type: System.Word   Name: cx
    Offset: 20    Size: 4    Type: System.Cardinal   Name: lParam

    Offset: 24    Size: 8    Type: System.PWideChar   Name: pszText

    Offset: 32    Size: 4    Type: System.Integer   Name: cchText 
    Offset: 36    Size: 4    Type: System.Integer   ***** dummy *****

(Gruppen zu je 8 Byte)

[r29d43]

Das vermute ich ebenfalls. Besser: Ich befürchte das ...weil mich das nämlich leider nicht weiterbringen würde. Denn mit genau so einem Record habe ich es ja die ganze Zeit über erfolglos versucht. Ergo hoffe ich da diesbezüglich noch auf eine event. kleine Überraschung. (ist zwar nicht unbedingt wahrscheinlich, aber trotzdem)


Bezüglich des dummy-Feldes in deiner "Vermutung": Heißt das, dass bei einem Record per {$Align 8) so eine endständige 8-Bytegruppe also immer bündig abgeschlossen wird? Was nämlich dann auch die 40Bytes Länge statt der erwarteten 36Bytes in meinem Beispiel erklären würde.

[himitsu]

Code:

   Offset:    Size: 48   Type: TBBUTTONINFO64

   Offset: 0   Size: 4   Type: System.Cardinal   Name: cbSize
   Offset: 4   Size: 4   Type: System.Cardinal   Name: ewMask
   Offset: 8   Size: 4   Type: System.Integer   Name: idCommand
   Offset: 12   Size: 4   Type: System.Integer   Name: iImage
   Offset: 16   Size: 1   Type: System.Byte   Name: fsState
   Offset: 17   Size: 1   Type: System.Byte   Name: fsStyle
   Offset: 18   Size: 2   Type: System.Word   Name: cx
   +4
   Offset: 24   Size: 8   Type: System.NativeUInt   Name: lParam
   Offset: 32   Size: 8   Type: System.PWideChar   Name: pszText
   Offset: 40   Size: 4   Type: System.Integer   Name: cchText
   +4

hmmmmm?

Zitat:

Delphi-Quellcode:

  ULONG_PTR = NativeUInt;
  DWORD_PTR = ULONG_PTR;

*_PTR sind also immer 64 Bit.
hatte es erst so verstanden, daß es 32 Bit ist und quasi einen "kleinen" Pointer darstellt,
aber wenn man es sich nochmals genau nachliest, dann stimmt's schon.
http://msdn.microsoft.com/en-us/library/aa383751.aspx

[r29d43]

Yeaaaaaaah, es geht!!!!!!!!!

Echt, suuuper Teamwork von dir. Aller besten Dank nochmal!

Die ersten zwei Versuche wollte es ja auch damit nicht so richtig klappen. Als ich dann aber in einem "letzten" Versuch auch noch den endständigen letzten 4Byte-dummy (von dem ich dachte, er sei eigentlich unwichtig) drangehängt hatte, kamen die ersehnten Button-Captions zum Vorschein.


Der fragliche und in einem 64bit-Win funktionsfähige Record sieht jetzt also folgendermaßen aus:

Delphi-Quellcode:

type
  TBBUTTONINFO64 = packed record
//  TBBUTTONINFO64 =  record // packed kann ich hier rausschmeißen, weil dann das default "{$A8}" zum Zuge kommt und das heißt: 8Byte lange Ptr werden an 8Byte-Grenzen ausgerichtet --> also genau das, was ein 64bit-Win benötigt
    cbSize: UINT;
    dwMask: DWORD;
    idCommand: Integer;
    iImage: Integer;
    fsState: Byte;
    fsStyle: Byte;
    cx: Word;
    _align1 : DWord;
//    lParam: DWORD;
    lParam: Int64;
//    pszText: PAnsiChar;
    pszText: Int64; // Zeiger haben in 64-Bit-Windows 8 Byte
    cchText: Integer;
    _align2 : DWord;
  end;

edit:

...bzw. so natürlich, jetzt mit dem defaultmäßig angeschaltetem {$ALIGN 8} und damit ohne das "packed" (ich hatte es ja sogar in der Kommentierung der davor per "//" ausgeschalteten 2'ten TBBUTTONINFO64-Zeile auch schon erwähnt):

Delphi-Quellcode:

  TBBUTTONINFO64 =  record // packed kann ich hier rausschmeißen, weil dann das default "{$A8}" zum Zuge kommt und das heißt: 8Byte lange Ptr werden an 8Byte-Grenzen ausgerichtet --> also genau das, was ein 64bit-Win benötigt
    cbSize: UINT;
    dwMask: DWORD;
    idCommand: Integer;
    iImage: Integer;
    fsState: Byte;
    fsStyle: Byte;
    cx: Word;
//    lParam: DWORD;
    lParam: Int64;
//    pszText: PAnsiChar;
    pszText: Int64; // Zeiger haben in 64-Bit-Windows 8 Byte
    cchText: Integer;
  end;

[himitsu]

Du übergibst ja die Recordgröße, und da dürfte es dann wichtig sein, denn über solche Size-Parameter können die APIs erkennen, welche "Version" des Records übergeben wurde, bzw. ob es die richtige Version ist.

Und wichtig ist soeine abschließende Ausrichtung z.B. für Arrays, also mehrere aufeinanderfolgende Records.