Hex-Werte an String hängen

[p80286]

Also, wofür soll das gut sein?
Zunächst gibt der Benutzer einen String ein, der aus Ziffern zusammen gesetzt wird.
Wenn "CPort" nur mit Strings umgehen kann, dann hast du doch alles was Du Brauchst?

Gruß
K-H

[Caleb]

Zitat von p80286:

Also, wofür soll das gut sein?
Zunächst gibt der Benutzer einen String ein, der aus Ziffern zusammen gesetzt wird.
Wenn "CPort" nur mit Strings umgehen kann, dann hast du doch alles was Du Brauchst?

Gruß
K-H

Weil es das Protokoll so will =/

z.B. so ...
--> [Request(ASCII)]+[16bit-Zahl]+[8bit-Zahl]
--> ['W']+[0x01A9]+[0xFF]

und den 16bit-Wert kann ich leider nicht so einfach ASCII-codieren ...

[p80286]

Zitat von Caleb:

--> ['W']+[0x01A9]+[0xFF]

Das erreichst Du über

Delphi-Quellcode:

s:='[''W'']+[0x'+
   inttohex(strtoint(edit1.text),4)+
   ']+[0x'+
   inttohex(strtoint(edit2.text),2)+
   ']';

Da fehlen naturlich noch ein paar Fehlerprüfungen.....

Gruß
K-H

[himitsu]

Nein, ein COM-Port kommt grundstzlich auch mit Steuerzeichen ala #0 und Co. zurecht.

Es kommt eher darauf an, wie der Empfänger die Daten interpretiert/interpretieren kann und wie eventuelle Zwischenschichten/Überträger arbeiten.
Mit diesem Wissen sollte man sich erstmal ein Protokoll überlegen und darüber entscheidet sich dann.

Wenn man nun ein Protokoll vorgegeben oder erstellt hat, dann kann man sich überlegen, wie man dieses nun Programmseitig erfüllt/umsetzt.

[Namenloser]

Zitat von DeddyH:

Das wird aber blöde, wenn da zufällig eine 0 umgewandelt wird, da der String danach abgeschnitten wird.

In Delphi eigentlich nicht, weil Delphi keine 0-terminierten Strings verwendet, sondern ein Längenpräfix. Es gibt allerdings einige String-Funktionen die nicht mehr richtig funktionieren, wenn ein 0-Byte vorkommt.

[himitsu]

Zitat von NamenLozer:

In Delphi eigentlich nicht, weil Delphi keine 0-terminierten Strings verwendet, sondern ein Längenpräfix. Es gibt allerdings einige String-Funktionen die nicht mehr richtig funktionieren, wenn ein 0-Byte vorkommt.

Jupp, einige interne Funktionen nutztn nicht die Längenangabe, sondern arbeiten über PChar und auch die VCL, also speziell die gekapselten Windowskomponenten und vorallem deren APIs arbeiten letztendlich fast alle mit PChar.

[Caleb]

Zitat von p80286:

Zitat von Caleb:

--> ['W']+[0x01A9]+[0xFF]

Das erreichst Du über

Delphi-Quellcode:

s:='[''W'']+[0x'+
   inttohex(strtoint(edit1.text),4)+
   ']+[0x'+
   inttohex(strtoint(edit2.text),2)+
   ']';

Habt dank für die zahlreichen Antworten, ABER ich glaub wir verstehen uns immer noch bisschen falsch ...
Bei dieser Variante bekomme ich doch den HEX-Wert ins ASCII formatiert ... und zwar in seiner vollen Länge ...
wenn der Wert den ich per Edit-Feld eingegeben habe einem hexadezimalen von meinetwegen 0x01AC entspricht, dann bekomme
ich mit der Vorgehensweise von oben 4 ganze ASCII-Chars für die 16bit-Zahl und zwei Chars für die 8bit-Zahl ...
ABER um die Zahl darzustellen brauche bzw. darf ich nur zwei Chars bzw. einen verwenden.

Solange beim Konvertieren kein Linefeed und Carriage-Return rauskommt ist es mir völlig egal was aus der seriellen Schnittstelle rauspurzelt.
Und CR bzw. LF kann man ja durch Überprüfung verhindern.

Um das nochmal zu verdeutlichen hab ichs mal bisschen in nem Bild zusammengefasst ...

http://imageshack.us/f/830/36160050.jpg/

Leider steh ich nämlich immer noch aufm Schlauch =/

[p80286]

Wenn ich das richtig interpretiere dann willst Du einen Ansichar, ein Word und ein Byte übertragen.

Delphi-Quellcode:

TMyRecord = packed record
             n1: Ansichar;
             n2: Word;
             n3: Byte;
          end;

und die beiden Werte n2 und n3 werden über ein TEdit eingegeben. Also brauchst Du Wahrscheinlich so etwas:

Delphi-Quellcode:

var
  MyRecord : TMyRecord;


Myrecord.N1:='W';
Myrecord.n2:=strtoint(Edit1.text) and $FFFF;
MyRecord.n3:=strtoint(Edit2.text) and $00FF;

Gruß
K-H

[v2afrank]

Es geht auch einfacher:
s:='W'+Ansichar(hi(strtoint(Edit1.text)))+Ansichar(lo(strtoint(Edit1.text)))+ansichar((strtoint(Edit2.text)));

[Caleb]

AMEN
Danke v2afrank funktioniert wunderbar.
@all responses: Vielen Dank für Eure Geduld.