Problem mit #0 im String

[R2009]

Hi DP'ler,

ein kleines Problem:
In edit1 steht Hex (z.B. 0C4B3A). In edit2 soll nacher der Text als solches stehen.
Problem:
Sobald in edit1 eine "00" (Beispiel: 0C54003A übrig bleibt nur oC54) auftaucht geht der Rest des Strings bei der Zuweisung zu edit2 verloren.
Da edit2 aber nur ein "Zwischenspeicher" für den String ist darf das keinesfalls passieren.
Hat jemand eine Idee? (INVHEXB ist eine Funktion von mir und funktioniert einwandfrei)

Delphi-Quellcode:

  b:=edit1.text;
  a:='';
  while length(b)>1 do
    Begin
      t:=INVHEXB(b[1]+b[2]);
      a:=a+chr(t);
      delete(b,1,2);
    end;
  edit2.Text:=a;

Danke im Vorraus!

[taaktaak]

Moin, Moin.

Zitat:

In edit1 steht Hex (z.B. 0C4B3A). In edit2 soll nacher der Text als solches stehen.

Hmmm, verstehe ich nicht: In Edit1 ist ein String und der soll nach Edit2? Wozu der Umweg? Was passiert da? Und wieso ist die Zahl 0 = #0?? 0=#48!!

[chaosben]

Tschaaa ... was soll man dazu sagen.

Sobald du eine binäre 0 im String hast, ist für die meisten Delphi-String-Routinen (und imho 99% aller anderen Sprachen + Windows) der String beendet. Das ist so eine Art Naturgesetz.

Um die Null darzustellen musst du dir irgendetwas einfallen lassen.

//Edit: obiger Text wurde dem revidierten Wissenstand angepasst

[Zoot]

Du solltest deine InvHexB so umschreiben, dass sie für alle Steuerzeichen (0..31) eine Sonderbehandlung durchführt, sonst wirst du keinen Spass daran haben.

[taaktaak]

... und wie kommt #0 in das EditFeld hinein?
Bevor ich die Symptome kuriere,
wäre es doch besser die Ursache zu beseitigen, oder?

[Satty67]

Zitat von chaosben:

Das ist so eine Art Naturgesetz.

Nicht ganz...

Delphi-Quellcode:

s := '1234'#0'6789';
Edit1.Text := s; // Anzeige 1234
ShowMessage(IntToStr(Length(s))); // 9!

String ist in Delphi durchaus in der Lage, auch #0 aufzunehmen, ohne die Länge zu kürzen. Nur Edit.Text ist wohl am Ende ein PChar, das dann bei der Anzeige tatsächlich abgeschnitten wird.

[sirius]

Wie? Du benutzt Edit2 nur als Zwischenspeicher?

@Chaosben
Die Delphi-Strings haben ja gerade die Besonderheit sich nicht an einer #0 zu stören. Solange man auch nur mit DelphiStrings arbeitet ist das auch kein Problem. Nur die Übergabe zu dem von Windows verwalteten Edit erfolgt über PChar. Und erst da wird der String gekürzt.

[chaosben]

Ja, ok ... das Obige war nicht korrekt.

Strings können auch 0-Zeichen enthalten. Die Einschränkung ist eben nur, das 90% der String-Routinen hintenrum auf PChars basieren und deswegen mit 0-Zeichen nichts anfangen können.

Und in diesem Fall gehts nicht, weil der Text eines Fenster/Edits per PChar gesetzt wird.

[R2009]

Hi,

ich wollte hier keine Diskussion anfangen warum ich das so oder so mache!

Hier nocheinmal eine kurze Erläuterung zur Problematik:
Beispiel:
ich muss den als Hex-Code voliegenden String zu einem Gerät binär übertragen (bei uns sind das Rundsteuerempfänger).
Hex als char
30313233 -->'0123'
das kann ich ohne weiteres übernehmen, kommt ja keine absolute 0 drin vor.
Sobald ich 30310033 übertragen will krieg ich nur noch 3031, weil ja plötzlich im zu sendenden String eine '0' steht.
'01'#0'2'
Dass da Nullen vorkommen ist ein 'Naturgesetz' und nicht umgehbar! Das Übertragungsprotokoll kann ich auch nicht ändern!
Wie machen das eigentlich die "C" Freaks?

Ich habe die Edit-felder gegen 'normale' Strings ausgetauscht jetzt funktioniert das alles.

Was mich stört ist:
Wieso wird der String in tedit (tedit.text ist nichts anderes als ein String) anders behandelt als ein normaler String.
Das ist doch Sch.... oder?

Für alle die immer alles besser wissen:
Die edit-Felder hab ich nur benutzt um zu sehen was passiert. Da das Ganze mit einer hohen Dynamik abläuft
kommt der Debugger nicht in Frage. Hab mir halt auf diese Art beholfen.

Vielen Dank für alle konstruktiven Beiträge!

[Satty67]

Zitat von R2009:

Was mich stört ist:
Wieso wird der String in tedit (tedit.text ist nichts anderes als ein String) anders behandelt als ein normaler String.
Das ist doch Sch.... oder?

Also zur Speicherung der binären Daten hast Du jetzt einen Datentyp genommen, der auch alle binären Zeichen speichern kann (Delphi-String, array of Byte wäre auch gegangen etc.)

Zur Anzeige musst Du die Daten aber aufbereiten, also Zeichen 0-31 und 127 ersetzen (Parser). Den TEdit.Text wurde zwar in Delphi als String implementiert, ist aber eigentlich ein PChar (das eben keine #0 als Datenbestandteil aufnehmen kann). Das kann mit dem Standard TEdit auch nicht geändert werden, ist ja ein Windows-Objekt.

Der einfachste Weg wäre, zur Datenspeicherung/Übermittlung Deine funktionierende Lösung und zur Anzeige den String aufbereiten.

#0 = '<NUL>'
...
#127 = '<ESC>'