Hilfe!!! Delphi 6/7 Compiler Fehler???

[LTE5]

Zitat:

Mit Delphi6 bzw 7 war ich bisher glücklich. Das ist schnell, bisher stabil und verfügbar.

Ok mit diesen Argumenten hast die neueren Delphis leider totgeschlagen (keine Ironie) ;)

[himitsu]

Dafür gibt es eine Chance, dass die Bugs irgendwann behoben werden oder sogar schon behoben wurden, was bei alten Delphis nicht der Fall ist. :zwinker:

Zitat:

Warum dann die Access Violation in der Delphi-Unit Menus in TMenu.SetWindowHandle???

Bei sowas kannst du auch immer die komplette Meldung angeben.
Strg+C in Delphi-Dialogen und dann hier Strg+V funktioniert gut.
Delphi kopiert bei Dialogen den Inhalt als Text in die Zwischenablage.

Zugriffsverletzung bei Adresse 00000xx -> irgendwas ist NIL (0 + Offset innerhalb des Objekts)
Zugriffsverletzung bei Adresse xxxxxxx -> Zeiger ist womöglich ungültig

Bei Ersterem hier

Delphi-Quellcode:

SubMenu.Visible:=false;

nachsehn ob die variable "SubMenu" NIL ist, was darauf deuten könnte, dass es dieses Objekt in der DFM nicht gibt, mit genau diesem Namen (Groß-/Kleinschreibung ist egal).

Da kein Anfänger, noch 'ne Info:
TComponent schreibt in seinen Owner seine Referenz rein, wenn es dort ein Published-Feld mit seinem Namen findet.
> Beim Erstellen (zuweisen des Owner), bei Namensänderung und beim Freigeben.
Der Typ dieser Felder muß passen, da diese "uralten" Funktionen nicht auf den Typ achten, also wäre dieses Feld nur ein Byte, statt einem TObjekt, dann gäbe es einen Bufferoverflow.

[Delphi.Narium]

Zitat:

Zitat von LTE5 (Beitrag 1389107)

Zitat:

Sorry, ja, ich hatte zwischen erstem und zweitem Post noch ein wenig rumexperimentiert, was man ändern darf und was nicht

Klingt also danach, dass du ein Anfänger bist. Noch ein Grund mehr ein modernes Delphi zu nutzen statt dieses völlig veraltete D7.

Ist Delphi 7 wirklich so schlecht, wie Du meinst?

Es ist nachwievor extrem selten, das die IDE oder der Compiler von Delphi 7 rumzicken. Meist sind das dann Fehler vom Anwender.

Bitte sei so gut, und akzeptiere, dass andere Programmierer andere Delphiversionen nutzen als Du. Delphi 7 war bisher wohl eine der besten Entwicklungsumgebungen. Es funktioniert einfach problemlos.

Abgesehen davon kann man aus dem Alter der genutzten Delphiversion nicht auf den "Befähigungsstatus" des Nutzers schließen. Ja, wir alten Säcke sind mit 'ner guten Entwicklungsumgebung zufrieden, auch wenn sie, so wie wir, schon etwas betagt ist.

@himitsu Die Qualität der Fehlerbehebung kann man ja momentan in 'nem anderen Thread "genüsslich" verfolgen ;-) (ironisch gemeint)

Zum Thema:

Nach dem Close wird nochmal Formresize aufgerufen. Dort erfolgt ein Zugriff auf SubMenu, dass zu diesem Zeitpunkt bereits nicht mehr existiert.

[iphi]

P.P.S.
Ups, beim Beispiel liegt die MainForm noch auf dem zweiten Bildschirm, so dass man sie mit einem Bildschirm allein nicht sieht. Anbei das Beispiel mit der Form auf dem Hauptbildschirm.

[himitsu]

Zitat:

Zitat von Delphi.Narium (Beitrag 1389113)

Nach dem Close wird nochmal Formresize aufgerufen. Dort erfolgt ein Zugriff auf SubMenu, dass zu diesem Zeitpunkt bereits nicht mehr existiert.

http://www.delphipraxis.net/194581-a...dowhandle.html :zwinker:
und siehe der letzte Absatz hier in Kommentar #12.

[Delphi.Narium]

Zitat:

Zitat von himitsu (Beitrag 1389116)

Zitat:

Zitat von Delphi.Narium (Beitrag 1389113)

Nach dem Close wird nochmal Formresize aufgerufen. Dort erfolgt ein Zugriff auf SubMenu, dass zu diesem Zeitpunkt bereits nicht mehr existiert.

http://www.delphipraxis.net/194581-a...dowhandle.html :zwinker:

Sieht mir nach 'nem Zusammenhang aus, bisher war wohl nur unklar, wo er war.

Also: Resize wird auch noch aufgerufen, wenn schon Teile des Formulars irgendwo im Nirwana entsorgt wurden.

Delphi-Quellcode:

procedure TForm1.KillButtonClick(Sender: TObject);
begin
  SubMenu.Visible := false;
  Self.OnResize := Nil;
  Close;
end;

Wenn das, was im OnResize steht, benötigt wird, das in eine eigene Prozedure packen und diese dann im OnResize aufrufen.

Wobei: Sollten im Resize tatsächlich Routinen sein, die zwingend beim Programmende aufgerufen werden müssen, erlaube ich mir die Frage, ob sie dann im Resize wirklich richtig aufgehoben sind.

[iphi]

Zitat:

Nach dem Close wird nochmal Formresize aufgerufen. Dort erfolgt ein Zugriff auf SubMenu,

soweit richtig.

Zitat:

dass zu diesem Zeitpunkt bereits nicht mehr existiert.

Nein, das existiert anscheinend noch, zumindest behauptet das der Debugger. Aber vieleicht spinnt der ja auch.

Zitat:

Sollten im Resize tatsächlich Routinen sein, die zwingend beim Programmende aufgerufen werden müssen, erlaube ich mir die Frage, ob sie dann im Resize wirklich richtig aufgehoben sind.

Nein, OnResize soll gar nicht bei Programmende ausgelöst werden, wird es aber beim D7 Code trotzdem.

Lazarus/FPC macht den Quatsch übrigens nicht. Derselbe Code in Lazarus läuft anstandslos. Grund: Lazarus löst bei Programmende keinen OnResize aus, hab ich gerade getestet. Leider kann man während der Compilierung mit Lazarus Kaffee trinken gehen.

[Delphi.Narium]

Wenn man im OnResize auf Assigned für Menu1, SubMenu oder MainMenu1 abfragt, so scheint es sie alle noch zu geben. Da scheinen aber Anschein und Realität voneinander abzuweichen.

Dem Formular einfach noch ein OnClose-Ereignis zuweisen und dort das OnResize auf Nil setzen. Das dürft dann auch mit Lazarus funktionieren und man muss nicht vor jedem Close im Programm (sofern es mehrere geben sollte) ein

Delphi-Quellcode:

Self.OnResize := Nil;

reinpacken.

[jaenicke]

Oder man löst es sauber... ;-)

Delphi-Quellcode:

procedure TForm1.FormResize(Sender: TObject);
begin
  if not (csDestroying in ComponentState) then
    SubMenu.Visible := true;
end;

// EDIT:

Zitat:

Zitat von Delphi.Narium (Beitrag 1389113)

Es ist nachwievor extrem selten, das die IDE oder der Compiler von Delphi 7 rumzicken. Meist sind das dann Fehler vom Anwender.

Ich erinnere mal an die fehlerhafte Randberechnung der Formulare und den Zeichenfehler bei DoubleBuffered in Kombi mit Buttons und Paintbox. Um nur die häufigsten Problemchen zu nennen.

[Delphi.Narium]

Zitat:

Zitat von jaenicke (Beitrag 1389162)

Zitat:

Zitat von Delphi.Narium (Beitrag 1389113)

Es ist nachwievor extrem selten, das die IDE oder der Compiler von Delphi 7 rumzicken. Meist sind das dann Fehler vom Anwender.

Ich erinnere mal an die fehlerhafte Randberechnung der Formulare und den Zeichenfehler bei DoubleBuffered in Kombi mit Buttons und Paintbox. Um nur die häufigsten Problemchen zu nennen.

Gut, dass mir das in den letzten 15 Jahren noch nicht aufgefallen ist ;-)

Vielleicht programmiere ich ja nur einfach zu wenig "exotisch", so dass es weitgehend problemlos funktioniert 8-)

Ok, bei komplexen Projekten, mit vielen eingebundenen Units, wie z. B. JVCL, Pascalscript, SynEdit, ..., mag der Debugger mir grundsätzlich keine Variabelinhalte anzeigen und die Auswahlbox für die Vervollständigung von Klassen liegt dann ab und an auchschonmal vollkommen "daneben" ... Das ist schon alles sehr ärgerlich. Und Änderungen an den Kompilerschaltern haben das keine "positive" Auswirkung.

Aber im Großen und Ganzen bin ich nachwievor zufrieden :-)