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 von SearchBot:

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 von Aviator:

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 von Uwe Raabe:

Zitat von Aviator:

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.

[p80286]

Zitat von hoika:

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

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

Gruß
K-H

[KodeZwerg]

Zitat von hoika:

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 von KodeZwerg:

Zitat von hoika:

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