Fehlermeldung unerklärlich

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