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

[iphi]

Hallo,

im folgenden ein einfacher und kurzer Code, der bei mir sowohl unter D6 als auch unter D7 eine Access Violation produziert, wenn man den KillButton drückt:

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, Menus, StdCtrls;

type
  TForm1 = class(TForm)
    KillButton: TButton;
    MainMenu1: TMainMenu;
    Menu: TMenuItem;
    SubMenu: TMenuItem;
    procedure KillButtonClick(Sender: TObject);
    procedure FormResize(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.KillButtonClick(Sender: TObject);
begin
SubMenu.Visible:=false;
close;
end;

procedure TForm1.FormResize(Sender: TObject);
begin
SubMenu.Visible:=true;
end;

end.

Ich mache doch nichts böses, oder?!?
Warum dann die Access Violation in der Delphi-Unit Menus in TMenu.SetWindowHandle???

Es müssen übrigens zwei MenuItems sein, mit einem allein tritt der Fehler nicht auf. Sie müssen nicht geschachtelt sein, aber Menu muss vor Submenu kommen.

[himitsu]

Wie sieht denn die DFM aus?

Grundsätzlich ist dieser Code erstmal OK und vorallem für Delphi 7 kann ich solche Fehler nicht bestätigen.
Die Reihenfolge von SubMenu und Menü sollten auch keine Rolle spielen.


PS: https://www.embarcadero.com/de/products/delphi/starter

[LTE5]

Zweite Frage
warum kein Delphi 10.2 Starter?

[iphi]

Zitat:

Wie sieht denn die DFM aus?

Standardform mit einem Button und einem Hauptmenü mit zwei Menuitems drauf:

Delphi-Quellcode:

object Form1: TForm1
  Left = -1469
  Top = 233
  Width = 589
  Height = 291
  Caption = 'Form1'
  Color = clBtnFace
  Font.Charset = DEFAULT_CHARSET
  Font.Color = clWindowText
  Font.Height = -13
  Font.Name = 'MS Sans Serif'
  Font.Style = []
  Menu = MainMenu1
  OldCreateOrder = False
  OnResize = FormResize
  PixelsPerInch = 120
  TextHeight = 16
  object KillButton: TButton
    Left = 56
    Top = 32
    Width = 75
    Height = 25
    Caption = 'KillButton'
    TabOrder = 0
    OnClick = KillButtonClick
  end
  object MainMenu1: TMainMenu
    Top = 32
    object Menu1: TMenuItem
      Caption = 'Menu'
    end
    object SubMenu: TMenuItem
      Caption = 'SubMenu'
    end
  end
end

Zitat:

warum kein Delphi 10.2 Starter?

??? Ich arbeite nicht mit Delphi 10.

Ah, ich sehe das gibts kostenlos. Bisher war ich mit D7 glücklich.

Kann das Problem jemand reproduzieren oder tritt das nur bei mir auf?

[samso]

Wenn das nun so ein kurzes Testprogramm ist, könntest Du doch vielleicht das komplette Projekt hier hochladen. Dann brauchen wir das nicht per Copy&Paste neu anzulegen

[LTE5]

Zitat:

Ich arbeite nicht mit Delphi 10.

Ich hoffe du denkst nicht...
Delphi 7, Delphi 8, Delphi 9, Delphi 10. So ist nicht ;)

[Delphi.Narium]

Zitat:

Zitat von LTE5 (Beitrag 1389098)

Zweite Frage
warum kein Delphi 10.2 Starter?

Warum immer diese Frage? Kann man nicht einfach mal akzeptieren, des jemand die Delphiversion nutzt, die er hat und mit der er entwickelt?

Zum Thema:

Die DFM passt nicht zur Unit.

In der DFM gibt es u. a.

Delphi-Quellcode:

  object MainMenu1: TMainMenu
    Top = 32
    object Menu1: TMenuItem // in der Unit heißt's nur Menu
      Caption = 'Menu'
    end
    object SubMenu: TMenuItem
      Caption = 'SubMenu'
    end

in der Unit aber

Delphi-Quellcode:

MainMenu1: TMainMenu;
Menu: TMenuItem; // nicht Menu1???
SubMenu: TMenuItem;

Da ist irgendwas kaputtgegangen, bei mir meckert der Kompiler das an.

[iphi]

Zitat:

könntest Du doch vielleicht das komplette Projekt hier hochladen.

Sorry, ich hatte noch nicht mitbekommen, dass das geht, Projektdateien anbei.

Zitat:

Da ist irgendwas kaputtgegangen, bei mir meckert der Kompiler das an.

Sorry, ja, ich hatte zwischen erstem und zweitem Post noch ein wenig rumexperimentiert, was man ändern darf und was nicht, daher hat das Form und der Code wohl nicht mehr zusammen gepasst.

[LTE5]

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.

[iphi]

Zitat:

Klingt also danach, dass du ein Anfänger bist.

Kein blutiger. Ich programmiere seit 40 Jahren Pascal und seit 15 Jahren Delphi 6 und 7. Habe auch beim Meister persönlich (Nikolaus Wirth) Vorlesungen genossen. Das ist aber nicht mein Beruf sondern ein Hobby.

Mit Delphi6 bzw 7 war ich bisher glücklich. Das ist schnell, bisher stabil und verfügbar. Und ich kanns bedienen. Ich bin übrigens beileibe nicht der einzige, der D6 bzw. D7 benutzt. Das gabs damals kostenlos als Zeitungsbeilage.

P.S.
Ein Anfänger hätte den Fehler sicher nicht in 10MB Quellcode mit Multithreading und dynamischen dlls isolieren können!

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