String wird bei bestimmetem Byte nicht angezeigt

[willyxv]

Hallo,

ich habe ein kleines Programm geschrieben, welches Daten über einen Com Port empfängt und daraus teildaten anzeigt. Dies funktioniert auch sehr gut solange nicht eine Fehlermeldung in Form eines einzelnen Bytes mitgeschickt wird.

Hier der Datensatz der empfangen wird:
in Grün die Teildaten (5,00)
in Blau die Bytes welche die Position bestimmen

80 F4 80 24 04 75 35 2C 30 30 72 32 35

Und hier das Programm um die Daten zu Filtern:

Delphi-Quellcode:

 
    Anfang :=  char($75);
    PostionsmarkeAnfang  := Pos(Anfang ,KompletterDatensatz);
    Teildaten := Copy(KompletterDatensatz, PostionsmarkeAnfang  + 1,  10);
    Ende :=  char($72);
    PostionsmarkeEnde  := Pos(Ende ,Teildaten );
    Teildaten := Copy(Teildaten, 0,  PostionsmarkeEnde  - 1);
    Anzeige.Caption := Teildaten ;

Und hier der Datensatz mit Fehlermeldungsbyte:
in Grün die Teildaten (5,00)
in Blau die Bytes welche die Position bestimmen
Rot = Fehlermeldungsbyte

80 F4 80 24 04 75 OA 35 2C 30 30 72 32 35

Wird die Fehlermeldung mitgeschickt wird nichts mehr angezeigt. Bei der ausgabe der Anfangsposition und Endposition stimmen diese jedoch, nur auf der anzeige erscheint nichts mehr. Wid die Fehlermeldung nicht mehr mitgeschickt geht es wieder. Desweiteren funktioniert die Anzeige bei einigen Fehlern und hier wird das Fehlerbyte als - oder als ein anderes Symbol angezeigt.

Woran kann dies liegen? Am dem Byte 0A?



Bin für jede Hilfe dankbar

MfG Willy

[Luckie]

0A ist Dezimal 10 und somit ein Steuerzeichen, entweder LineFeed oder CarriageReturn. Und das kann ein Memo oder ähnliches nicht anzeigen.

[alfold]

Darum sollte man generell, keine Steuerzeichen, wenn sie nicht ausgelesen und behandelt werden, über eine Schnittstelle schicken!
http://www.stefan-lenz.ch/bit_glossar/18.html

Gruss alfold

[willyxv]

Danke für die schnellen Antworten.

Zitat:

Darum sollte man generell, keine Steuerzeichen, wenn sie nicht ausgelesen und behandelt werden, über eine Schnittstelle schicken!

leider entscheide ich nicht was über die Schnittstelle geschickt wird das entscheidet das Gerät.

Zitat:

0A ist Dezimal 10 und somit ein Steuerzeichen, entweder LineFeed oder CarriageReturn. Und das kann ein Memo oder ähnliches nicht anzeigen.

Dieses Steuerzeichen kommt nur ab und zu und nicht immer. Gibt es eine möglichkeit es aus dem String zu entfernen? oder zu erkennen ob es enthalten is damit man dann die Copy funktion so anpassen kann das es ausgelassen wird?

Mfg Willy

[WM_CLOSE]

Trim?

[jobo]

Du kannst es z.B. mit StringReplace (unit Sysutils) gegen ein gewünschtes Zeichen austauschen oder ganz entfernen.
Aber in einem String stört 0A ja nicht, erst im Memo oder auf einem Drucker bekommt es Steuerfunktion.

Vielleicht ist es nur ein Tippfehler, aber in Deinem Beispiel steht nicht 0A sondern OA,
der Buchstabe O, der der vor P kommt. Du solltest jedenfalls Deinen Code auch auf solche Fehler prüfen.

[himitsu]

Ich hab mir jetzt nicht alles durchgelesen, aber erstmal ein paar grundsätzliche Probleme.

Du möchstest eine Byte-Folge in einem UnicodeString abbilden?
nicht böse gemeint ... aber spinnst du?
Unicode ist 2 Byte pro Zeichen, das kann also niemals gut gehn,
(außer die Zeichen/Bytes bleiben im Bereich von $00 bis $7F, also ASCII)
denn hier wird ganz gern mal die Ansi-Unicode-Umwandlung zuschlagen, abgesehn von den "unnützen" Bytes zwischen jedem deiner Bytes.

Wenn, dann AnsiString nutzen, oder besser sogar TBytes (array of Byte) oder den RawByteString (welcher eine Umkodierung unterdrückt und somit AnsiChar <-> Char wenigstens bytegenau umkopiert)

Und das gewisse Bytes unterhalb von ' ' aka $20 oder 32 nicht einfach so angezeigt werden können, wurde bestimmt schon gesagt, da dieses Steuerzeichen sind.

PS: Char($ab) = #$ab , bzw. Char(123) = #123 :wink:
Wozu muß man es sich schwerer machen ... es sei denn du nutzt direct AnsiChar zum Casten.

Beim Char hat man nämlich auch noch Probleme im Quelltext.
Bei #$ hat man dabei aber noch eine Möglichkeit einfluß zu nehmen wie die Zahl interpretiert wird, siehe #$85 und #$0085
http://www.delphipraxis.net/130228-a...nd-keines.html
Beides stellt zwar logisch einen gleichen Wert dar, aber für Delphi ist es unterschiedlich.

Zitat:

leider entscheide ich nicht was über die Schnittstelle geschickt wird das entscheidet das Gerät.

Das ist auch vollkommen egal, denn du entscheidest was davon wie angezeigt wird.
- entweder du nutzt eine Ausgabeform (Komponente), welche mit den Daten klar kommt
- oder du mußt die Daten so anpassen, daß die Anzeigekomponente damit klar kommt (z.B. die nötigen oder gleich alle Bytes nach HEX umwandeln)

[alfold]

Wenn solche Steuerzeichen an Deine Schnittstelle gesendet werden und Du sie nicht auswertest wirst Du immer wieder Fehler drin haben!
Deswegen ist es wichtig, bei solchen Dingen, ob man es Byteweise aussliest oder bis die Gegenstelle mir die Info sendet das die Übertragung zu Ende ist. Also liest man die Daten solange in ein Puffer ein, bis das Ende der Übertragung erreicht ist und wertet die Daten erst dann aus!
Denn auch dafür gibt es, wie für fast alles, ein Protokol. Dein Sender sollte sich also an das Protokol halten, dann weisst Du auch wann ein steuerzeichen kommt oder wann es Daten sind! Oder Du musst dich an das Protokoll halten und nicht einfach nur evtl Daten suchen, es könnten die Daten an dieser Position sein!
Denn so, wie ich es vermute, verwendst Du kein Protokoll, denn ein Linefeed wird nicht umsonst gesendet.

Mehr kann man da nicht sagen, dazu müsste man wissen schickt die Gegenstelle selbstständig Daten oder ob Du Daten anforderst!??

Zitat:

Das ist auch vollkommen egal, denn du entscheidest was davon wie angezeigt wird.

Ist nur halbrichtig, Steuerzeichen muss er selbst auswerten! Sie erscheinen ja nicht von ungefähr bei Schnittstellen, wenn sie dann Übertragen werden:wink:
Gruss alfold

[himitsu]

Zitat:

Zitat von alfold (Beitrag 1087124)

Sie erscheinen ja nicht von ungefähr bei Schnittstellen, wenn sie dann Übertragen werden:wink:
Gruss alfold

Sag ich ja.

Gut, ein Protokoll legt fest wie die Daten aufgebaut sind,
aber der Programmierer ist dann dafür verantwortlich die Daten notfalls umzukodieren, wenn die nachfolgenen Stellen (wie z.B. ein TMemo) mit diesesn Daten nicht klar kommt (es aber unbedingt dort angezeigt werden soll).

- Protokoll = Definition der Schnittstelle vom Gerät zu seinem Programm, also das Format der zu übertragenden Daten
- und die Schnittstelle zwischen dieser Schnittstelle und seiner Anzeige muß er sich nun selber schaffen.
> z.B. beim TMemo ist das grundlegende Protokoll, bzw. das Format des Textes festgelegt,
also müßte er nun quasi die Daten von Übertragungsprotokoll ins Anzeigeprotokoll umwandeln. :stupid:

[p80286]

Nu mal langsam,
es sollte doch eigentlich klar sein, daß Daten aus "unbekannten" Quellen zunächst einmal nur Werte sind. Sie dann gleich als Buchstaben zu interpretieren ist zumindestens optimistisch.

Gruß
K-H