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