an String anhängen - mal wieder Probleme mit #0

[Martin K]

Zitat:

Zitat von Muetze1

Das geht definitiv auch. Getestet mit BDS2006, siehe Anhang (wovon die Turbo's nur eine Ausgliederung sind)

:shock: :shock: :shock: :shock: :shock:
Also genau sowas hab ich auch grade getestet mit meinem TurboDelphi...
Achte darauf, was hier in s steht:

//Edit:
Hab net genau hingeschaut auf dein Bild, die letzten 3 Bytes von a sind bei dir abgeschnitten!

[Martin K]

Zitat:

Zitat von bernau

Was hier noch gar nicht gefragt wurde:

Mit welcher Funktion schreibst du die Daten in die Datei?

Verwendest du einen TFilestream, oder schreibst du mit "writeln" und Konsorten.

Ich schreibe mit TFileStream, aber das ganze wird hier aus einer selbst gebastelten Struktur eingelesen und daraus dann in den Stream geschrieben.

[Muetze1]

Ok, stimmt, bei mir schneidet er diese auch ab.

Grundsätzlich: wenn du eine entsprechende Struktur definierst, dann definiere sie entsprechend mit dem richtigen Typ. Wenn du einen String von genau 4 Bytes schreiben willst mit dem Inhalt von #6#0#0#0 scheint es sich eher um einen Integer zu handeln, welcher in der Big-Endian Schreibweise geschrieben werden soll. Sicher das es ein String ist? Und wenn es definitiv 4 Bytes bleiben sollten, warum baust du diesen in einen String ein? Was für einen Sinn hat dies bei einer definierten Struktur?

[mkinzler]

oder soll #0 für ein Leerzeichen stehen?

[Martin K]

Ja, du hast recht, es handelt sich um einen 4-Byte Integerwert.
Normalerweise speichere ich diesen auch in der Struktur als Longword ab, aber hier wird ein Teil der Struktur in einen String zusammen gefasst, da er wieder Teil der Struktur eines übergeordneten Elements ist (klingt jetzt alles etwas theoretisch :mrgreen: )
Auf jeden Fall geschieht dieses Zusammenfassen in der Struktur noch vor dem Schreiben in den Stream und das soll auch so bleiben.
Ich hab dazu per Move() den Longword in das Array[0..3] of Char kopiert, mal sehen, wie es klappt wenn ich stattdessen einen String[4] nehme...

//Edit:
Ok, das funktioniert dann soweit!
Danke an euch alle!

[Muetze1]

Dann nutzt keinen string sondern definiert euch einen Pointer!

Zitat:

Zitat von Martin K

..., mal sehen, wie es klappt wenn ich stattdessen einen String[4] nehme...

Welcher afaik aber 5 Bytes gross ist, da er vorne weg ein Längenbyte hat.

[Martin K]

Zitat:

Zitat von Muetze1

Dann nutzt keinen string sondern definiert euch einen Pointer!

Kannst du dazu mal ein Beispiel machen?

Zitat:

Zitat von Muetze1

Welcher afaik aber 5 Bytes gross ist, da er vorne weg ein Längenbyte hat.

Ja, und genau deswegen wollt ich ja ein Array of Char nehmen, da dieses kein Längenbyte benötigt.
Aber das scheint ja nicht zu klappen...
So geht's zumindest:

Delphi-Quellcode:

var size: LongWord; strsize: String[4];
//...
  SetLength(strsize, 4);
  Move(size, strsize[1], 4);
  s := s + strsize;

Aber statisches Array war irgendwie eleganter, da man kein zusätzliches Längenbyte hat und sich SetLength() sparen kann.
Aber Strings fester Länge gibts ja nicht und mit dem Array eben das Problem mit dem #0 abschneiden...

[Muetze1]

Zitat:

Zitat von Martin K

Kannst du dazu mal ein Beispiel machen?

Sind die Strukturen unterschiedlich/dynamisch lang?

Wenn nicht: Struktur (record) definieren.
Wenn ja: Pointer übergeben, entsprechend Platz reservieren und diesen mit den Daten füllen. Übergeben werden müsste der Pointer sowie die Grösse der Daten.

[Martin K]

Also meine Struktur stellt einen RIFF-Chunk dar (Wave-Dateien).

Delphi-Quellcode:

type
  TID = array[0..3] of Char;
  TChunk = record
    ID: TID;
    Size: LongWord;
    Stream: String;
  end;
  TChunks = array of TChunk;

Also ID ist ein 4 Byte String, Size gibt die Größe des Stream an und Stream ist der entsprechende Stream als String (wurde mit SetLength() auf die Größe gesetzt, die auch in Size steht).

//Edit:
und in dem Fall jetzt, fasse ich Chunks zusammen und schreibe diese in einen "übergeordneten Chunk", also ein übergeordneter Chunk erhält als Stream der Reihe nach ID,Size,Stream der untergeordneten Chunks.
Dabei gab es eben das Problem, den LongWord in String umzuwandeln, sprich: die Größe eines untergeordneten Chunks an den Stream des übergeordneten Chunks anhängen.

[Muetze1]

1. Warum nutzt ihr nicht die Lese- und Schreibroutinen für das RIFF Format von Windows?
2. Warum ein String und nicht z.B. ein TMemoryStream?