Die unerklärliche AV

[Delbor]

Hi zusammen

Soeben habe ich meinem Projekt eine weitere Listbox hinzugefügt, um darauf Ausgaben über den Codeverlauf zu machen. Delphis Reaktion:

Zitat:

---------------------------
Im Projekt PDFOfficerProject.exe ist eine Exception der Klasse $C0000005 mit der Meldung 'access violation at 0x0063f592: read of address 0x000002a0' aufgetreten.
---------------------------

Klar, das angesprochene Objekt, die soeben aus der Toolbox eingefüge Listbox2, ist nil. Deren Parents sind schon länger Teil des Projektes. Tönt so, als hätte Delphi ein Burnout...
Der Code, in der die AV ausgelöst wird:

Delphi-Quellcode:

begin  
  Node := TVPathExplorer.Items.AddChild(ParentNode, aCaption);
  PDFOfficerMain.ListBox1.Items.Add('aRealName := ' + aRealName);   //Listbox1 funkttioniert schon länger
  PDFOfficerMain.ListBox1.Items.Add('aCaption := ' + aCaption);
  BCaption := ExtractFileExt(aCaption);
  PDFOfficerMain.ListBox1.Items.Add('ExtractFileExt := '+ BCaption);
  Application.ProcessMessages; 
  if CanGetChildren then
  begin
    FDefaultdraw := False;
    FIsDirectory := True;
    Node.ImageIndex := 1;
    Node.SelectedIndex := 1;
    (* Dummy-Knoten anlegen *)
    TVPathExplorer.Items.AddChild(Node, 'dummy');
    PDFOfficerMain.ListBox2.Items.Add('procedure TPathFinderFrame.AddNewNode');   /Listbox2 ist nil
    PDFOfficerMain.ListBox2.Items.Add('CanGetChildren := True');
    PDFOfficerMain.ListBox2.Items.Add('');
  end

Beide Listboxen wurden aus dem OI heraus gesetzt. Was ist da los?

Gruss
Delbor

[Delbor]

Hi zusammen

Aktionen von mir:

• Löschen der ominösen Listbox2
• Delphi neu starten
• Effekt := 0

Weiter:

• Löschen der ominösen Listbox2
• Listbox1 auschneiden und an der Stelle der ehemaligen Listbox2 einfügen
• Effekt: AV beim ansprechen von Listbox1 (NIL)

Der Anhang zeigt meine Strukturen der Gui.

Gruss
Delbor

[himitsu]

Was hindert dich daran, mal im Debugger in der Codezeile zur Exception nachzusehn ob da irgendwo das böse NIL zu sehen ist?
[edit] grade das fast versteckte

Delphi-Quellcode:

/Listbox2 ist nil

entdeckt.

Heißt nur die Varaible/Feld so in der PDFOfficerMain, aber in der DFM/OI heißt die Komponente anders?

Oder wurde Listbox2 zur Programmlaufzeit umbenannt oder vielleicht doch freigegeben?

[Luckie]

Du verwendest nicht zufällig eine with do begin Konstruktion irgendwo?

[Delbor]

Hi zusammen

Vielen Dank für eure Antworten!

Zitat:

Zitat von himitsu (Beitrag 1393460)

Heißt nur die Varaible/Feld so in der PDFOfficerMain, aber in der DFM/OI heißt die Komponente anders?

Zumindest im OI heisst sie so, und demnach wohl auch in der DFM - denn da kommen dieDaten der Strukturansicht wohl her.

Zitat:

Zitat von himitsu (Beitrag 1393460)

Oder wurde Listbox2 zur Programmlaufzeit umbenannt oder vielleicht doch freigegeben?

Nein, wurde sie nicht.

@Luckie: Hab ich mir schon vor längerem abgewöhnt...

Aber nach dem Mittagsschläfchen (um vier Uhr :-D ) fiel mir ein, was ich nicht gecheckt habe: nämlich enabled des Parentpanels. Ich mag mich nebulös erinnern, dass ichs schon mal geschafft habe, sowas unbeabsichtigt zu ändern.

...
Soeben nachgeholt - das Ergebnis seht ihr im Anhang...

Grrr....Seit wann kann Delphi denn ein Burnout haben???

Gruss
Delbor

[Stevie]

Hast du möglicherweise Lokalisierungen die nicht aktualisiert wurden? Da stecken auch die dfm resourcen drin und wenn da noch nicht die ListBox2 drin ist, wird sie beim dfm streamen nicht erstellt und demnach bleibt das ListBox2 Feld nil.

[Delphi.Narium]

Im Screenshot zu Post 2 ist ListBox2 nicht enthalten, sie soll aber doch auch auf Panel7 liegen?

Enabled sollte eigentlich keinen Auswirkungen auf die Zugriffsmöglichkeiten im Programmcode haben, enabled wirkt sich nur auf die Bedienbarkeit durch den Anwender aus.

Irgendwo muss es die ListBox2 geben, sonst würde der Compiler meckern.
Das eine auf 'nem Formular liegende Komponente Nil ist, ist eher ungewöhnlich.

Könnten wir bitte mal die DFM und die PAS vollständig zu gesicht bekommen. Da muss irgendwo was ungewöhnliches passieren, das man ohne den vollständigen Quelltext höchstwahrscheinlich nicht finden kann.

Alternativ:

Ist irgendwo unterhalb von

Delphi-Quellcode:

type TPDFOfficerMain = class(TForm)

die ListBox2 zu finden?
Wenn ja, ist sie auch in der DFM zu finden?
Wenn sie in der DFM fehlen sollte, wird sie nicht automatisch erstellt und bleibt daher Nil.

[himitsu]

Zitat:

Zitat von Delphi.Narium (Beitrag 1393477)

Irgendwo muss es die ListBox2 geben, sonst würde der Compiler meckern.

Nein, da es das Feld gibt, meckert der Compiler nicht.
Aber in dem Feld ist einfach keine Referenz gespeichert.

Die VCL/FMX setzen in ihrem Owner die gleichnamige Variable, die so wie sie heißt.
Alle Komponenten im Formdesigner haben die Form als Owner.

Wie sieht die Definition von PDFOfficerMain aus?
Das Feld "Listbox2" muß natürlich published sein, sonst geht das automatische Setzen nicht.

[Delbor]

Hi zusammen

@Delphi.Narium: Die Strukturansicht in Post2 zeigt die Situation, nachdem ich Listbox2 entfernt hatte und durch Listbox1 ersetzt hatte - und prompt war es dann auch diese, die in dieser Konstellation die AV auslöste.

Im Anhang nun mal einige jpeg- und pas-Dateien mit der kompletten DFM, bzw Formularansichten zur Lauf- und Designtime. Aussserdem ist eine kleinere pas dabei, die nur die aktuelle AddNewNode-prozedure zeigt, die einige auskommentierte Zeilen enthält, die von meinen Versuchen stammen.

Gruss
Delbor

[Delbor]

Hi zusammen

Zitat:

Zitat von himitsu (Beitrag 1393483)

Zitat:

Zitat von Delphi.Narium (Beitrag 1393477)

Irgendwo muss es die ListBox2 geben, sonst würde der Compiler meckern.

Nein, da es das Feld gibt, meckert der Compiler nicht.
Aber in dem Feld ist einfach keine Referenz gespeichert.

Die VCL/FMX setzen in ihrem Owner die gleichnamige Variable, die so wie sie heißt.
Alle Komponenten im Formdesigner haben die Form als Owner.

Wie sieht die Definition von PDFOfficerMain aus?
Das Feld "Listbox2" muß natürlich published sein, sonst geht das automatische Setzen nicht.

Ein ausschnitt aus der Mainform-Deklaration:

Delphi-Quellcode:

type
  TPDFOfficerMain = class(TForm)
    PnlToolBox: TPanel;
    CategoryPanelGroup1: TCategoryPanelGroup;
 ...
    Panel7: TPanel;
    ListBox1: TListBox;
    ListBox2: TListBox;
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
    procedure TVNameMouseUp(Sender: TObject; Button: TMouseButton;
      Shift: TShiftState; X, Y: Integer);

Ansonsten findet sich die komplette pas im Anhang meines letzten posts.

Gruss
Delbor

[Delbor]

Hi Stvie

Zitat:

Zitat von Stevie (Beitrag 1393476)

Hast du möglicherweise Lokalisierungen die nicht aktualisiert wurden? Da stecken auch die dfm resourcen drin und wenn da noch nicht die ListBox2 drin ist, wird sie beim dfm streamen nicht erstellt und demnach bleibt das ListBox2 Feld nil.

Bezüglich Lokalisierung hab ich noch nichts unternommen. Damit gelten also die Defaulteinstellungen meines Systems.
Das Programm selbst ist zur Zeit eher eine Testanwendung, die in einem weiteren Schritt um eine SQLite-DB ergänzt werden soll. Hauptziel: Effizientes organisieren meiner eigenen Dokumente.

Gruss
Delbor

[himitsu]

Zitat:

Zitat von Delbor (Beitrag 1393487)

Ansonsten findet sich die komplette pas im Anhang meines letzten posts.

"Komplett" war früher auch mal mehr. :roll:

Das Problem scheint doch vermutlich schon vorher zu existieren und da fehlt gleich mal Alles.

Delphi-Quellcode:

Assert(Assinged(PDFOfficerMain));
Assert(Assinged(PDFOfficerMain.ListBox1));
Assert(Assinged(PDFOfficerMain.ListBox2));

Direkt an den Anfang von TPathFinderFrame.AddNewNode und auch nach dem

Delphi-Quellcode:

Application.ProcessMessages;

, zu dem ich jetzt besser mal nix sage.

[Delbor]

Hi himitsu

Zitat:

"Komplett" war früher auch mal mehr.

Ufff!! Sorry, mein Fehler! Ich hab da zwar eine Note++-Datei angelegt, aber nicht hochgeladen :?
Ich hab mal nur die Pathfinder-Unit angehängt, da hier die Listbox2 angesprochen wird.

Gruss
Delbor

[hoika]

Hallo,
wir brauchen auch die Main-Pas und -Dfm.
Am besten das ganze Projekt.

Und markier mal die Stelle, wo es knallt.

[Delbor]

Hi zusammen
Das Projekt erfordert allerdings etwas Zusatzaufwand, da die Vorrausetzungen für einen Zip-Upload nicht so ohne weiteres einzuhalten waren.
Das Projekt erwartet:
Die PDFium-DLL von Google(freeware), die in den Debug-Ordner kopiert werden muss oder da, wo die Exe erstellt wird.
Die TFilesearcher-Komponente von DeddyH, die ich hier ebenso beilege. Diese benötigt eine Zusatzdatei DDFileUtils, die enthalten ist und sich meiner erfahrung nach im Projekteverzeichnis befinden sollte, ohne aber explizit dem Projekte hinzugefügt zu werden.

Gruss
Delbor

[Delbor]

Hi zusammen

Wie ich gesehen habe, wurden meine Zips schon mal heruntergeladen. Da es hier dazu bislang noch keinen Kommentar gab, befürchte ich, dass auf anderen Rechnern dieseAV nicht auftritt. Oder irre ich mich da?

Gruss
Delbor

[himitsu]

LOL :stupid:

Irgendwer kommt auf die geniale Idee im Create des Frame auf die globale Variable der Form zuzugreifen, die gerade eben erstellt wird und dann wundert er sich, dass Komponenten, die erst nach dem Frame erstellt werden, noch nicht existieren, da sie noch nicht erstellt wurden.

Verschiebe diesen Code in eine Methode und rufe sie im OnCreate der Form aus, nachdem alles erstellt wurde.




ODER: Trenne alle globalen Abhängigkeiten auf.

Erstmal solltest du lernen, dass man diese Variablen besser nicht verwenden sollte.
Stattdessen sollte dein Frame (deine Komponente) ein Property für diese Listboxen bekommen, mit denen er arbeiten soll.
Wenn der Frame registriert wird und RegisterComponent und als "Komponente" auf der Form liegt, dann bekommst du auch diese Property im OI angeboten.

Als Nebeneffekt sind die einzelnen Komponenten voneinander unabhängig, können ausgetauscht oder auch in anderen Programmen wiederverwendet werden.

[Delbor]

Hi Himitsu

Du sprichst von dieser Prozedur:

Delphi-Quellcode:

procedure TPathFinderFrame.AddNewNode(ParentNode: TTreeNode; const aCaption,
  aRealName: string; CanGetChildren: Boolean);
var
  Node: TTreeNode;  NodeRect: TRect;
  NameRec: PNameRec; DefaultDraw: Boolean;BCaption : String;
begin  
  Node := TVPathExplorer.Items.AddChild(ParentNode, aCaption);
  PDFOfficerMain.ListBox1.Items.Add('aRealName := ' + aRealName); // Hier wird Listbox1 auf 
  PDFOfficerMain.ListBox1.Items.Add('aCaption := ' + aCaption);         // der Mainform ausgefüllt.
  BCaption := ExtractFileExt(aCaption);                                                     // Und zwar mit sen hier angegbenen drei 
  PDFOfficerMain.ListBox1.Items.Add('ExtractFileExt := '+ BCaption);  // Zeilen, die für jedes der 13 Laufwerke je einmal
  Application.ProcessMessages; 
  if CanGetChildren then        // Boolean-Wert für Isdirectory aus dem TSearchanalizer(TFilesearcher)
  begin
    FDefaultdraw := False;
    FIsDirectory := True;
    Node.ImageIndex := 1;
    Node.SelectedIndex := 1;
    (* Dummy-Knoten anlegen *)                      
    TVPathExplorer.Items.AddChild(Node, 'dummy');
//    PDFOfficerMain.ListBox2.Items.Add('procedure TPathFinderFrame.AddNewNode');      // Hier die AV: Listbox2 ist Bil, obwohl sie sich auf der Form befindet
//    PDFOfficerMain.ListBox2.Items.Add('CanGetChildren := True');
//    PDFOfficerMain.ListBox2.Items.Add('');
  end
  else
  begin
    if BCaption = FFilter then                 //  Boolean
    begin
....

Jetzt brauch ich aber ganz schnell ein recht tiefes Mausloch, in das ich mich verkriechen kann!!

Da hab ich erst grade in einem andern Thread geschrieben, dass der Constructor des Frames vor demjenigen der Form abläuft, weil in dieser eine Frameinstanz angelegt werden soll - und jetzt dies! Natürlich läuft die Prozedur AddNewNodes zum ersten mal vor dem Form-Constructor ab und ebenso natürlich gibt es zu dieser Zeit keine Listbox2.

Das Problem ist nur - es gibt zu diesem Zeitpunkt auch keine Listbox1. Die aber wird anstandslos gefüllt, ob es sie nun schon gibt oder nicht! Und das dürfte auch nicht sein!?
Im Constructor des Frames gibt es keinen Zugriff auf die Main- oder irgendeine andere Form.

Delphi-Quellcode:

constructor TPathFinderFrame.Create(AOwner: TComponent);
  var RGindex, L: integer; Drive, D: string;
      Drives: TStringlist;
begin
  inherited;
  FDefaultDraw := False;
  Drives := TStringlist.Create;
  try                                                                  
    TDrives.ListDrivesAndNames(Drives);
    FReportlist := TStringlist.Create;
    FReportlist.Add('----');
    for Drive in Drives do
    begin
      D := Copy(Drive, 1, 3);
      AddNewNode(nil, Drive, Copy(Drive, 1, 3), true);       //AddNew wird hier aufgerufen, bevor die Form crestet wird.
      FReportlist.Add(D);
    end;
  finally
    FreeAndNil(Drives);
  end;
  FReportlist.Add('----');
  PathFinder1.SearchType := stBoth;
  FileMaskInit;
  
  FPathlist := TStringlist.Create;
  FNodeList := TStringlist.Create;
  FNodeList.Sorted := False;
  RGindex := 0;
end;

Also: Zu dem Zeitpunkt, da der Frame createt wird:

• gibt es noch keine Mainform.
• Also gibt es weder Listbox1 noch Listbox2
• Der Constructor des Frames greift aber via aufruf von AddNewNode indirekt auf auf beide zu.
• Wesshalb erzeugt nur der Zugriff auf die noch nicht vorhandenen Listbox2 eine AV, nicht aber der auf die ebenfalls noch nicht vorhandene Listbox1?

Gruss
Delbor

PS:

Zitat:

Irgendwer kommt auf die geniale Idee im Create des Frame auf die globale Variable der Form zuzugreifen,

Das muss dieser ominöse Fehler sein, der da vor meinem Bildschirm sitzt... :x

[himitsu]

Bei Frames gibt es halt zwei Varianten,

entweder als Frame, der durch die IDE verwaltet wird. (wie hier)

• Da wird es schwer, dass die Daten "automatisch" rein bekommen,
  abgesehn davon der Code wird in Methoden gelegt, die manuell vom Programm aufgerufen werden.
  > statt im eigenen Contructor dann im Contructor der Form aufgerufen
• Property des Frame sind im OI nicht nutzbar, da die IDE für solche Frames, Forms und Datenmodule eine "Dummy"-Kompoente im Formdesigner nutzen. (und da eben nur die bekannten Grundtypen, wie TFrame).
  Das Selbe gilt auch für Vererbung diesen Modulen, so lange die Vorfahren nicht in der IDE registriert werden.
• aber dafür gibt es auch keine Abhängigkeit zur IDE

oder man behandelt den Frame als Komponente

• hier muß man diesen Frame aber in der IDE registrieren/installieren, also erstmal in ein Laufzeitpackage stecken
• aber dafür kennt die IDE dann diese Klasse und kann auch ihre Property und Property-/Component-Helper verwenden

Was ich schon immer vermisst habe.
Es gibt das

Delphi-Quellcode:

TComponent.Loaded

-Ereignis, welches nach dem Erstellen und Laden aller Property via DFM ausgeführt wird.
Es gibt aber leider kein Ereignis für "Form fertig geladen", so wie z.B. csDestroying, wo alle Sub-Komponenten erstmal diesen Status bekommen, bevor auch nur eine Komponente freigegeben wird.
Ein AfterModulCreate und BeforeModulDestroy in TComponent (TForm/TFrame/TDataModule) wäre toll.