tstringlist.loadfromstream liest mehr ein, als es soll

[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 von Bummi:

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 von himitsu:

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?

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 von himitsu:

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