TStringList erzeugt access violation...

[himitsu]

Zitat:

Zitat von user0815 (Beitrag 1236723)

Später habe ich dann auf einen Wert gegriffen den es nicht gibt - ABC[11] ...
Trotz allem erschien die Fehlermeldung bei der Stringlist, die aber in diesem Fall nichts damit zu tun hatte.

Schalte mal die Bereichtprüfung an. :stupid:

[Perlsau]

Meines Kenntnisstandes nach sollte man bei der Deklaration von Stringlisten statt SendeListe : TStringList; besser SendeListe : TStrings; schreiben. Weshalb?

TStrings ist lediglich die "Schnittstellenklasse" für eine Stringliste. Simon meint: "TStrings is a lesser 'contract' allowing greater flexibility for the developer. You can interact with any class that implements the TStrings abstract class." Auf deutsch: Mit der Deklaration als TStrings statt TStringList ist man flexibler, weil man so mit jeder von TStrings abgeleiteten Klasse interagieren kann. Deshalb sind auch die Stringlisten in Memos und Listboxen als TStrings deklariert, wobei intern natürlich eine abgeleitete Klasse arbeitet. Auf diese Weise kann man überhaupt erst die Stringliste einer Listbox, deren interner Abkömmling über zusätzliche Properties verfügt, einer selbsterzeugten Liste oder dem Abkömmling Memo.Lines zuweisen: TStrings sind immer mit ihren Abkömmlingen kompatibel. Oder wie es David Heffernan ausdrückt:

"However, if you had code that assigned a variety of different types of TStrings descendants to the variable, then it would make sense to declare it as TStrings."

[DeddyH]

Für eine rein intern genutzte Stringliste erschließt sich mir der Sinn nicht, zumal man dann ggf. bei jedem Zugriff auch noch casten muss, zumindest sobald man auf Properties/Methoden zugreift, die erst in TStringlist implementiert oder veröffentlicht sind.

[Perlsau]

Wieso muß man casten, wenn man die Liste als TStrings deklariert und als TStringList erzeugt?

[DeddyH]

Weil der Typ nunmal TStrings ist.

[edit] Einfaches Beispiel:

Delphi-Quellcode:

var
  Test: TStrings;
begin
  Test := TStringlist.Create;
  try
    Test.Sorted := true;  //Fehler, erst in TStringlist implementiert
    (Test as TStringlist).Sorted := true; //OK
    TStringlist(Test).Sorted := true;  //auch OK
  finally
    Test.Free;
  end;
end;

[/edit]

[mkinzler]

Zitat:

Wieso muß man casten, wenn man die Liste als TStrings deklariert und als TStringList erzeugt?

Z.B. sind sonst Eigenschaften/Methoden nicht verfügrbar, welche durch TStringList hinzugefügt wurden.

[DeddyH]

As I said before :mrgreen:

[mkinzler]

Zitat:

Zitat von DeddyH (Beitrag 1236749)

As I said before :mrgreen:

Was aber mal wieder überlesen wurde.

Ich sollte zitieren, auf was ich mich beziehe. ( Mache ich gleich im Beitrag oben)

[Perlsau]

Zitat:

Zitat von mkinzler (Beitrag 1236748)

Zitat:

Wieso muß man casten, wenn man die Liste als TStrings deklariert und als TStringList erzeugt?

Z.B. sind sonst Eigenschaften/Methoden nicht verfügrbar, welche durch TStringList hinzugefügt wurden.

Also wurde ich von den oben genannten Quellen falsch informiert. Gut zu wissen. Danke.

[Perlsau]

Zitat:

Zitat von DeddyH (Beitrag 1236746)

Weil der Typ nunmal TStrings ist.

Okay, dann hab ich trotz Erzeugung als TStringList nur die Methoden von TStrings. Das will ich natürlich nicht. Die Einwände der oben genannten Quellen sind dann vermutlich Humbug: Angeblich soll es Probleme geben, wenn ich einer TStringList, die auch als solche deklariert wurde, z.B. ein Memo.Lines oder ein ListBox.Items zuweise.