Nix da.. geb gas und mach fertisch, dann schauen wir mal ;)Zitat von Dove
Nix da.. geb gas und mach fertisch, dann schauen wir mal ;)Zitat von Dove
Ich gebe hier ausschließlich meine private Meinung wieder!
ohhhh :(
bei rennt es :D und bei dir ?! ^^
@Buebchen.
die badConverion Exception die beim decoden geworfen wird tritt doch dann auf, wenn er auf, wenn er zeichen findet die (<0&&>9)||(F)||(f)
Nur das das doch rein Theoretisch gar nicht passieren, wenn ich daten von dir bekomme (monitord)
Ich versteh nicht warum er dort ständig rein brät.
Wird vielleicht wird der Doppelpunkt als Trennzeichen noch mitübergeben ? Sonst lass dir die Zeichenkette vorher mal ausgeben. Aber wie du schon schreibst. Die Exeception wird nur bei Zeichen geworfen die nicht [0..9], [a..f] oder [A..F] sind.
also die Exception kommt bei sowas hier:
Error: &TRN03195967E00847EB5 -EOL- æ2ÔTôÂÒ
Error musste dir davor wegdenken, das ist noch ausgabe vorher.
Error: 67 73 f0 7d -EOL- RRô´ÄRõ¤'&öæ2ââââÔTôÂÒ
sowas kommt da auch bei raus bzw rein.
Entweder bekomm ich das so vom daemon (was ich nicht glaube) oder ich hab irgendwo noch schrott in den vars stehen.
Aha. Der Fehler liegt im monitord. Der Text ist ja nicht verschlüsselt, sondern klartext. Seltsam. Habe ich bestimmt wieder mal beim Testen vergessen 'was zurückzustellen.
Die zweite Aussendung ist vom Fahrzeug aus. Die sollten eigentlich überhaupt nicht auftauchen.
Werde das heute abend mal prüfen ...
Die "Schrott am Ende" liegt vermutlich daran, daß die Zeichenkettenvariable nicht bei jedem Aufruf "genullt" wird.
ja hab ich mir eigendlich auch gedacht, aber da ich die laufzeit var (mein vector mit dem jeweiligen param) erst in der While erstelle kanns daran nicht liegen.
Und der Buffer wird am ende der while auf buffer[0] = '\0'; gesetzt.
Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)