Access Violation durch Length(Array)?

[Bjoerk]

Zitat von Jumpy:

Hier mal wie das Array befüllt und geleert wird. Mag sein, dass die Remove-Methode noch etwas umständlich ist, die hab ich noch nicht überarbeitet, vllt. wird da auch das Array zerschossen?

Delphi-Quellcode:

procedure TTapiLine.AddCall(Call: TTapiCall);
begin
  SetLength(priv_Calls,High(priv_Calls)+2); // ***
  priv_Calls[High(priv_Calls)]:=Call;
end;

Wenn ich's noch recht in Erinnerung habe, liefert High für Length = 0 Minus Eins zurück.

[himitsu]

High = Length - 1
da dynamische Arrays immer bei Index 0 beginnen.

[Jumpy]

Edit: Fehler gefunden. Diesen Post gerne überspringen und unten weiterlesen!

Hallo und guten Morgen und danke für die Hilfe gestern.

Eine Nacht drüber geschlafen brachte immer noch keine Lösung.
Hab's so geändert, das bei AddCall nun eine globale Zählervariable hochgezählt wird, bei removeCall wird diese wieder runtergesetzt und die Funktion CallCount liest diese nun nur noch aus:

Delphi-Quellcode:

function TTapiLine.CallCount: integer;
begin
{  Result:=0;
  try
    Result:=Length(priv_Calls);
  except
  end;}
  Assert(Assigned(self));
  try
    Result:=priv_CallCount;
  except on e:exception do
    begin
    showmessage(IntToStr(priv_LineNumber));
    end;
  end;
end;

Trotzdem kommt noch der Fehler. Zudem kommt der dann nochmal bei dem showmessage (womit ich sehen wollte, welche Line den Fehler verursacht, was aber nicht klappt). Dies legt den Verdacht nahe, das shmia vllt. die richtige Idee hatte, aber das Assert macht nichts? In den Debug-Optionen ist es aktiviert (überlauf usw. sind deaktiviert).

Zum Fehler nochmal: Er tritt scheinbar immer nur 1 mal auf 2-5 Sekunden nach Programmstart, danach (hab's mal 30 min laufen lassen) nicht mehr.
Vllt. ist da wirklich am Anfang irgendeine "Geisterleitung" die mir hier in den Kram spukt. Das ganze Programm wird durch Tapi-Aufrufe einer Callback-Funktion gesteuert. Mag sein, dass diese schon zu früh mal feuert, wenn noch nicht alle Leitungen stehen oder so. Muss ich mal weiter experimentieren. Andere Ideen aber weiterhin willkommen

[Jumpy]

Den Fehler gefunden. Eine Callback-Funktion gibt immer den Handle des Calls weiter an eine Funktion, die den Callback Verarbeitet. Aus dem Handle wird der Handle der Line bestimmt, auf der der Call läuft und aus dem Linehandle wird der Index der Line im Array priv_Lines bestimmt.

Aber nun: Bei einer bestimmten Callback-Nahricht wird nicht der Handle des Calls, sondern der einer Line zurückgegeben. Die Funktion, die aus dem Call-Handle einen Line-Handle sucht wird daher natürlich nicht fündig und liefert 0 zurück.

Die Funktion, die aus dem LineHandle nun den Index sucht findet damit natürlich auch nix und liefert -1 zurück.

Dann wird auf priv_Lines[-1].CallCount zugegriffen (weil bisher der Test Index>=0 fehlt) und da knallt es. Keine Ahnung warum es da innerhalb der CallCount knallt und nicht in der Funktion in der die Zeile priv_Lines[-1].CallCount steht und wo doch ein Idndex out of Bounds oder so gemeldet werden müsste?

[himitsu]

Zitat von Jumpy:

Keine Ahnung warum es da innerhalb der CallCount knallt und nicht in der Funktion in der die Zeile

Das kommt eben immer drauf an, wie und auf was man zugreift.

Bei einem Array kann man locker vor den Ersten oder hinter den letzten eintrag zugreifen.
es kommt nur drauf an, was für einen Typ die Felder haben (Integer ist unproblematischer als z.B. String) und ob an der Stelle zufällig etwas anderes im Speicher liegt, so daß keine Zugriffsverletzung auftritt.

Bezüglich der Arrays kann man das ganz leicht prüfen lassen, indem man z.B. die Bereichsprüfung in den Projektoptionen aktiviert.

[Bjoerk]

Statt des Arrays würde ich eine TList verwenden.

[Jumpy]

Wenn ich schon Generics könnte würd ich das machen, aber ohne ist mir die ganze is/as-Casterei zu lästig (müsste bei meiner momentanen Coderenovierung zuviel anpacken).