Was steht unter XE6 in Vcl.ComCtrls.TToolBarStyleHook.ApplyImageList?

[TiGü]

Hallo Gemeinde,

ich wollte den Threadtitel schon in "Waaas für Praktikanten arbeiten bei Emba?" benennen, fand es dann aber doch zu unsachlich.

Meine Kollegen arbeiten mit den C++Builder XE3 an einem VCL-Formular mit aktiviertem VCL Style unter 64-Bit.
Bei Verwendung des Stylings und einer TToolBar kam es unter bestimmten Umständen zu obskuren Access Violations, hier ein CallStack-Beispiel:

Code:

:00007FF956748A23 ; C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_5.82.9600.16384_none_34a8918f959016ea\COMCTL32.DLL
:00007FF95674C948 ; C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_5.82.9600.16384_none_34a8918f959016ea\COMCTL32.DLL
:0000000000a81178 ; Vcl::Imglist::TCustomImageList::SetNewDimensions(unsigned long long)
:0000000000a81294 ; Vcl::Imglist::TCustomImageList::SetHandle(unsigned long long)
:0000000000b8bb0e ; Vcl::Comctrls::TToolBarStyleHook::ApplyImageList()
:0000000000b8be52 ; Vcl::Comctrls::TToolBarStyleHook::Paint(Vcl::Graphics::TCanvas*)
:0000000000a59bf5 ; Vcl::Themes::TStyleHook::WMPaint(Winapi::Messages::TMessage&)
:0000000000cddaa1 ; System::TObject::Dispatch(void*)

Das sorgte auch dafür, das die Icons in den TToolButtons nicht richtig gesetzt bzw. verschoben dargestellt wurden.

Beim Debuggen des ToolBar-StyleHooks ist mir die folgende Stelle aufgefallen:

Delphi-Quellcode:

procedure TToolBarStyleHook.ApplyImageList;
var
  H: Cardinal; // <--- Was zum Kuckkuck ist das?
begin
  H := SendMessage(Handle, TB_GETIMAGELIST, 0, 0);
  if (H <> 0) and (FImages = nil) then
  begin
    FImages := TImageList.Create(nil);
    FImages.ShareImages := True;
    FImages.Handle := H;
  end;
end;

Warum wird hier ein fester Cardinal verwendet, anstatt ein HImageList?
Das kann ja wohl nicht wahr sein...:evil:

Ist das in XE6 gefixt?
Unter XE5 (beim Kollegen geschaut) ist der falsche Datentyp noch da.

[himitsu]

Zitat:

Delphi-Quellcode:

type
  THande = type Cardinal;

Vielleicht ist das noch ein "Übersetzungsfehler" aus dem Win32. :stupid:

Oder man hätte da auch LRESULT als Typ verwenden können. :roll:


Oder wie wäre es damit? :stupid:

Delphi-Quellcode:

procedure TToolBarStyleHook.ApplyImageList;
begin
  if not Assigned(FImages) then
  begin
    FImages := TImageList.Create(nil);
    FImages.ShareImages := True;
  end;
  FImages.Handle := SendMessage(Handle, TB_GETIMAGELIST, 0, 0);
end;

Seit wann gibt es TToolBarStyleHook eigentlich und warum verwendet sonst keiner Win64? :shock:

[Daniel]

Ohne Zweifel ist der Datentyp falsch, dennoch bleiben derartige Handles auch bei einem 64bit-Windows Zahlenwerte von 32bit. MSDN schreibt ausdrücklich, dass es sicher ist, die obere 32 Bit abzutrennen, wenn eine 32bit-Anwendung ein solches Handle erhalten soll.
Nichts anderes wird der Compiler bei o.g. Aufruf machen (können), weil der Zieldatentyp nichts anderes hergibt.

[TiGü]

Zitat:

Zitat von himitsu (Beitrag 1269391)

Seit wann gibt es TToolBarStyleHook eigentlich und warum verwendet sonst keiner Win64? :shock:

Na, frühstens zusammen mit den 64-Bit Compiler in XE2.
Daher gibt es auch keine Entschuldigung, dass es hier an der Stelle falsch gemacht wurde.

Ich persönlich war in meinen 64-Bit Delphi-Programm auch gar nicht betroffen, aber die C++Builder-Leute haben geflucht und gejammert.
Letztendlich läuft es darauf hinaus, dass ich den Style-Hook kopiert habe, die entsprechende Stelle gefixt und diesen eignen Hook anstatt des normalen per TCustomStyleEngine.RegisterStyleHook() anmelde.

[TiGü]

Zitat:

Zitat von Daniel (Beitrag 1269397)

MSDN schreibt ausdrücklich, dass es sicher ist, die obere 32 Bit abzutrennen, wenn eine 32bit-Anwendung ein solches Handle erhalten soll.

Und eine 64-Bit-Anwendung?
Ist es da auch sicher?
Ich denke eher nicht!

[Daniel]

Nun, Handles lassen sich zwischen Prozessen austauschen - insbesondere auch zwischen 64bit- und 32bit-Prozessen. Da Windows nicht wissen kann, was Du mit dem Handle anstellen wirst, kann es eigentlich nur ein 32bit-kompatibles Handle sein, dass da ausgestellt wird.
Ich muss mal schauen, ob ich die Unterlagen und Quellen wiederfinde. Tenor von MS war: "Der Wertebereich von 32bit langt für den Zweck."

[TiGü]

Könnte trotzdem jemand mal bitte in seinen XE6 VCL-Sourcen nachgucken? Das wäre lieb!

[Daniel]

Ist weiterhin als "Cardinal" deklariert.
Delphi XE6 20.0.15596.9843.


//edit: Ich sehe mal zu, heute Abend einen QC-Eintrag dafür zu erstellen.

[himitsu]

Wobei die 4 Milliarden Handles auch reichen sollte.

OK, oftmals sind das auch nur gekastete Pointer/ListenIndize, aber selbe bei der Beachtung von Signed und einem 8er Align, wären das immernoch über 268 Millionen und wie man das gerne bei den GDI-Handles sieht, sind die schon lange vorher "alle", womit der Wertebereich also locker reicht.

Einige Handle sind ja intern immernoch auf WORD begrenzt. Vielleicht ändert sich das mal, jetzt wo das 16-Bit-Subsystem langsam verschwindet. :gruebel:



Das Problem ist nun also, wenn der Code so im Prinzip eigentlich doch stimmt ... Warum knallt es hier nun eigentlich?

[TiGü]

Zitat:

Zitat von himitsu (Beitrag 1269431)

Das Problem ist nun also, wenn der Code so im Prinzip eigentlich doch stimmt ... Warum knallt es hier nun eigentlich?

Das frage ich mich auch!
Aber ich sehe halt, das mit entsprechenden Fix die Probleme in den C++Builder-VCL-Formularen verschwinden.

Kann es damit zu tun haben, dass wir in einer C#-WPF-Anwendung die C++-VCL-Formulare eingebettet haben?

[Daniel]

Nungut, Du wirst wohl nicht ewig Zeit haben, Dich jetzt noch mit dem Fehler zu befassen - zumal Ihr ihn ja für Euch korrigiert habt.
Aber die API-Funktion "SendMessage()" sollte doch auch bei mehrmaligen Aufruf stets das selbe Handle liefern. Man könnte es testweise sowohl in der 32bit- als auch in einer 64bit-Variablen speichern (über einen zweiten Aufruf) und schauen, ob tatsächlich derselbe Wert herauskommt.

[TiGü]

Es lag übrigens höchstwahrscheinlich daran, weil die VCL-Formulare in einer DLL liegen.
Dadurch sind vielleicht die ganzen Adressen verschoben.