How to know the no. of bytes in a String Control Function?

[jtc]

Hi,

I would like to know the no. of bytes for a certain String Control Data.

For instance, if i have a String Length Function, on the left is a String Control and on the right is a Length Indicator.

If i will type coordinates, i.e. 9.25,4.25 on the String Control it will show 9 on the Length Indicator. I think 9 do not mean 9 bytes but

only a length. Is there any function in LV that will tell me the total bytes of the data on the string control?

Appreciate for any advise.

Thanks a lot.

[tst]

The term "total bytes of the data on the string control" is kind of meaningless in this case, since a control has a lot more data associated with it than just its value (e.g. the string length, the control properties) and once the string is put on a wire, it is seperated from the control and loses that data.

If you want the number of bytes a string takes in memory, then the answer is [len+4], since LabVIEW uses ASCII and saves the string length as an I32. There are options to work with Unicode, but they aren't officially supported and I think that only Asian languages can currently have more than one byte per character.

There is a private (meaning you can't access it) control property called Bit Accurate Data Size, but I wouldn't be surprised if it returned the string length*8.

Why do you actually want to know this? What's your actual goal?

[Wiebe@CARYA]

Each character in a sting control is a byte, so the length of the string is
the number of bytes. The LabVIEW strings don't support Unicode. If they did,
you'd be right: the number of characters don't have to be the number of
bytes.

If you're not convinced, you can flatten the data. But the flattended data
will be a string... You can also cast the sting to an array of u8's (use the
Type Cast function). Then get the length of the array.

Regards,

Wiebe.

[jtc]

Thanks tst for your kind reply.

Here is what i am trying to find/goal.

I will be using wireless receiver for my system. The wireless receiver have some signal strength ranges; 95dbm @ 1Mbps (mega bit per sec), 90dbm @ 11Mbps, 82 dbm @ 24 Mbps and 75dbm @ 54 Mbps. Ofcourse i prefer to have lower data transfer rate so that my signal strength is best.

I will be sending coordinate data/s via wireless communication using string controls. But i do not know how big/heavy is my coordinate data

If i can know how many bytes or mega bytes the data i want to send then i will be able to transfer it to bits or mega bits(8 bits = 1 byte) thus i will know which setting i can use for the wireless receiver. And if the data is too big then i have a basis to redesign my data transfer to suite a better signal strength.

Thanks for your help.

[tst]

In general, one character is one byte. This can be changed with Unicode, but as mentioned, Unicode isn't officially supported with LabVIEW, so you can ignore it for now.

Of course, if you'll be using IP based communication, you'll get overhead from the communication protocol itself (probably TCP) which will considerably increase the amount of bytes you send in any case.

Incidentally, if you want to optimize your bandwidth consumption, you can probably do so by manipulating the data to take up less space, but I doubt you'll get even to 1Mbps with the data you'll transfer.

[jpeters]

In general, one character is one byte. This can be changed with Unicode, but as mentioned, Unicode isn't officially supported with LabVIEW, so you can ignore it for now.

Have to nit pick here.  1 character != 1 byte.  On Japanese systems LabVIEW uses Shift-Jis which may use more than one byte for a character without Unicode.  LabVIEW doesn't use ASCII -- it uses ANSI characters which doesn't imply that 1 byte == 1 character.

[tst]

Fair enough, although I did mention Asian laguages as the exception in my original reply.

[Wiebe@CARYA]

So when a multy byte Japanese character is used, will the string size return
the number of bytes, or the number of characters?

Regards,

Wiebe.

[jpeters]

Length is in bytes not characters.  This is one of the reasons that dealing with multibyte text (Japanese) can be much more difficult than single byte character sets.

Jeff P

[jtc]

Hi Tst, Wiebe, Jpeters,

Thank you very much for all your inputs.

I will not be using japanese characters, only numbers, comma, sines (-), and maybe parenthesis.

I made a sample VI. Its in LV 8.5.

Is this correct then?

Thanks again.