TMainMenu Darstellung in IDE und zur Laufzeit unterschiedlich

[Whookie]

Nach all den Hinweisen hier - und einem leeren VCL Projekt, dass auch keine Probleme gezeigt hat - habe ich das Programm einmal zerlegen und bin nun zu folgendem (mehr oder wenig zufriedenstellendem) Ergebnis gekommen:

Der Bösewicht heißt GetOrdProp() und ausgelöst wird das Ganze durch die Multilizer VCL-Komponenten. Sie übersetzen das gesamte Projekt zur Laufzeit in verschiedene Sprachen und machen das mehr oder weniger automatisch, indem sie alle Objekte rekursiv durchlaufen und über GetOrdProp() feststellen ob ein String vorhanden ist, der übersetzt werden muss.

Dabei gelangen sie auch an die Bitmap-Eigenschaft des Menü-Items und in GetOrdProp wird festgestellt, das eine Klasse mit statischer GetProc vorhanden ist und diese aufgerufen. Das führt dann unweigerlich zum Aufruf von:

Code:

function TMenuItem.GetBitmap: TBitmap;
begin
  if FBitmap = nil then FBitmap := TBitmap.Create;
  FBitmap.Transparent := True;
  Result := FBitmap;
end;

in Vcl.Menus und damit wird jetzt eine TBitmap erzeugt (wohl gemerkt nur die Klasse - Height und Width bleiben 0), was dann in späterer Folge, wegen der Art und Weise wie Delphi zum Neuberechnen der Hotkeys gezwungen wird, zu meinem Problem führt.
Zum Glück kann man das Verhalten durch setzen von MainMenu.AutoHotKey := maManual umgehen.

Für alle die sich das trotzdem gerne einmal ansehen möchten habe ich ein kleines Demoprogramm angehängt, vielleicht gibt es ja eine elegante Methode AutoHotKey auf amAutomatic lassen zu können...

Das Programm muss nur compiliert werden ... "Burn!" alleine richtet keinen Schaden an, "Prepare hell.." auch nicht. Wird "Burn!" jedoch nach "Prepare hell.." angeklickt ist das "datei"-menü gefährlich breit geworden...

[Perlsau]

Habe dein Projekt eben mal kurz mit XE4 geöffnet und gestartet: Keinerlei fehlerhafte Darstellung des Menüs, auch nicht nach Klick auf einen der Buttons.

[jaenicke]

Dito, weder mit XE4 noch mit XE5 lässt sich das hier reproduzieren. Testen kann ich im Moment nur unter Windows 8.1.

[Perlsau]

@jaenicke
Wir – oder zumindest mein derzeitiger Auftragggeber, an dessen PC ich das vorhin getestet hatte – haben ja wohl auch keine "Multilizer VCL-Komponenten" installiert, die oben als mögliche Ursache genannt wurden.

@Whookie
Das von dir bereitgestellte Projekt macht irgendwie keinen Sinn: Wie soll man das Problem reproduzieren, wenn man diese Komponenten gar nicht installiert hat?

Da du ja offenbar diese "Multilizer VCL-Komponenten" verdächtigst, wie du oben schreibst, wäre es da nicht erstens mal Zeit, zu versuchen, den Test ohne diese Komponenten zu versuchen und zweitens, dich an den Hersteller dieser Komponenten zu wenden?

[jaenicke]

Zitat von Perlsau:

Wir – oder zumindest mein derzeitiger Auftragggeber, an dessen PC ich das vorhin getestet hatte – haben ja wohl auch keine "Multilizer VCL-Komponenten" installiert, die oben als mögliche Ursache genannt wurden.

Nein, aber er hat doch geschrieben, dass er meint, dass das an dem Aufruf von GetBitmap durch die Property Abfrage liegt. Und den hat er ja im Button simuliert.

Ich hätte auch eine Idee, aber da bei mir der Fehler nicht auftrat, konnte ich sie nicht testen... wenn ich den Quelltext in TMainMenu auf die Schnelle richtig deute, könnte es reichen, wenn man dafür sorgt, dass die TBitmap leer ist. (Denn dort wird nicht nur auf Assigned, sondern auch auf Empty geprüft.)

[Perlsau]

Der Fehler tritt mit dieser Simulation jedoch nicht auf, egal in welcher Reihenfolge ich die Buttons drücke. Ich kann jetzt zwar nicht mehr mit XE4 kompilieren, weil der Remote-Rechner, an dem ich heute nacht gearbeitet habe, offenbar abgestürzt ist, doch hab ich noch die kompilierte Echse hier, und da passiert gar nix, wie ich eben nochmal überprüft habe. Ergo müßte jemand testen, der die genannten Komponenten installiert hat, die ich nicht kenne.

Mehr kann ich dazu auch nicht sagen.