TStringList erzeugt access violation...

[user0815]

Ich verstehe nichts mehr.... :|

Habe ein neues Projekt erstellt, drücke ich auf den Button erscheint die Meldung "ok".

Delphi-Quellcode:

  private
    { Private-Deklarationen }
    SendeListe : TStringList;
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
  if SendeListe.Count > 0
   then ShowMessage('falsch')
    else ShowMessage('ok')
end;

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  if SendeListe <> nil
   then SendeListe.Free;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  SendeListe := TStringList.Create;
end;

In einem anderen Projekt habe ich ähnliches. Hier erhalte ich allerdings eine Exception die ich nicht verstehe.
Ich habe hier mal den Code auf den Button wo es passiert verkürzt:

Delphi-Quellcode:

  private
    { Private-Deklarationen }
    SendeListe : TStringList;
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
  SendeListe := TStringList.Create;

  if SendeListe.Count > 0
   then ShowMessage('falsch')
    else ShowMessage('ok')
end;

sobald ich auf den Button drücke erhalte ich bei Zeile: "if SendeListe.Count > 0" eine Exception.

---------------------------
Benachrichtigung über Debugger-Exception
---------------------------
Im Projekt SoUndSo.exe ist eine Exception der Klasse $C0000005 mit der Meldung 'access violation at 0x00700bfd: read of address 0x02000041' aufgetreten.
---------------------------
Anhalten Fortsetzen Hilfe
---------------------------

Der Debugger spuckt über dem "count" als Meldung "Ungültiger Ausdruck im Evaluator" aus.

Gibt es irgendwelche Projektdateien die man löschen kann damit dieser nicht vorhandene Fehler verschwindet.
Neustart: Delphi, Rechner hat nichts gebracht.
Ich verstehe leider nichts mehr. :cry:

[DeddyH]

Und wenn Du den Code so wie er ist mal in einem neuen Projekt einfügst? Ich sehe keinen Fehler (nur ein Speicherleck) und kann das unter XE auch nicht nachvollziehen.

[baumina]

Heißt in diesem Projekt evtl. noch irgendetwas anderes SendeListe, eine Variable, eine Function, eine Procedure, eine Unit?

[user0815]

Delphi-Quellcode:

  SendeListe := TStringList.Create;
  SendeListe.Clear;

füge ich die Clear Zeile ein, dann kommt die Exception nicht.

Heißt in diesem Projekt evtl. noch irgendetwas anderes SendeListe, eine Variable, eine Function, eine Procedure, eine Unit?
STRG + UMSCH + F: Nein (hatte ich bereits geprüft)

[baumina]

Wenn du mit der Maus auf TStringList fährst, wird dir angezeigt aus welcher unit diese ist (müsste classes sein). Ebenso bei SendeListe mal überprüfen.

[user0815]

es ist die: "System.Classes.TStringList"

Ich werde die Form jetzt mal aus dem Projekt schmeissen & alles neu einfügen, mal schauen...

[himitsu]

Im Debuger oder einer Messagebox mal

Delphi-Quellcode:

Pointer(SendeListe)

ausgeben, also direkt nach dem Erstellen der Stringliste
und dann vor dem Zugriff nochmal.

Stehen da die selben Werte drin?
Es kann natürlich noch sein, daß du im Programm z.B. einen Buffer-Overrun hast und dir diese Variable zerstörst.

[Lemmy]

Hallo,

bevor du das machst: Schau mal nach, ob das FOrmular ggf. 2x erzeugt wird, einmal automatisch beim Start, einmal von dir manuell erzeugt. Da habe ich schon die tollsten Fehlermeldungen bei Kollegen gesehen ;-)

Grüße

[Bjoerk]

BTW, SendeListe.Free gehört eigentlich nach FormDestroy.

[user0815]

Arrrrggghhhhhhhh

der Fehler lag ganz woanders.
Ich habe einen Record erstellt und einer Variablen den Record zugewiesen. Hierbei habe ich mit Konstanten gearbeitet und durch die Codevervollständigung (irgendjemand muss ja Schuld haben) die falsche genommen.

Delphi-Quellcode:

const
  MaxWert = 10;
  MaxWertEinheiten = 20;

type 
  TRecordXYZ = Record
    a : Integer;
  end;

var
ABC : array[1..MaxWert] of TRecordXYZ;
//statt
ABC : array[1..MaxWertEinheiten] of TRecordXYZ;

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.

Danke für´s gucken!
Sollte vielleicht öfter mal ne Pause machen...

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

[DeddyH]

Das stimmt so aber doch auch wieder nicht, bei Properties oder Parametern kann die Deklaration als TStrings ja durchaus wieder sinnvoll sein (mache ich ja auch so gut wie immer so).

[Lemmy]

Hi Perlsau,

es kommt halt darauf an...

wenn man die Zuweisung "richtig" macht dann ist das kein Thema, aber ein

Delphi-Quellcode:

var Liste: TStringList;
begin
...

  memo1.Lines := Liste;
end;

oder auch anders rum würde ich persönlich nie verwenden. Das mögen andere anders sehen...

Und auch die Verwendung von TStrings kann man so einfach auch nicht als falsch darstellen: Die VCL macht es doch vor: Die Schnittstelle einer Klasse/Komponente ist sicherlich sinnvoller mit einem TStrings zu deklarieren als mit einer TStringList. Hier hast Du dann für den Anschluss nach außen mehr Möglichkeiten.

Wenn Du andererseits eine sortiere Liste haben willst, spricht schlicht nichts dafür, einen TStrings zu definieren und dann anschließend eine TStringList reinzubuttern und ständig zu casten...

GRüße

[jaenicke]

Man sollte immer den kleinsten gemeinsamen Nenner nehmen, den z.B. eine Funktion benötigt. Wenn die Funktion auch mit TStrings funktioniert, sollte man auch TStrings als Parameter nehmen, damit man sie mit allen Nachkommen von TStrings aufrufen kann.

Wenn man aber darin etwas von TStringList braucht, z.B. eben Sorted, dann muss man auch diesen benötigten Typ benutzen, da man sonst im günstigsten Fall casten muss, ich ungünstigsten Fall aber einen anderen Nachkommen von TStrings in der Variablen hat. Versucht man den dann zu casten knallt es logischerweise.

[himitsu]

Zitat:

Zitat von jaenicke (Beitrag 1236760)

Wenn man aber darin etwas von TStringList braucht, z.B. eben Sorted, dann muss man auch diesen benötigten Typ benutzen,

Was dann aber auch wieder der kleinste gemeinsame Nenner wäre. :angel: