Fehlermeldung unerklärlich

[Naryxus]

Hallo, ich habe ein größeres Problem bei dem ich einfach keine Lösung finde.
Erst mal allgemein: Ich habe...

• eine ListView mit verschiedenen Elementen
• eine Groupbox, die noch leer ist

Bei Klick auf ein Element der ListView (gelöst durch das Event "OnClick") soll genau dieses Element in der Groupbox als Label angezeigt werden (also die Caption des Elements). Dies habe ich durch folgende Prozedur gelöst:

Delphi-Quellcode:

procedure TForm1.ListView1Click(Sender: TObject);
var MyLabel:TLabel;
var labelname:string;
begin
  if(form1.ListView1.ItemFocused.Caption<>'') then //Prüfung ob ein Element angeklickt wurde
  begin
    MyLabel:=TLabel.Create(Form1);
    with MyLabel do begin
      Caption:=form1.Listview1.ItemFocused.Caption;
      labelname:=form1.Listview1.ItemFocused.Caption;
      Delete(labelname, 2, 1); //Bearbeitung der Caption für den Namen, da Sondezeichen enthalten
      name:='Label'+labelname;
      left:=10;
      top:=labelvar*20; //globale Variable, um die Labels untereinander anzuzeigen
      visible:=true;
      parent:=groupbox3;
      onClick:=loesche; //Prozedur, zu der ich noch komme
    end;
    labelvar:=labelvar+1;
    form1.ListView1.ItemFocused.Delete;
  end
end;

Mit dieser Prozedur wird also ein Label mit der Caption des Elements erzeugt und das Element selbst in der ListView gelöscht. Soweit funktioniert auch alles.

Probleme gibts jetzt aber bei der Prozedur zum Löschen der Labels. Allgemein soll die Prozedur beim Klicken auf das Label das Element der ListView wieder hinzugefügt werden und das Label wieder gelöscht werden. Das läuft durch folgende Prozedur:

Delphi-Quellcode:

procedure TForm1.loesche (Sender: TObject);
var fahrzeug, listenfahrzeug:string;
var listitem:TListItem;
var fahrzeugliste:array[0..5] of integer;
var i:integer;
begin
  fahrzeug:=(Sender as TLabel).Caption; //Caption des angeklickten Labels herausfinden
  listitem:=form1.ListView1.Items.Add; //Hinzufügen des Elements in die ListView
  listitem.Caption:=fahrzeug; //Caption des Labels als Caption des neuen Elements
  for i:=1 to form1.ListView1.Items.Count do begin   //Im folgenden Block werden alle Elemente der ListView in einem Array gespeichert
    listenfahrzeug:=form1.ListView1.TopItem.Caption;
    delete(listenfahrzeug, 1, 2);
    fahrzeugliste[i]:=strtoint(listenfahrzeug);
    form1.Edit12.Text:=form1.Edit12.Text+listenfahrzeug+', ';
    form1.listview1.topitem.Delete;
  end;
  for x:=2 to i-1 do begin //Hier wird das Array dann sortiert von klein nach groß
    z:=fahrzeugliste[x];
    y:=x;
    while(y>1) and (fahrzeugliste[y-1]>z) do begin
      fahrzeugliste[y]:=fahrzeugliste[y-1];
      dec(y);
    end;
    fahrzeugliste[y]:=z;
  end;
  for x:=1 to i-1 do begin //Hier wird dann das geordnete Array wieder in die ListView eingefügt
    listitem:=form1.ListView1.Items.Add;
    listitem.Caption:='1/'+inttostr(fahrzeugliste[x]);
  end;
  (Sender as TLabel).Destroy; //Zuletzt wird dann das angeklickte Label wieder gelöscht
end;

Die Prozedur funktioniert an sich auch wunderbar, die ListView wird sortiert und richtig angezeigt.
Folgende Situationen habe ich durchgespielt:

• ein Label wird gelöscht (funktioniert)
• zwei Labels werden der Groupbox hinzugefügt und dann jeweils wieder gelöscht (funktioniert)

So weit, so gut. Füge ich jetzt aber drei Elemente der Groupbox hinzu, entstehen folgende Situationen:

1. Löschen des ersten Labels (funktioniert)
2. Anschließendes Anklicken des zweiten Labels (funktioniert nicht)
   Anhang 35294
3. Anschließendes Anklicken des dritten Labels (funktioniert nicht)
   Anhang 35295

Genauso setzt sich das dann auch bei mehreren Elementen fort. Genauso auch, wenn man das erste Label nicht löscht, sondern gleich das zweite, dritte oder vierte Label anklickt.
Ich habe schon vermutet, dass es sich um irgendein Problem mit dem Namen des Labels handelt, wenn man mehr als ein Label erstellt. Allerdings müsste man dann noch die Anomalie bei zwei Labels erklären, dort funktioniert es nämlich, egal in welcher Reihenfolge man diese Labels anklickt, sie werden gelöscht und der ListView hinzugefügt.

Ich hoffe, ich konnte mein Problem einigermaßen klar darstellen und hoffe auf eure Hilfe,

mit freundlichen Grüßen, Naryxus

[Alaitoc]

Nun ich gehe einfach mal davon aus das du per OnClick auf das Label, dass Label löscht?
Edit: Gerade gesehen das du das wirklich tust. Daher solltest du das anders lösen, am Besten indem
du das Element vormerkst für die Freigabe und es dann erst freigegeben wird sobald der Zugriff nicht mehr vorhanden ist.
Da gibt es mehrere Möglichkeiten.

Das Problem ist, wenn ein Objekt per Event sich selbst löschen will...dann gibt es Zugriffsverletzungen weil
du versuchst etwas freizugeben obwohl du noch innerhalb des Events auf das Label zugreifst.

Außerdem bitte FreeAndNil() benutzen anstatt Destroy() und auch Überprüfen ob das Element überhaupt existiert mit Assigned().

MfG Alaitoc

Edit: Willkommen in der Delphi-Praixs! :)

[Union]

Damit hat das nichts zu tun. Sondern eher hiermit:

Delphi-Quellcode:

for i:=1 to form1.ListView1.Items.Count do begin

Bitte prüfe diese Schleife. Und debugge im Einzelschritt.

[stahli]

Erst einmal herzlich willkommen.

Es ist etwas schwierig, die Abschnitte schnell zu durchblicken.
Mal ein paar Hinweise:

- Die Schleifen müssen ggf. von 0 bis Count-1 laufen.
- Du musst nicht vor jeden Variable "var" deklarieren.
- Du musst in einer Methode von Form1 nicht noch einmal "Form1."MyComponent schreiben.
- "(Sender as TLabel)" kannst Du auch einmalig einer Variable UseLabel zuweisen und damit arbeiten (das liest sich oft besser).
- Setze einen Haltepunkt und arbeite den Quelltext schrittweise ab (incl. Nutzung der überwachten Ausdrücke)

Dann solltest Du auf dem richtigen Weg sein.

[Alaitoc]

Sollte es da nicht auch zu Problemen kommen wenn ein Objekt sich selbst zerstört...? :/
Auch wenn es hier wirklich grad an was anderem liegt...:oops:

MfG Alaitoc

[Naryxus]

Danke erst einmal für die schnellen Antworten.

Zitat:

Das Problem ist, wenn ein Objekt per Event sich selbst löschen will...dann gibt es Zugriffsverletzungen weil
du versuchst etwas freizugeben obwohl du noch innerhalb des Events auf das Label zugreifst.

Scheint für mich logisch, allerdings frage ich mich dann, warum das dann bei einem oder zwei Labels funktioniert, aber dann bei mehreren nicht mehr.

Zitat:

Damit hat das nichts zu tun. Sondern eher hiermit:
for i:=1 to form1.ListView1.Items.Count do begin Bitte prüfe diese Schleife. Und debugge im Einzelschritt.

Die Sache ist ja die, dass die Schleife eigentlich gar nichts mit der Löschung des Labels zu tun hat. Sie dient ja letztendlich nur zur Sortierung der ListView. Ich habe mal den kompletten Array-Sortierungsbereich auskommentiert und das Problem tritt immer noch auf.

[Alaitoc]

Zitat:

- Setze einen Haltepunkt und arbeite den Quelltext schrittweise ab (incl. Nutzung der überwachten Ausdrücke)

Ist wahrscheinlich der beste Tipp um dem Problem auf die Spur zu kommen. Geh einfach mal mit dem Debugger jeden einzelnen Punkt durch. Dann sollte sich schnell der Fehler herauskristalisieren.

MfG Alaitoc

[Union]

Am Label-Löschen liegt es nicht. Folgender Source funktioniert:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  MyLabel : TLabel;
  LabelName : string;
begin
  MyLabel:=TLabel.Create(Form1);
  with MyLabel do begin
    Caption:= DateTimeToStr(Now);
    labelname:= 'Label'+IntToStr(labelvar);
    Delete(labelname, 2, 1); //Bearbeitung der Caption für den Namen, da Sondezeichen enthalten
    name:='Label'+labelname;
    left:=10;
    top:=labelvar*20; //globale Variable, um die Labels untereinander anzuzeigen
    visible:=true;
    parent:=Form1;
    onClick:=loesche; //Prozedur, zu der ich noch komme
  end;
  labelvar:=labelvar+1;
end;

procedure TForm1.Loesche(Sender: TObject);
begin
  (Sender as TLabel).Destroy; //Zuletzt wird dann das angeklickte Label wieder gelöscht
end;

Bitte nimm doch den Vorschlag an, im Einzelschritt zu debuggen. Programmierer die nicht debuggen kommen in die Hölle (Steve McConnell)

[DeddyH]

Bitte nicht Destroy direkt aufrufen, sondern stattdessen Free verwenden. Aber das nur am Rande.

[stahli]

Zitat:

Zitat von Alaitoc (Beitrag 1127712)

Sollte es da nicht auch zu Problemen kommen wenn ein Objekt sich selbst zerstört...? :/
Auch wenn es hier wirklich grad an was anderem liegt...:oops:
MfG Alaitoc

Das muss nicht unbedingt problematisch sein. Zum Zeitpunkt der Click-Behandlung existiert das Objekt ja noch.
Nun wird es in der Click-Behandlung freigeben. Wenn darauf danach nicht mehr (innerhalb des Objektes und außerhalb darauf zugegriffen wird), macht das keine Probleme.
Und selbst wenn noch ein Zugriff auf die Speicherstelle erfolgt, liegen dort noch die bisherigen Objektdaten.
Ob es ein Problem gibt hängt dann letztlich von der genauen Implementierung ab.

Zitat:

Zitat von Naryxus (Beitrag 1127713)

Die Sache ist ja die, dass die Schleife eigentlich gar nichts mit der Löschung des Labels zu tun hat. Sie dient ja letztendlich nur zur Sortierung der ListView. Ich habe mal den kompletten Array-Sortierungsbereich auskommentiert und das Problem tritt immer noch auf.

Geh ein Problem nach dem anderen an und debugge schrittweise.

[Naryxus]

Ok, ich bin jetzt mal alles durchgegangen.

Komischerweise stockt er, wenn es zu Problemen kommt nicht in der Datei *.pas sondern in der Project-Datei *.dpr. Und zwar in der letzten Zeile bei "end.". So etwas hatte ich noch nie...
Vor allem verstehe ich immer noch nicht, wieso es bei einmaligen und beim zweimaligen Aufrufen der Löschen-Prozedur einwandfrei läuft, es aber dann, sobald drei Labels erstellt wurden stockt. Vor allem kann man das schlecht debuggen, da der Fehler ja nur auftritt, wenn man im laufenden Programm eine bestimmte Abfolge an Befehlen tätigt.

[Union]

Zitat:

Vor allem kann man das schlecht debuggen, da der Fehler ja nur auftritt, wenn man im laufenden Programm eine bestimmte Abfolge an Befehlen tätigt.

Dann setze Haltepunkte am Beginn des zu prüfenden Abschnitts.

[stahli]

Zitat:

Zitat von Naryxus (Beitrag 1127722)

Ok, ich bin jetzt mal alles durchgegangen.

Komischerweise stockt er, wenn es zu Problemen kommt nicht in der Datei *.pas sondern in der Project-Datei *.dpr. Und zwar in der letzten Zeile bei "end.". So etwas hatte ich noch nie...
Vor allem verstehe ich immer noch nicht, wieso es bei einmaligen und beim zweimaligen Aufrufen der Löschen-Prozedur einwandfrei läuft, es aber dann, sobald drei Labels erstellt wurden stockt. Vor allem kann man das schlecht debuggen, da der Fehler ja nur auftritt, wenn man im laufenden Programm eine bestimmte Abfolge an Befehlen tätigt.

In den Haltepunkteigenschaften kannst Du auch Bedingen definieren. Du kannst also dafür sorgen, dass die Unterbrechung nur in bestimmten Situationen erfolgt.

Dein Problem (wenn ich es richtig interpretiere) kenne ich beim Löschen eines Controls, das den Focus hat. Windows will dieses später noch einmal neu zeichnen, dann existiert es aber nicht mehr.
Ich habe dies gelöst, indem ich das Control erst einmal unsichtbar mache und später lösche. Vielleicht kommst Du auf diesem Weg etwas weiter (wobei ja ein Label durch anklicken nicht den Focus erhält!?)

[Jumpy]

Auch wenn es ja angeblich nicht daran liegt. Ist nicht die ganze sortiererei mit array usw. unnötig. Gibt doch z.B. CustomSort.

[Luckie]

Zitat:

Zitat von Jumpy (Beitrag 1127741)

Auch wenn es ja angeblich nicht daran liegt. Ist nicht die ganze sortiererei mit array usw. unnötig. Gibt doch z.B. CustomSort.

Na ja, am Fehler wird es wohl nichts ändern, aber je übersichtlicher der Code, desto einfacher die Fehlersuche.

[CCRDude]

Noch etwas, das mir problematisch vorkommt: Du legst das Label mit Form1 als Owner an, zerstörst es dann aber selber. Aber wo informierst Du Form1, daß es sich jetzt nicht mehr um das Label kümmern soll?

[stahli]

Zitat:

Zitat von CCRDude (Beitrag 1127759)

Noch etwas, das mir problematisch vorkommt: Du legst das Label mit Form1 als Owner an, zerstörst es dann aber selber. Aber wo informierst Du Form1, daß es sich jetzt nicht mehr um das Label kümmern soll?

Das erfolgt bei Ableitungen von TComponent automatisch:

Delphi-Quellcode:

constructor TComponent.Create(AOwner: TComponent);
begin
  FComponentStyle := [csInheritable];
  if AOwner <> nil then AOwner.InsertComponent(Self);
end;

destructor TComponent.Destroy;
begin
  Destroying;
  RemoveFreeNotifications;
  DestroyComponents;
  if FOwner <> nil then FOwner.RemoveComponent(Self);
  inherited Destroy;
end;

[CCRDude]

Zitat:

Zitat von stahli (Beitrag 1127762)

Das erfolgt bei Ableitungen von TComponent automatisch

Oh, danke schön, wieder was dazugelernt, dann ziehe ich meinen Einwand zurück :)

[DeddyH]

Ganz unberechtigt war der Einwand aber nicht.

[himitsu]

Zitat:

Delphi-Quellcode:

if(form1.ListView1.ItemFocused.Caption<>'') then //Prüfung ob ein Element angeklickt wurde

Und was ist, wenn keine Items in der ListView sind oder wenn keines fokusiert ist?

Genau, dann ist ItemFocused = NIL und der Zugriff auf Caption kann nur noch schief gehn.

[Naryxus]

Hallo und sorry, dass ich erst jetzt wieder antworte, hatte einiges um die Ohren.

Zitat:

In den Haltepunkteigenschaften kannst Du auch Bedingen definieren. Du kannst also dafür sorgen, dass die Unterbrechung nur in bestimmten Situationen erfolgt.

Ok, in die Haltepunkte muss ich mich erst noch einmal etwas reinarbeiten, da ich ehrlich gesagt noch nie größere Probleme mit Delphi-Programmen hatte, sodass ich auch nie großartig debuggen musste. Zu gegebener Zeit werde ich da dann mal Bericht erstatten.

Zitat:

Ist nicht die ganze sortiererei mit array usw. unnötig.

Wie gesagt, ich habe mal den ganzen Sortierungsblock auskommentiert und Problem hat weiterhin bestanden. Das Sortieren dient ja letztendlich auch nur dem Komfort. Zufrieden wäre ich ja schon mal, wenn alle Labels, die erzeugt wurden und angeklickt wurden wieder verschwinden...
Aber ja, ihr habt Recht, zur besseren Übersicht sollte man das alles vereinfachen. Wo wir dann gleich dabei sind, heißt CustomSort, dass Delphi da etwas bereitstellt?

Zitat:

Noch etwas, das mir problematisch vorkommt: Du legst das Label mit Form1 als Owner an, zerstörst es dann aber selber. Aber wo informierst Du Form1, daß es sich jetzt nicht mehr um das Label kümmern soll?

Dazu habe ich mich ja auch schon geäußert. Rein theoretisch und logisch betrachtet finde ich den Einwand komplett nachvollziehbar, wenn dann nicht die Tatsache bestünde, dass das Programm mit ein, bzw. zwei erzeugten Labels fehlerfrei läuft.

Zitat:

Und was ist, wenn keine Items in der ListView sind oder wenn keines fokusiert ist?

Genau, dann ist ItemFocused = NIL und der Zugriff auf Caption kann nur noch schief gehn.

In der If-Abfrage wird geprüft, ob ein Item angeklickt wurde, ist dies der Fall, so wird das Label erstellt (wodurch dann auch erst die Möglichkeit zum Aufruf der Prozedur "Löschen" gegeben wird und deshalb auch, wenn die Prozedur aufgerufen werden kann auch eine Caption vorhanden sein muss), ist dies nicht der Fall, das heißt

Delphi-Quellcode:

ItemFocused.Caption==''

dann passiert rein gar nix, weil dann die Prozedur des ListView-Clicks beendet ist.

[Naryxus]

Jetzt scheine ich doch tatsächlich weitergekommen zu sein.
Ich glaube nun mich der Fehlerquelle langsam zu nähern und bin nun wirklich nochmal Schritt für Schritt die Prozedur "Löschen" durchgegangen. Und es scheint wohl an dem Befehl "FreeAndNil()" zu liegen.
Ich habe den jetzt mal auskommentiert, das Programm gestartet, drei Labels mal dynamisch erzeugt, das zweite Label dann mal angeklickt (was ja vorher dann schon zu dem Zusammenbruch führte) und siehe da, das Programm läuft weiter. Es fügt der ListView das angeklickte Label in Form eines Items hinzu und löscht das Label dann dementsprechend logischerweise nicht.
Trotz allem bin ich im Endeffekt doch überfragt, da ich mir nicht erklären kann, wo genau dann das Problem liegt und wie ich das dann lösen kann. Könnt ihr mir helfen? Ich würde jetzt mal grob tippen, dass da irgendwas mit dem Speicherplatz nicht richtig läuft, sobald ein drittes Label dynamisch erzeugt wird.

[stahli]

Delphi-Quellcode:

FreeAndNil(O);

macht folgendes:

Delphi-Quellcode:

O.Free;
O := nil;

Danach führt ein Zugriff auf O zu einem Fehler.
Wenn das Objekt sebst schon nicht mehr existierte, scheitert FreeAndNil schon selbst.

Benutze beim schrittweisen debuggen mal noch die überwachten Ausdrücke, um Deine Objekte zu untersuchen.

Wenn Du Deinen Quelltext mal aufgeräumt hast, kannst Du ihn ja nochmal zeigen. Vielleicht fällt jemandem dann noch etwas auf...

[Naryxus]

Hmmm... Ich habe es versucht jetzt mal anders zu lösen.
Und zwar wird gleichzeitig zum Erzeugen der Labels ein dynamisches Array mit erstellt, bzw. aktualisiert, welches dann die Namen der erzeugten Labels mitspeichert. Funktioniert auch so weit gut. In der Prozedur "Löschen" wird dann das jeweilige Array-Element wieder gelöscht und das dynamische Array so aktualisiert, dass keine Lücken durch das Löschen entstehen. Danach werden alle Controls der Groupbox gelöscht, da die Labels alle Childs von dieser Groupbox sind. Das funktioniert auch, sodass jetzt, auch wenn 3 Labels erzeugt wurden, alle gelöscht werden.
Ich habe mir jetzt gedacht, dass ich dann einfach am Ende der Prozedur für jedes Element in dem Array ein neues Label erstelle.
Allerdings sagt das Programm dann auch wieder "Gute Nacht", weil angeblich schon ein Element mit dem Namen XY existieren würde. Ich habe doch aber alle erzeugten Labels über die Eigenschaft "Controls" gelöscht. Oder bleiben da trotzdem die Labels bestehen? Ich habe dann auch schon mal getestet, ob nach dem Löschen der Labels noch ein Label exisitiert (mittels FindComponent) und das ergab dann auch keinen Treffer, also müsste es rein theoretisch gelöscht sein.

[DeddyH]

Setz doch einfach mal ReportMemoryLeaksOnShutdown auf true (je nach Delphi-Version schon eingebaut oder mittels Installation von FastMM nachrüstbar). Beim Beenden des Programms wird Dir dann schon angezeigt, ob da nicht freigegebene Labels existieren.

[edit]

Zitat:

Zitat von himitsu (Beitrag 1127802)

Zitat:

Delphi-Quellcode:

if(form1.ListView1.ItemFocused.Caption<>'') then //Prüfung ob ein Element angeklickt wurde

Und was ist, wenn keine Items in der ListView sind oder wenn keines fokusiert ist?

Genau, dann ist ItemFocused = NIL und der Zugriff auf Caption kann nur noch schief gehn.

Dieser Einwand ist richtig und wichtig und hat mit Deinen Labels nicht das Geringste zu tun. Besser so:

Delphi-Quellcode:

var 
  Item: TListItem;
begin
  Item := {form1. ist Quatsch, besser self. schreiben oder ganz weglassen}ListView1.ItemFocused;
  if Assigned(Item) then
    if Item.Caption <> '' then

Wenn kein Item fokussiert ist, gibt ItemFocused nil zurück. nil besitzt logischerweise keine Caption, ein Zugriff darauf verursacht also eine AV. [/edit]

[Jumpy]

Zitat:

Zitat von Naryxus (Beitrag 1127942)

Zitat:

Ist nicht die ganze sortiererei mit array usw. unnötig.

Wie gesagt, ich habe mal den ganzen Sortierungsblock auskommentiert und Problem hat weiterhin bestanden. Das Sortieren dient ja letztendlich auch nur dem Komfort. Zufrieden wäre ich ja schon mal, wenn alle Labels, die erzeugt wurden und angeklickt wurden wieder verschwinden...
Aber ja, ihr habt Recht, zur besseren Übersicht sollte man das alles vereinfachen. Wo wir dann gleich dabei sind, heißt CustomSort, dass Delphi da etwas bereitstellt?

Mit unnötig meinte ich eher umständlich, da ich die Hilfe so verstanden habe, dass sich Listen selber sortieren können. Ich hab es noch nie gemacht, aber es gibt wohl sowas wie ein "OnCompare"-Event, wo man eine Vergleichsfunktion ablegen kann, die dann angewendet wird, wenn zwei Listenelemente verglichen werden. CustomSort ist wiederum eine Methode(?) der Liste, die, wie ich das verstanden habe, genau diesen Vergleich nutzt, um die Liste zu sortieren.

Jemand der bereits damit gearbeitet hat möge mich bitte ggf. berichtigen.

[DeddyH]

Du meinst TList.Sort. Diese Methode nutzt tatsächlich intern einen Quicksort-Algorithmus, wobei die Vergleichsroutine dann selbst zu schreiben ist. Das steht in der Hilfe aber ganz gut beschrieben.