Can I pass Chinese characters in a queue (Do queues support Unicode)?

[leesi]

I am aware that there are a number of tools to allow the use of Chinese characters within LabVIEW. I have successfully built an application where I am able to switch between English and Chinese so that all screen text, buttons, multi-column list boxes etc etc are updated correctly.

However, I do all my event logging using queues. When I dequeue the an item, I want to write it out to a log file (i.e. a ".txt" file) but the resulting file contains rubbish instead of the Chinese characters.

As an experiment, I created a simple VI that reads an array of Chinese text and writes it to a text file and this works fine. But, as I say, if I try doing this using queues, I just just get rubbish.

Any help would be very much appreciated.

Lee

[SteveChandler]

A queue supports any datatype. Can you post an example VI?

[leesi]

Hi Steve

I've tried to replicate my situation but now I get a different outcome. It seems that I am now getting Chinese characters in my text file. However, you'll see from my code that I'm trying to Tab seperate each item (Date, Time and Message) but this doesn't seem to be working. Likewise, I want to end each line with a Carriage Return but that doesn't seem to be working either.

I think I'm going to have to take it on the chin that something I'm doing in my "real" application is preventing me from seeing the Chinese characters in my log file.

I've attached the sample VI along with a sample logfile from my "real" application so you can see what I'm getting.

I can't really see what I've done different between my sample VI and my application. The only real difference is to do with the Byte Order Mark. In my application I've tried the following :-

1. Inserting this once at the beginning of the entire log file
2. Inserting it once at the start of each line of the log file
3. Inserting it before each piece of text excluding the date and time
4. Inserting it before every message item including the Tabs and Carriage Returns

None of the above produce anything I can use.

Thanks for responding so quickly.

Cheers

Lee

[SteveChandler · Accepted solution]

I don't know much about Unicode but the issue could be the EOLs inserted by the write to text file. From the help for this function:

This function appends platform-dependent, end-of-line (EOL) characters to the elements of an array even if you right-click the function and remove the checkmark next to the Convert EOL shortcut menu item.

I changed it so that a string is built in a while loop using a shift register and concatenate strings. That way you are just writing a single strnig instead of an array of strings with the EOL. Again I don't know if that is even the issue.

Also you should take advantage of dataflow and not use the sequence structure. I modified your program to do that. Also the queue datatype specification cluster should be a typedef.

[leesi]

Hi Steve

Yes, I noticed the EOL issue with the write to text file function. I also wondered if this was pertinent.

I take on board your comment about dataflow rather than sequences. I put the sample together in somewhat of a rush as I was just leaving the office for the day. I tend to steer clear of sequence structures if they are not necessary.

I ran your VI but, as you probably noticed, it returns (pretty much) the same result as mine so I'm no further forward. I'm not seeing the tabs nor are the date and time appearing correctly. What I want to see is something like this :-

26/01/2012         09:46:00        系统启动

26/01/2012         09:47:00        系统启动

26/01/2012         09:47:00        系统启动 etc etc

Thank you for your input

Lee

[leesi]

Hi Steve

I cracked it last night. I basically created a file using Notepad that had the contents exactly as I wanted them. Then I opened this file in a Hex Editor to see the layout of the bytes. Straight away I noticed the difference between my manually created file and the file generated from my code. In a nutshell, it was to do with the EOL conversions that "Write to Text File" employs.

I switched off the EOL conversion (by right-clicking the "Write to Text File" object) and also replaced the "End of Line Constant" with a "Carriage Return Constant" and a "Line Feed Constant", padding each one with the additional 00 byte.

Now it works perfectly.

Thanks for the pointer.

Regards

Lee

[RavensFan]

You really should mark Steve's message as the solution to your problem as he was the one who told you to look at the end of line character.  First you will  need to unmark your solution by going to the options menu to the upper right of your message.

[leesi]

I will most certainly do that although technically, Steve's response wasn't the solution to my problem.

As you can see in my earlier post, I'd already suspected that the EOL switch may have some bearing on the outcome. Not only that, but I also had to modify my code to achieve the desired results. Simply switching the EOL conversion off wasn't the complete answer.

Still, consider it done.

[leesi]

Just out of interest, the LabVIEW Help on "Write To Text File" function says, "This function appends platform-dependent end-of-line (EOL) characters to the elements of an array even if you right-click the function and remove the checkmark next to the Convert EOL shortcut menu item".

You're correct that Steve mentioned this but I'm not using arrays to generate my text files so wouldn't have considered that option at first as one wouldn't think it relevant.

[SteveChandler]

The example dequeued elements in a for loop and used autoindexing to create an array of strings. Either a string or an array of strings can be wired to write to text file. If you wire an array then each element gets an EOL appended to it. That's what I was referring to.