Bug in Vcl.Forms?

[SearchBot]

Hey,

ja, ich bin da mal ganz durchgesteppt. Diese kleine Zuweisung auf FMenu macht hintenrum ja ne ganze Menge.
Ich kann nun zwar den Code ändern (hab die Verzeichnisrechte alle auf Vollzugriff umgestellt...), aber er scheint das trotzdem nicht zu compilieren - wenn ich nämlich eine Zeile einfüge, sind die blauen Punkte noch an der selben Stelle und die IDE erzeugt also keine neuen DCUs? Bei den Vcl.Forms aber scheinbar schon, bei den Vcl.Menus aber nicht?! Ich hab nicht finden können, wo die hincompiliert sind (Es war dann auch schon spät).

Es scheint besser zu sein (obwohl ich mir nicht sicher bin, daß der Compiler meine Änderung mitgenommen hat), wenn zuerst FMenu.WindowHandle:=0 gesetzt wird und dann die Winapi.windows.SetMenu(Handle, 0) angewiesen wird, statt umgekehrt. Ein if assigned(FMenu) then scheint auch hilfreich.

Das Problem tritt ja auf beim Zerstören der Objekte, WMDestory...

Ich habe eine kleine Routine im FormResize:

Delphi-Quellcode:

procedure TForm1.FormResize(Sender: TObject);
begin
 m_time.ImageIndex:=byte(form1.WindowState<>wsMinimized);
 Timer1.Enabled:=m_time.ImageIndex=1;
end;

Die Idee war, wenn das Form minimiert ist, muss der Timer nicht an sein.
m_time (TMenuItem) hat eine kleine Grafik, die anzeigt, ob die Funktion aktiv ist (ImageIndex=1) oder nicht (ImageIndex=0).

Dennoch ist es so, daß der Fehler nur dann auftritt, wenn ImageIndex=0..., ist es 1 dann knallt es seltsamerweise nicht

Bei durchsteppen ist mir aufgefallen, daß das FormResize nach dem FormCloseQuery auch aufgerufen wird.
Die Zuweisung des ImageIndex ist dann wohl nicht so optimal, wenn das MenuItem gerade vorher zerstört wurde

Dass diese Möglichkeit aber im Vcl.Menus nicht berücksichtigt wird...?!

Delphi-Quellcode:

procedure TMenu.SetWindowHandle(Value: HWND);
begin
   FWindowHandle := Value;

Wenn FWindowHandle schon aufgelöst ist, endet es hier (bei mir). Ein if assigned(FWindowHandle) then könnte hilfreich sein.

Ich habe das Problem jetzt so gelöst, daß ich im FormCloseQuery eine globale Variable ending:=true setze und dann es so mache:

Delphi-Quellcode:

procedure TForm1.FormResize(Sender: TObject);
begin
 if not ending then begin
  m_time.ImageIndex:=byte(form1.WindowState<>wsMinimized);
  Timer1.Enabled:=m_time.ImageIndex=1;
 end;
end;

Dann ist auch alles gut.
Und ich habe wieder was gelernt

[DieDolly]

Zitat:

Ich kann nun zwar den Code ändern (hab die Verzeichnisrechte alle auf Vollzugriff umgestellt...)

Vcl.Menus.pas mit Notepad++ als Administrator öffnen hätte auch gereicht.

[Aviator]

Ich glaube immer noch nicht an einen Fehler in den Delphi Sourcen. Ich denke eher, dass durch das Destroy der Form irgendein Event ausgelöst wird in dem nochmal auf ein nicht mehr existentes Objekt zugegriffen wird und dadurch der Fehler auftritt.

Ich suche einen solchen Fehler immer so, dass ich zuletzt geänderte Dinge (seitdem der Fehler passiert) auskommentiere oder rückgängig machen. Hier könnte ein VCS hilfreich sein. Alternativ kannst du auch mal Events von bestimmten Komponente (die neu hinzugekommen sind) deaktivieren bzw. nicht mehr behandeln. So kannst du dich dem Fehler immer weiter nähern.

Aber einfach so die Delphi Sourcen ändern ist IMO keine gute Idee. Der Fehler tritt ja nicht seit Beginn auf, oder?

[Uwe Raabe]

Zitat von Aviator:

Ich glaube immer noch nicht an einen Fehler in den Delphi Sourcen.

Da stimme ich dir zu. Dieser Code wird täglich millionenmal ohne Probleme ausgeführt. Ich bin ziemlich sicher, daß das Problem woanders liegt und mit diesem Patch nur tiefer versteckt wird.

[hoika]

Halo,
und noch einmal.
Tritt der Fehler auch bei einem neuen Projekt?

[Bernhard Geyer]

Zitat von Uwe Raabe:

Zitat von Aviator:

Ich glaube immer noch nicht an einen Fehler in den Delphi Sourcen.

Da stimme ich dir zu. Dieser Code wird täglich millionenmal ohne Probleme ausgeführt. Ich bin ziemlich sicher, daß das Problem woanders liegt und mit diesem Patch nur tiefer versteckt wird.

Das ist definitiv so:

Zitat von SearchBot:

... wenn ich mein Programm beende

Da hier viel Aufräumarbeiten geschehen kann es sehr wohl sein das nach einem WinAPI-Aufruf auch Variablen die zwei Zeilen zuvor noch gültig waren schon im Rahmen der Aufräumarbeiten nicht mehr gültig sind. Die Lösung ist hier zu verhindern das beim Beenden des Programmes nicht noch irgendwelche Timer, (In)Activate, FocusChanged und Co-Events abgearbeitet werden.

[Uwe Raabe]

Zitat von Bernhard Geyer:

Die Lösung ist hier zu verhindern das beim Beenden des Programmes nicht noch irgendwelche Timer, (In)Activate, FocusChanged und Co-Events abgearbeitet werden.

Eigentlich sollten zu dem Zeitpunkt gar keine Events mehr aufgerufen werden, da die Message-Queue nicht mehr abgearbeitet wird - außer jemand ruft z.B. sowas wie Application.ProcessMessages oder die Events direkt auf.