tstringlist.loadfromstream liest mehr ein, als es soll

[DrUArn]

Hallo, community

als Fingerübung habe ich mal eine tpersistent abgeleitet, welches in streams Daten schreiben und lesen kann:

Delphi-Quellcode:

//Zuordnung von lesen und schreiben
procedure TStoreComponent_UA.defineproperties(filer: tfiler);
begin
  inherited;
  Filer.DefineBinaryProperty('otherdata', readotherdata,writeotherdata, true);
end;


//daten lesen
procedure tstorepersistent_UA.readotherdata(astream: tstream);
 var i:integer;
begin
astringlist.Clear;
astringlist.LoadFromStream(astream);
end;



//daten schreiben
procedure tstorepersistent_UA.writeotherdata(astream: tstream);
  var i:integer;
begin
astringlist.SaveToStream(astream);
end;

Habe ich in den Stream vorher mehr Daten eingeschrieben als in einem späteren Speicherungsprozess, kann es passieren, das beim Lesen mehr strings in der eingelesenen Liste stehen als geschrieben wurden (und zwar alles, was noch "hinter" dieser Position bis zum Ende des streams steht).
Beispiel: erste Speicherung: 100 strings, erstes Lesen: 100 strings; zweite Speicherung: 10 Strings, zweites Lesen: wieder 100 strings

Weiss astringlist.LoadFromStream(astream) nicht, wieviele strings eingelesen werden müssen - und frißt sich bis zum Ende des Streams durch -alle Daten als strings interpretierend?

Wenn ja, wie löst man dieses verhalten auf?

MfG Uwe

[Bummi]

Delphi-Quellcode:

Weiss astringlist.LoadFromStream(astream) nicht, wieviele strings eingelesen werden müssen - und frißt sich bis zum Ende des Streams durch -alle Daten als strings interpretierend?

woher soll sie es wissen, ab Stream.Position wird gelesen bis Streamende ....

[jaenicke]

Zitat:

Zitat von DrUArn (Beitrag 1138019)

Wenn ja, wie löst man dieses verhalten auf?

Kopiere die entsprechenden Daten in einen temporären TMemoryStream, der nur diese Daten enthält. Den kannst du dann an LoadFromStream übergeben.

Ich habe einen ähnlichen Fall aber anders gelöst:
Ich habe mir eine eigene TStream Klasse abgeleitet, die einen TStream als Adapter enthält und selbst die Größe der einzelnen Daten mit in den Stream schreibt. Beim Auslesen wiederum spiegelt der Stream jeweils eine Größe vor, die nur bis zum Ende der aktuellen Daten reicht. Aber das ist für dich jetzt vermutlich wie mit den Kanonen und Spatzen und so. ;-)

[DrUArn]

Hallo community,

@Bummi: o.k., das ist die Antwort. In den Hilfen findet der Laie die Funktionsbeschreibung eben nicht. Ich hatte die Vorstellung, dass man am Anfang des Schreibprozesses die Anzahl der strings (count) speichern könnte.

@jaenicke: stimmt.

Schade, dass tstringllist dieses Verhalten nicht kann.
Meine Lösung wäre dann zwar umständlich, aber möglich:

Delphi-Quellcode:

procedure tstorepersistent_UA.writeotherdata(astream: tstream);
   var i:integer;
 begin
 astream.write(astringlist.count,sizeof(astringlist.count));
 for i:=0 astringlist.count-1 do 
   begin
      i:=length(astringlist[i])*sizeof(char);
      astream.write(i,sizeof(i));
      astream.write(pointer(astringlist[i])^,i);
   end
 end;

Enstprechendes umgekehrt beim Wiedereinlesen.
Habe ich noch nicht getestet.

Danke an alle!

MfG
Uwe

[himitsu]

Die StringListe als Erstes in den Stream und dann noch eine #0 (besser ein Word mit dem Wert 0) hinten an den Stream ... danach kann man ohne Probleme andere Daten dranhängen.

Hat man den Gesamt-Stream in einem TMemoryStream drin, dann kann der Text der StringList sonstwo stehen, onlange auch da eine #0 hinten dran hängt ... einlesen dabei z.B. über TStringList.SetText.


Ich hatte mir irgendwo mal einen Stream erstellt, welcher einen Teil eines anderen Streams wie einen eigenständigen Stream representiert, ohne die Daten vorher temporär zu kompieren.

[DrUArn]

@himitsu

heisst, tstringlist.LoadFromStream(astream) liest definitiv nur bis #0?

Probiere ich aus.

danke Uwe

//daten schreiben
procedure tstorepersistent_UA.writeotherdata(astream: tstream);
var i:integer;
a:char;
begin
astringlist.SaveToStream(astream);
a:=#0;
astream.Write(a,sizeof(a));
end;

Diese Änderung bringt's nicht - wo und warum der Leseprozess beendet wird, kann ich nicht erkennen - aber immer werden ein paar mehr Strings eingelesen als gespeichert!

Gruß Uwe

[himitsu]

http://www.delphipraxis.net/130566-t...ml#post1137526

Theoretisch sollte sie (zumindestens die aktuelle TStringList) auch nur ab der aktuellen Position einlesen, aber ich bin mir nicht sicher, ob das schon immer der Fall war ... aber bis zur #0 lesen die alle nur.

[CCRDude]

Das wäre aber bugusing. Denn daß eine StringList nur bis #0 arbeitet, ist imho ein Bug. Der irgendwann gefixt werden kann, und dann sucht man den Fehler...

Heißt ja immerhin TStringList und nicht TPCharList ;)

Leider hat die RTL/VCL einige wenige solcher Stellen, aber Embarcadero fixt sie, wenn bekannt. Zumindest habe ich mal den #0-End-Bug in StringReplace gemeldet und das QC-Ticket wurde sogar geöffnet (ob auch schon gefixt weiß ich gerade nicht mehr).

[Bummi]

lese tut sie alles, aber interpretiert wird nur bis zur #0, in den Zeiten von Unicode sollte man eh andere Wege bestreiten...

[DrUArn]

Hi,


@himitsu: Hatte mich in meinen eigenen Routinen verheddert. Du hast recht! #0 beendet den Lesevorgang. Sicherheitshalber noch mal die Frage: Wird dieses zusätzlich gespeichert #0 (a:=#0; astream.Write(a,sizeof(a))) beim Lesen (tstringlist.LoadFromStream(astream))mit einbezogen - also astream.position hinter dem #0 oder muß man beim Lesen nochmal astream.read(a, sizeof(a) nutzen, um weitere Daten ab der richtigen Stelle zu lesen. Beim Probieren meine ich zu merken, dass der Zeiger schon hinter dem #0 steht.

OK - ich denke der Zeiger muß hinter #0 stehen - denn erst muß tstringlist.LoadFromStream(astream) das #0 ja einlesen ehe das Lesen gestoppt werden kann!

@Bummi: Welche?

MfG Uwe

[Bummi]

du bist auch wenn #0 vorkommt faktisch am Ende des Streams .... es wird nur nicht mehr dargestellt

Delphi-Quellcode:

var
ms:TStringStream;

procedure TForm1.Button1Click(Sender: TObject);
var
 s:String;
begin
    s := '连接测试'+ #13#10 +'Test'+#0;
    ms.WriteString(s);
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
   ms.Position := 0;
   ListBox1.Items.LoadFromStream(ms,TEncoding.Unicode);
   Caption := IntToStr(ms.Position) + ' - ' + IntToStr(ms.Size)
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
 ms := TStringStream.Create('',TEncoding.Unicode);
end;

Mir ist noch nicht ganz klar was genau Du vorhast, ich würde das was ich verstanden habe über eine Klasse mit einer Liste von Streams abfackeln, was hier für welche Ausgabe gebraucht wird lässt sich iontern gegf. über zusammenkopieren in neue Streams abfackeln.
Der Ansatz von Jaenicke könnte für Dich passen, auch Dein Ansatz mit Längenspeicherung innerhalb des Streams ist brauchbar, allerdings würde ich den von Komponenten zu ladenden Stream vorher in einen neues Extrahieren.

[himitsu]

Zitat:

Zitat von Bummi (Beitrag 1138117)

du bist auch wenn #0 vorkommt faktisch am Ende des Streams .... es wird nur nicht mehr dargestellt

Das mit der #0 ist kein Bug, sondern Absicht (ein Feature), wegen Kompatibilität zum PChar.

Ein Delphi-String abeitet über eine Längenangabe und nicht über eine Endemarkierung.

Der einzige "Bug" ist, daß man nach dem Laden, über Add in eine TStringList Strings mit #0 einfügen kann.
Andere Stringlisten, wie z.B. die vom Memo (Lines) arbeiten dagegen anders und beachten indirekt die #0.

[DrUArn]

@Bummi: Wie am Start gesagt - 'ne Fingerübung - wollte nur ein allg. Object probieren, welches Daten in eine Stream speichert - also etwa ein Integer, einen String, ein Byte-Array und eben falls nötig - eine Stringliste.

Delphi-Quellcode:

procedure tstorepersistent_UA.writeotherdata(astream: tstream);
  var i:integer;
      a:char;
begin
astringlist.SaveToStream(astream);
a:=#0;
astream.Write(a,sizeof(a));

astream.write(F_int,sizeof(F_int));
astream.write(i,sizeof(i));
astream.write(pointer(astring)^,i);
astream.Write(f_maxblocksize,sizeof(f_maxblocksize));
astream.Write(abytearray^,maxblocksize);
end;

procedure tstorepersistent_UA.readotherdata(astream: tstream);
 var i:integer;

begin

astringlist.Clear;
astringlist.LoadFromStream(astream);

astream.Read(F_int,sizeof(f_int));
astream.read(F_char,sizeof(F_char));
astream.Read(i,sizeof(i));
SetLength(F_string,i div sizeof(char));
astream.Read(pointer(f_string)^,i);
FreeMem(abytearray);
astream.Read(F_maxblocksize,sizeof(maxblocksize));
getmem(abytearray,maxblocksize);
astream.Read(abytearray^,maxblocksize);
end;

Ohne eine Stringliste funktioniert das. Mit Stringliste kommt's zu Störungen.
Speichere ich z.B. obiges 2 mal und lade es auch 2 mal, dann ist die zweite geladene Stringliste leer (count=0) - womit Du wohl recht hast -das erste Lesen führt schon zum Ende des Streams, auch wenn irgendwo #0 steht und egal, ob ich die Liste am Anfang oder am Ende des Objects schreibe und lese - so sieht es jedenfalls beim Probieren aus.

Mfg Uwe

[Bummi]

@himitsu

Zitat:

Das mit der #0 ist kein Bug, sondern Absicht (ein Feature), wegen Kompatibilität zum PChar.

ich habe es auch nie als Bug bezeichnet, sondern wollte nur darauf hinweisen daß man danach am Ende des Streams steht.

@DrUArn
jepp, aber da die Streams ja nicht das Problem sind kannst Du ja Exzerpte in die Stringlisten laden ...

[DrUArn]

hi,

Zitat:

jepp, aber da die Streams ja nicht das Problem sind kannst Du ja Exzerpte in die Stringlisten laden ...

@Bummi: ... verstehe Ich nicht. Nebenher, wenn man als unbedarfter eine Info über die Arbeitsweise von tStringlist.save/load...fromstream haben will (eben gerade die wichtige: liest immer bis zum Ende des Streams), findet man die nicht in der Delphi-Hilfe. Wo könnte man so detailierte Info's herbekommen?


Grüße
Uwe

[Bummi]

wenn Du die Sourcen hast

unit Classes

procedure TStrings.LoadFromStream(Stream: TStream; Encoding: TEncoding);

Ansonsten lang es ja auch Stream.Position anzufragen nach dem LoadFromStream

[CCRDude]

Zitat:

Zitat von himitsu (Beitrag 1138122)

Das mit der #0 ist kein Bug, sondern Absicht (ein Feature), wegen [der] Kompatibilität zum PChar.

Wie schön. Ich argumentiere, daß Embarcadero das schon in anderen Fällen als Bug anerkannt und behoben hat und es daher ein Bug sein dürfte.

Du argumentierst, daß himitu meint daß es kein Bug wäre und damit ein Feature wäre, und bleibst ohne Belege.

Wem soll ich jetzt glauben? :D

Da ich aber eine Konkretisierung meines Belegs schuldig geblieben bin:
http://qc.embarcadero.com/wc/qcmain.aspx?d=60730

Auch die Delphi-Hilfe erwähnt eine angeblich erwünschte Kompatibilität in keinster Weise. Ich nehme hier mal AnsiString, weil der schon älter ist. Dort wird explizit der Support von MBCS/DBCS erwähnt, der aber mit PAnsiChar-Kompatibilität unmöglich wäre, weil PChar-kompatible String-Operationen auf MBCS-Texten in AnsiStrings dann jeweils nur ein Zeichen kopieren würden.
http://docwiki.embarcadero.com/VCL/en/System.AnsiString

Zitat:

Zitat von himitsu (Beitrag 1138122)

Ein Delphi-String abeitet über eine Längenangabe und nicht über eine Endemarkierung.

Genau. Und ist deswegen auch nicht kompatibel (wenn es um #0 geht), beziehungsweise sollte es nicht sein.

[DrUArn]

Hi,

@alle Diskutanten: Danke für Eure Beiträge, hat mir wieder ein (kleines) Stück geholfen, Delphi zu verstehen. Gelernt, dass man manchmal auch probieren muss, was eine Routine tut (@Bummi's letzter Beitrag). - Bloß habe ich dieses Verhalten von load/save..stream mehr zufällig bemerkt - sonst hätte ich wohl noch ein Stück weiter programmiert und mich später sehr gewundert.

Als nochmal Danke

mfG Uwe

[DrUArn]

Nochmal zum Thema:

nachdem ich in einem abgleiteten tpersistent eine Schreib- und Leseroutine (ähnlich s.oben) erfolgreich eingefügt habe, sehe ich, dass in von tcomponent abgeleiteten Objecten möglich ist, eine Eigenschaft für stringlisten zu definieren mit entsprechenden schon vorhandenen Lese- und Schreibroutinen:

Delphi-Quellcode:

  TStoreComponent_UA = class(TComponent)
  private
    { Private-Deklarationen }
  F_stringlist:tstringlist;
 protected
    { Protected-Deklarationen }
  public
    { Public-Deklarationen}
  published
    { Published-Deklarationen }
    property astringlist: TStringList read F_stringlist write F_stringlist;
    constructor create(aowner:Tcomponent);override;
    destructor destroy;override;
    procedure defineproperties(filer:tfiler);override;
    procedure readotherdata(astream:tstream);virtual;
    procedure writeotherdata(astream:tstream);virtual;
  end;

Als ich das unter Turbodelphi mal probiert habe kam die Fehlermeldung "Propertys nur für einfache Typen erlaubt".
Ich dachte immer, property's dürfen nur einfache Typen sein - ist eine tstringlist so was?
Hier funktioniert jedenfalls das Lesen und Schreiben - auch mehrfach - ohne zu meckern. Wie ist das von den Delphi-Programmieren gelöst wurden?

MfG UWE