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

[r29d43]

@DeddyH

Grundsätzlich stimme ich dir da natürlich zu. (Wenn allerdings "FindWindow" schon die Taskbar nicht mehr findet, dann ist das System sowieso höchstwahrscheinlich abgestürzt und es wird da wesentlich mehr nicht mehr funktionieren als nur mein Prog.)


@sx2008

Diese Idee hatte ich in der Zwischenzeit tatsächlich auch schon. Allerdings geht es mir in diesem Fall auch einfach etwas ums Prinzip. Dass nämlich ein relativ einfacher Code, der auf einem Win32 bestens läuft, dieses auf einem Win64 jetzt nur wegen eines wahrscheinlich winzigen Fehlers nicht mehr tut... und ich, bevor ich da jetzt also irgendeinen anderen Lösungsweg einschlage, doch lieber erstmal versuche, diesen höchstwahrscheinlich nur "winzigen" Fehler rauszukriegen...


@himitsu

thx für deinen Codehilfe. Leider hat mein Delphi dieses elegante Exit('...') nicht, so dass ich in einem solchen Fall immer so eine relativ globige 4 Zeilen lange begin-end-Struktur brauche.

Ist dein "IntPtr" eigentlich ein normales ^integer? Habe diesbezüglich mal alles etwas ausprobiert, was der Compiler allerdings nie akzeptiert hat. Habe das dann wieder durchs Cardinal ausgetauscht.

Und direkt unter der fraglichen SendMessage-Zeile ist das "if (L=0)..." wohl durch ein "if (R=-1)..." auszutauschen, oder? Denn das L hattest du davor ja nirgendwo initialisiert etc...

Wie auch immer, dass Ergebnis nach dieser SendMessage-Zeile lautet auch mit deinem Code nach wie vor für das R = -1 und für die Übersetzung des GetLastError-Resultates: "[Error: SendMessage] Der Vorgang wurde erfolgreich beendet".

(PS. Hatte den Code mal vor einigen Jahren hier aus dem Forum aufgegabelt und auch ganz gut verstanden ...und deswegen auch nicht nochmal extra in die Dokumentation einer jeden Anweisung reingeguckt.)


@Alle,

imo müsste die eigentliche Fehlerursache immer noch in einer falschen Record-Umwandlung liegen. Weil der doch auch irgendwie das einzigste Teil ist, das sich am ganzen Code wirklich geändert hat! ???

[DeddyH]

Wie gesagt: Rückgaben auswerten und schauen, wo es genau es nicht mehr klappt. Oder möchtest Du lieber so lange raten, bis Du den Fehler scheinbar gefunden hast?

[himitsu]

Schade, ich war mich sicher das Exit wurde schon im D2006 eingeführt.

"Früher" hat man doch Pointer in Integer gecastet, wenn man diesen als Zahl brauchte. Integer(P)
Da nun aber der Integer, in Bezug auf 64 Bit, eingefroren wurde, ist das nicht so schön.
NativeInt könnte man jetzt zwar verwenden, aber da wurde eben auch gleich ein passender Typ für diesen Cast erfunden. IntPtr ist praktisch ein ^NativeInt, bzw. UIntPtr ein ^NativeUInt.
NativeInt/NativeUInt sind die neuen Integer/Cardinal. (Integer war in Win16 ja mal 16-bittig)

Delphi-Quellcode:

{$IF not Declared(IntPtr)}
type
  IntPtr = {$IF Declared(NativeInt)}NativeInt{$ELSE}Integer{$IFEND}
{$IFEND}

Zitat:

Wie auch immer, dass Ergebnis nach dieser SendMessage-Zeile lautet auch mit deinem Code nach wie vor für das R = -1 und für die Übersetzung des GetLastError-Resultates: "[Error: SendMessage] Der Vorgang wurde erfolgreich beendet".

Jupp, sollte ein if (R = -1) bzw. if (R < 0) werden. (SendMessage + TB_GETBUTTONINFO)

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

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