Bug in Vcl.Forms?

[SearchBot]

Hallo,

ich habe da ein seltsames Phänomen entdeckt, wenn ich mein Programm beende (siehe Bild).

Es kommt an dieser Stelle zu einer Zugriffsverletzung, weil FMenu plötzlich nil ist.
Wenn ich dort zur Behebung reinschreibe "if FMenu<>nil then ".., könnte ich es ja abfangen und vermeiden.

Aber die IDE kann meine Änderung nicht speichern, weil "Sicherungsordner 'c:\program files\embarcadero\studio\19.0\SOURCE\VCL\__history \' kann nicht angelegt werden."

Ich hab nicht die neuste Tokyo, vielleicht wurde es ja bereits behoben (wegen 20 Byte Fehlerkorrektur deinstalliere ich doch nicht mein Delphi, nur um dann die neuste Version 12GB und stundenlang wieder zu installieren!); wie kann ich mein Delphi dazu bringen, meinen kleinen Bugfix anzuwenden (auch erstmal zu speichern)?

[DieDolly]

Versuch mal ganz klassisch mit dem Windows Notepad und Administratorrechten. Damit umgehst du das Problem mit dem History-Verzeichnis.

Als kleiner Hinweis. In der aktuellen Community-Version ist ein Hotfix wie deiner nicht vorhanden.
Das Problem muss also von woanders herkommen.

[Uwe Raabe]

Zitat:

Zitat von SearchBot (Beitrag 1416600)

Es kommt an dieser Stelle zu einer Zugriffsverletzung, weil FMenu plötzlich nil ist.

Aber warum ist es plötzlich nil, wenn es das doch zwei Zeilen vorher offenbar noch nicht war?

Wenn das ein Bug in dem Code wäre, dann müsste man schon die Umstände beschreiben, bei dem das passiert. Es ist vermutlich kein generelles Problem, denn dann hätten das sicher noch viel mehr Leute.

Es wäre also interessant zu erfahren, wie es in deinem Fall zu dem nil-Wert kommt. Es ist gut möglich, daß du da einen viel schwerwiegenderen Fehler in deinem Code hast.

[Aviator]

So etwas hatte ich auch schonmal. Im Endeffekt war es ein Fehler in meinen eigenen Sourcen der sich bis zum Ende nicht bemerkbar gemacht hat. Meistens ein zu früh freigegebenes Objekt auf das am Ende wieder zugegriffen wird oder so.

An den Sourcen von Emba würde ich selbst nicht rumfummeln. Ich meine mich auch zu erinnern, dass es damals die gleiche Stelle war, kann dir aber meinen Fehler nicht mehr sagen.


Die Community Version basiert von den Sourcen her soweit ich weiß auf der 10.2 ohne Updates. Aber da kann sicherlich jemand anderes mehr dazu sagen oder auch einen Beweis vorlegen.

[hoika]

Hallo,
Erzeuge mal ein neues Projekt mit einem Menü.
Tritt der Fehler jetzt nicht auf, liegt es an Deinem Code.

[Uwe Raabe]

Zitat:

Zitat von Aviator (Beitrag 1416603)

Die Community Version basiert von den Sourcen her soweit ich weiß auf der 10.2 ohne Updates. Aber da kann sicherlich jemand anderes mehr dazu sagen oder auch einen Beweis vorlegen.

Die Community Version basiert auf dem letzen Stand 10.2.3 mit allen zur Zeit verfügbaren Updates.

[Aviator]

Zitat:

Zitat von Uwe Raabe (Beitrag 1416614)

Zitat:

Zitat von Aviator (Beitrag 1416603)

Die Community Version basiert von den Sourcen her soweit ich weiß auf der 10.2 ohne Updates. Aber da kann sicherlich jemand anderes mehr dazu sagen oder auch einen Beweis vorlegen.

Die Community Version basiert auf dem letzen Stand 10.2.3 mit allen zur Zeit verfügbaren Updates.

:thumb:

[p80286]

Zitat:

Zitat von hoika (Beitrag 1416604)

Tritt der Fehler jetzt nicht auf, liegt es an Deinem Code.

das sollte sich in der Zwischenzeit herum gesprochen haben. Zumindest Profis wissen das.:mrgreen:

Gruß
K-H

[KodeZwerg]

Zitat:

Zitat von hoika (Beitrag 1416604)

Hallo,
Erzeuge mal ein neues Projekt mit einem Menü.
Tritt der Fehler jetzt nicht auf, liegt es an Deinem Code.

Interessant finde ich die Sachlage dennoch.
"if <> nil then" aber im abschnitt ist es nil obwohl abfrage <> nil ist.

/edit
oder baue in deiner abfrage if FMenu.WindowHandle <> Nil ein, was passiert dann?
Ich meine, vielleicht hast Du ja ein FMenu object was nur noch kein WindowHandle besitzt?

[TiGü]

Zitat:

Zitat von KodeZwerg (Beitrag 1416664)

Zitat:

Zitat von hoika (Beitrag 1416604)

Hallo,
Erzeuge mal ein neues Projekt mit einem Menü.
Tritt der Fehler jetzt nicht auf, liegt es an Deinem Code.

Interessant finde ich die Sachlage dennoch.
"if <> nil then" aber im abschnitt ist es nil obwohl abfrage <> nil ist.

Nebenläufigkeit, Threads, Tasks...

[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

Delphi-Quellcode:

FMenu.WindowHandle:=0

gesetzt wird und dann die

Delphi-Quellcode:

Winapi.windows.SetMenu(Handle, 0)

angewiesen wird, statt umgekehrt. Ein

Delphi-Quellcode:

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 :roll:

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

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

Delphi-Quellcode:

if assigned(FWindowHandle) then

könnte hilfreich sein.

Ich habe das Problem jetzt so gelöst, daß ich im FormCloseQuery eine globale Variable

Delphi-Quellcode:

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 :wink:

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

Zitat von Aviator (Beitrag 1416721)

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:

Zitat von Uwe Raabe (Beitrag 1416722)

Zitat:

Zitat von Aviator (Beitrag 1416721)

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:

Zitat von SearchBot (Beitrag 1416600)

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

Zitat von Bernhard Geyer (Beitrag 1416727)

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

Delphi-Quellcode:

Application.ProcessMessages

oder die Events direkt auf.