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

[r29d43]

Hallo,

es geht darum, eine Toolbar (die Schnellstartleiste = QuickLaunch) auszulesen, bzw. die Caption-Texte von den Buttons darauf. Bei einem 32bit-Win7 klappte das, beim 64bit-Win7 meines neuen Laptops jetzt aber leider nicht mehr.

Das exakt gleiche Problem hatte ich auch schon beim des Auslesens eines ListView-Controls. Das allerdings konnte ich lösen, mittels eines Tipps (von teebee) aus dem Forum hier (http://www.delphipraxis.net/129414-i...vista-x64.html). Die Lösung hier lag in einem Umbau einer LVItem-Struktur von einer 32Bit-Struktur in eine 64Bit-Struktur.

Ergo versuchte ich diese Lösung 1:1 auf mein ToolBar-Problem zu übertragen, was jetzt aber leider nicht mehr funktionierte. Nach wie vor bekomme ich als Text für die Button-Captions immer wieder nur einen leeren String zurück.

Sieht event. jemand woran das liegen könnte?

Und: Ist meine TBBUTTONINFO64-Struktur auch genauso geworden, wie sie ein 64bit-System erwartet?

Delphi-Quellcode:

function TSmallIconForm.GetTBButtonText64Bit(idCommand: Integer): String;

type
  TBBUTTONINFO64 = packed record
    ewMask: DWORD;
    idCommand: Integer;
    iImage: Integer;
    fsState: Byte;
    fsStyle: Byte;
    cx: Word;
    lParam: DWORD;
//    pszText: PAnsiChar;
                  _align: LongInt; // Zeiger müssen in 64-Bit-Windows an 8-Byte-Alignment beginnen
                  pszText: Int64; // Zeiger haben in 64-Bit-Windows 8 Byte
    cchText: Integer;
  end;
  PTBButtonInfo64 = ^TBButtonInfo64;

var ItemGlob: PTBButtonInfo64;
    InfoStruc: TBButtonInfo64;
    Buffer: Array[0..255] of Char;
    hProc: THandle;
    bw: Cardinal;
begin
  Result := '[Error]';
  if hSchnellstartleiste <> 0 then
  begin
    hProc := OpenProcess(PROCESS_VM_OPERATION or PROCESS_VM_READ or PROCESS_VM_WRITE,false,PID_TaskBar);
    if hProc <> 0 then
    begin
      ItemGlob := VirtualAllocEx(hProc,nil,SizeOf(InfoStruc)+SizeOf(Buffer),
                                 MEM_RESERVE or MEM_COMMIT, PAGE_READWRITE);

      if ItemGlob <> nil then
      try
        with InfoStruc do
        begin
          InfoStruc.cbSize := sizeof(InfoStruc);
          InfoStruc.dwMask := TBIF_TEXT;
          pszText := Cardinal(ItemGlob)+SizeOf(InfoStruc);
          cchText := SizeOf(Buffer);
        end;

        WriteProcessMemory(hProc,ItemGlob,@InfoStruc,SizeOf(InfoStruc),bw);    // parameter zum Data-Transfer: ..., "nach", "von", "länge",...
        sendMessage(hSchnellstartleiste,TB_GETBUTTONINFO,idCommand,integer(ItemGlob));
        ReadProcessMemory(hProc,Pointer(Cardinal(ItemGlob)+SizeOf(InfoStruc)), // parameter zum Data-Transfer: ..., "von", "nach", "länge",...
                          @Buffer[0],SizeOf(Buffer),bw);
        Result := Buffer;
      finally
        VirtualFreeEx(hProc,ItemGlob,SizeOf(InfoStruc)+SizeOf(Buffer),MEM_RELEASE);
        CloseHandle(hProc);
      end;
    end;
  end;
end;

[himitsu]

Mathematik?

Du hast einen 64-Bit-Zeiger und kastest ihn für die Positionsberecchungen nach Integer/Cardinal ... also das kann schonmal nicht gut gehn.

[edit]
hmmmm.

[edit2]

Zitat:

DWORD_PTR lParam;

Pointer? :wink:

PS:
- packed
+ {$ALIGN 8}

[r29d43]

Thx erstmal fürs Antworten.


Die TBBUTTONINFO64-Struktur habe ich aus der CommCtrl-Unit, von der dortigen TBBUTTONINFO-Struktur hergeleitet. Und dort steht auch: "lParam: DWORD;"

Das mit dem {$ALIGN 8} hat leider nicht geklappt. Ich glaube auch nicht so richtig dran, dass der Record unpacked sein kann, wenn der beim 32bit-Win schon packed gewesen ist. Es sei denn, beim 64bit-Win wären diese Strukturen jetzt alle unpacked?


Wenn ich übrigens mit SizeOf() die Summe der Längen aller Felder in der Struktur VOR dem pszText-Zeiger ermittle, dann komme ich gemäß:

type
TBBUTTONINFO64 = packed record
cbSize: UINT; = 4Bytes
dwMask: DWORD; = 4Bytes
idCommand: Integer; = 4Bytes
iImage: Integer; = 4Bytes
fsState: Byte; = 1Bytes
fsStyle: Byte; = 1Bytes
cx: Word; = 2Bytes
lParam: DWORD; = 4Bytes
// pszText: PAnsiChar;
_align: longint; // Zeiger müssen in 64-Bit-Windows an 8-Byte-Alignment beginnen
pszText: Int64; // Zeiger haben in 64-Bit-Windows 8 Byte
cchText: Integer;

auf eine gesamte Datenlänge vor dem Ptr von genau 24 Bytes. Also habe ich in einem weiteren Versuch auch mal dieses künstliche "_align: longint" ganz weggelassen. Allerdings auch leider ohne Erfolg.


?

[himitsu]

Das $Align sagt dem Compiler, wie er ausrichten soll, wenn nicht PACKED, womit dann das küntliche _align weg kann.

Was heißt eigentlich "funktioniert nicht" ?


Du könntest/solltest dein InfoStruc eventuell mal Nullen, also

Delphi-Quellcode:

FillChar(..., 0)

(für alles Ungenutzte/Nichtgesetzte).

Integer-Casts sind sowieso böse und speziell für SendMessage gibt es sogar passede Typen (LPARAM, WPARAM und LRESULT), welche man für den Cast nutzen kann.

Viele Befehle sagen einem, ob sie erfolgreich waren ... man sollte nur mal deren Result und z.B. GetLastError ordentlich auswerten.

Und was sagt der Debugger/Datenexplorer/MemoryView zu den Daten, die am Ende zurückkommen?

[Luckie]

Ist deins ein 32 oder 64 Bit Programm? Und zeig mal etwas Code.

[himitsu]

Zitat:

Zitat von Luckie (Beitrag 1187954)

Ist deins ein 32 oder 64 Bit Programm? Und zeig mal etwas Code.

TDE = 32

Ansonsten würde mein erster durchgestrichener Text den Fehler erklären.

[r29d43]

"funktioniert nicht" hieß in dem Falle, dass im Buffer leider immer nur ein leerer String herauskam.

FillChar(..., 0) brachte leider keine Besserung, ebenso wie mittels DWord o. LPARAM zu casten.

Die Results von WriteProcessMemory/ReadProcessMemory sind immer TRUE.

ALLERDINGS ist das Result von SendMessage(hSchnellstartleiste,TB_GETBUTTONINFO,. ..,...) negativ, also -1. Ergo dürfte also irgendetwas mit den Parametern nicht in Ordnung sein. Nur was eben? Kann doch eigentlich nur irgendwas kleines an diesem InfoStruc-Record sein!?

Momentan sieht der so aus:

Delphi-Quellcode:

//  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;
    lParam: DWORD;
//    pszText: PAnsiChar;
      pszText: Int64; // Zeiger haben in 64-Bit-Windows 8 Byte
    cchText: Integer;
  end;

ist 40 Byte groß. Im Packed-Format wäre er 36 Byte groß. Was mich eigentlich wundert, denn der einzigste 8Byte-Pointer darin, nämlich dieses pszText, beginnt doch eigentlich genau an einer 24Byte-Grenze.



@Lucki

habe ein Turbo Delphi für Win32

Die Routine von der aus ich die fraglich Proc oben calle, hat die Aufgabe, die Schnellstartleiste nach einem Button zu durchsuchen, der einen ganz bestimmten Caption-Text besitzt. Und das müsste eigentlich schon alles so stimmen, denn das Prog läuft ja in einer Win32-Umgebung völlig fehlerlos.

Delphi-Quellcode:

function TSmallIconForm.QuickLaunchIconChecker(AFileName : String) : boolean;
var AStrList : TStringList;
    ItemCount : integer;
    I : integer;
    Btn_idCommand : integer;
    TB_Style : integer;
begin
  HotQueryIs := true;
  result := false;

  hTaskBar   := FindWindow('Shell_TrayWnd',nil);
  hReBarWindow32 := FindWindowEx(hTaskBar,0,'ReBarWindow32',nil);
  hSchnellstartleiste := FindWindowEx(hReBarWindow32,0,'ToolbarWindow32',nil);

  GetWindowThreadProcessID(hTaskBar,PID_TaskBar); // nötig in den TaskBar-UntersuchungsProcs

  SetLength(QuickLaunchDim,0);
  while hSchnellstartleiste > 0 do begin   // Untersuchung der Symbolleiste ..ob eine ihrer ToolbarButtons genauso wie das fragliche Prog heißt?
    loadDebugStrList('hSchnellstartleiste:  ' + IntToStr(hSchnellstartleiste));
    ToolbarInfo.cbSize := sizeOf(TWindowInfo);      // ToolbarInfo ist nötig für den Check, ob die Maus aktuell
    getWindowInfo(hSchnellstartleiste,ToolbarInfo); //_in der Schnellstartleiste steht oder nicht (nachher in "findFilename")
    AStrList := TStringList.Create;
    ItemCount := sendMessage(hSchnellstartleiste,TB_BUTTONCOUNT,0,0);
    for I := 0 to ItemCount - 1 do begin
      Btn_idCommand := GetTBButton(I);
      if hasWin64Bit
      then AStrList.Add(GetTBButtonText64Bit(Btn_idCommand))
      else AStrList.Add(GetTBButtonText(Btn_idCommand));
      loadDebugStrList(' - - - - ' + AStrList.Strings[AStrList.Count-1] + '   < ' + IntToStr(I) + ' >');
    end;

    I := -1; // vor dem "findFilename"-Call nötig: Laden des HotItem-IndexWertes für diese Schnellstartleiste
    repeat inc(I); HotItem_ := HotItemDim_[I].Index
    until hSchnellstartleiste = HotItemDim_[I].hQuickLaunch;
    findFilename(AFileName,AStrList,bzglQuickLaunch);  // steht das Prog in der Schnellstartleiste und hat es event. den "hotItem"... Dann protokolliere das in der Ergebnisliste (=QuickLaunchDim)
    AStrList.Free;

    hSchnellstartleiste := FindWindowEx(hReBarWindow32,hSchnellstartleiste,'ToolbarWindow32',nil);
  end;

  loadDebugStrList('');
  for I := 0 to Length(QuickLaunchDim) - 1 do // auch die Ergbnisse der QuickLaunchDim werden letztlich noch
  with QuickLaunchDim[I] do                   //_in der DebugStrList ausgegeben
    loadDebugStrList('Index:  ' + IntToStr(Index) + '  hSchnellstartleiste:  ' + IntToStr(hQuickLaunch)
                     + '  HotFlag:  ' + BoolToStr(HotFlag) + '  MouseFlag:  ' + BoolToStr(MouseFlag));

  result := (Length(QuickLaunchDim)>0) and QuickLaunchDim[0].HotFlag;
  loadDebugStrList(#13#10 + ' > > > Result:  ' + BoolToStr(result) + ' < < <');
  loadDebugStrList(#13#10 + '===============================================' + #13#10);
end;

[DeddyH]

Wie bereits angedeutet wurde, werden in Deinem Code keine Rückgaben ausgewertet. Eigentlich sollte das statt so

Zitat:

Delphi-Quellcode:

hTaskBar := FindWindow('Shell_TrayWnd',nil);
hReBarWindow32 := FindWindowEx(hTaskBar,0,'ReBarWindow32',nil);

wohl besser so aussehen:

Delphi-Quellcode:

hTaskBar := FindWindow('Shell_TrayWnd',nil);
if hTaskBar <> 0 then
  begin
    hReBarWindow32 := FindWindowEx(hTaskBar,0,'ReBarWindow32',nil);

Oder alternativ auch z.B. so:

Delphi-Quellcode:

type
  ETaskbarNotFound = class(Exception);

hTaskBar := FindWindow('Shell_TrayWnd',nil);
if hTaskBar = 0 then
  raise ETaskbarNotFound('Taskbar-Handle nicht gefunden');
hReBarWindow32 := FindWindowEx(hTaskBar,0,'ReBarWindow32',nil);

Auf jeden Fall ist es keine gute Idee, immer vom Idealfall auszugehen.

[sx2008]

Warum liest du nicht das Verzeichnis %appdata%\Microsoft\Internet Explorer\Quick Launch aus sowie alle enthaltenen Lnk-Dateien?

PS: warum werden Backslashes zu Pipezeichen? Da stimmt doch was an der BBS-software nicht.

[himitsu]

Delphi-Quellcode:

begin
  if hSchnellstartleiste = 0 then
    Exit('[Error]');
  hProc := OpenProcess(PROCESS_VM_OPERATION or PROCESS_VM_READ or PROCESS_VM_WRITE,false,PID_TaskBar);
  if hProc = 0 then
    Exit('[Error:OpenProcess] ' + SysErrorMessage(GetLastError));
  ItemGlob := VirtualAllocEx(hProc, nil, SizeOf(InfoStruc) + SizeOf(Buffer), MEM_RESERVE or MEM_COMMIT or MEM_TOP_DOWN, PAGE_READWRITE);
  if ItemGlob = nil then
    Exit('[Error:VirtualAlloc] ' + SysErrorMessage(GetLastError));
  try
    FillChar(InfoStruc, SizeOf(InfoStruc));  // *1
    with InfoStruc do
    begin
      InfoStruc.cbSize := SizeOf(InfoStruc);
      InfoStruc.dwMask := TBIF_TEXT;
      pszText := IntPtr(ItemGlob) + SizeOf(InfoStruc);
      cchText := SizeOf(Buffer);
    end;
    if not WriteProcessMemory(hProc, ItemGlob, @InfoStruc, SizeOf(InfoStruc), bw) then  // *3
      Exit('[Error:WriteProcessMemory] ' + SysErrorMessage(GetLastError));
    SetLastError(0);  // *4
    R := SendMessage(hSchnellstartleiste, TB_GETBUTTONINFO, idCommand, LPARAM(ItemGlob));
    if (L = 0) or (GetLastError <> 0) then
      Exit('[Error:SendMessage] ' + SysErrorMessage(GetLastError));
    if not ReadProcessMemory(hProc, Pointer(IntPtr(ItemGlob) + SizeOf(InfoStruc)), @Buffer[0], SizeOf(Buffer), bw) then
      Exit('[Error:ReadProcessMemory] ' + SysErrorMessage(GetLastError));
    Result := Buffer;
  finally
    VirtualFreeEx(hProc, ItemGlob, 0, MEM_RELEASE);  // *2 : If the dwFreeType parameter is MEM_RELEASE, dwSize must be 0 (zero)
    CloseHandle(hProc);
  end;
end;

*1) Soll sicherstellen, daß nichtgenutzte Teile 0 sind, damit keine unbeabsichtigten Reaktionen ausgelöst werden ... deine lokale Variable ist aber mit zuzälligem Inhalt versehn.
*2) Dokumentationen sollte man schon noch lesen.
*3) Wie gesagt, Rückgabewerte auswerten und wenn, dann ordentlich, damit man damit auch was anfangen kann.
*4) LastError wird "natürlich" nicht gesetzt, wenn der Aufruf erfolgreich war, aber aus dem Result von SendMessage kann man nicht immer direkt etwas schließen.

Das Exit(...) steht für

Delphi-Quellcode:

begin Result := ''; Exit; end;

.
IMHO macht es den Code teilweise übersichtlicher.
- Weniger Verschachtelungsebenen, wo man erst viel später im ELSE was finden muß. So sieht man beide Aktionen sofort. (bei Fehler raus und sonst weiter)

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

"Früher" hat man doch Pointer in Integer gecastet, wenn man diesen als Zahl brauchte.

Delphi-Quellcode:

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

Delphi-Quellcode:

if (R = -1)

bzw.

Delphi-Quellcode:

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:

Zitat von r29d43 (Beitrag 1188018)

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! :thumb:

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.