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

[himitsu]

Tja, als erstes hast du mal einen großen Fehler in deinem Record. (zumindestens da im Post #1)
Oder hast du das cbSize absichtlich weggelassen?

Code:

// blöde Formatierung der [delphi]-Tags ... wird das denn irgendwann mal repariert? (ich mag meine Leerzeichen nämlich)

uses
  RTTI;

type
  {$ALIGN 8}
  TBBUTTONINFO64 = record
    cbSize:     UINT;
    ewMask:     DWORD;
    idCommand: {int}LongInt;
    iImage:     {int}LongInt;
    fsState:    BYTE;
    fsStyle:    BYTE;
    cx:         WORD;
    lParam:     DWORD_PTR;
    pszText:    LPTSTR;
    cchText:    {int}LongInt;
  end;

procedure TForm11.Button1Click(Sender: TObject);
var
  R: TRttiRecordType;
  F: TRttiField;
begin
  R := TRttiContext.Create.GetType(TypeInfo(TBBUTTONINFO64)) as TRttiRecordType;
  Memo1.Lines.Add(
    '    Offset: ' +
    '    Size: ' + IntToStr(R.TypeSize) +
    '    Type: ' + R.Name);
  for F in R.GetFields do
    Memo1.Lines.Add(
      '    Offset: ' + IntToStr(F.Offset) +
      '    Size: ' + IntToStr(F.FieldType.TypeSize) +
      '    Type: ' + F.FieldType.QualifiedName +
      '    Name: ' + F.Name);
end;

Unter 32 Bit sieht es wie folgt aus.

Code:

    Offset: 0    Size: 32    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: 4    Type: System.PWideChar    Name: pszText
    Offset: 28    Size: 4    Type: System.Integer    Name: cchText

Mit 64 Bit kann ich's grade nicht testen.

[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.