Christian, you replied: > > How to do it? > > You define an escape character (maybe really <Esc>=0x1B or even better a > > char that is unlikely to show up in your data). Than replace any > > occurance > > of this char in your original data with a sequence of <escape><0x1> and > > afterwards all occurances of <delimiter with <escape><0x2>. Send this > > data > > and perform the inverse operation before using your delimiter. > > Both transcodings can be transparent. > > I do not have VIs at hand, but exactly this is what is done when > > transfering our medical measurements between different 'nodes' (may > > those > > be instances of operational units, devices or even machines). > > > > A side note: > > You should test a set of your raw data and do a histogram of all chars > > therein. Use the two chars that do show up least often as <escape> and > > as > > <delimiter>. > > Since the array is binary data, potentially any bit pattern can appear in > it. You are just making the delimiter longer to decrease the odds of a > false positive. Theoretically, I could always create artificial sample data > that would fail your approach. No. This is a misunderstanding. This is a failsafe aproach if done properly! I replace any occurence of the delimiter and of an <Esc> char with a set of two chars, where the first is that <Esc> char. This adds some extra chars to the string; the number of extra chars depends on the number of <Esc> and <delimiter> char in the raw string. After trancoding every occurence of <Esc> together with its successor is a representation of one of the original special chars as are <Esc> and <delimiter>.
> Actually (after sleeping over this), I think the programmatically simplest > solution would be to make an array of strings, then flatten it again. > > To decode: you unflatten the string to an "array of strings", then > unflatten > each string back to the numeric arrays. > > It is so much easier to work with arrays compared to searching through a > string. You're right, but with a lot of short strings (and a more slow connection) the overhead can be very important. 4 extra bytes for every String and at least 8 extra bytes for the array and its size. Greetings from Germany! -- Uwe Frenz ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr. Uwe Frenz Entwicklung getemed Medizin- und Informationtechnik AG Oderstr. 59 D-14513 Teltow Tel. +49 3328 39 42 0 Fax +49 3328 39 42 99 [EMAIL PROTECTED] WWW.Getemed.de