Fehlermeldung unerklärlich

[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
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]

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

Zitat:

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

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.