03-25-2013 09:33 AM
I can create an array of multi-line text entries that my program can then pick cells and compile them into a list of text.
I would like to be able to Save the array as a file, then change my program to read in the file.
If I use the Save Spreadsheet file vi, the data is corrupted by the carriage returns within the cells and the data read in is messed up.
Can someone recommend a way to save the array that preserves the carriage returns?
03-25-2013 10:13 AM
As far as I know, this cannot be done automatically with the basic VIs from the palletes. I would convert the [LF] into another group of characters (likely "\n") and then save the text array to a CSV file. Don't forget to escape any good "\" string with an extra "\. Regular expressions would work really well:
Just make sure you parse your entire array of strings with this.
Olivier
03-25-2013 11:27 AM
I guess you are not using the proper delimiters while writing and reading. Can you attach the VI you have created before? (Please attach in 2009 version)
03-25-2013 11:33 AM
It is definitely an issue wity delimiters but I don't know of any way to tell LabVIEW not to process [New line] as "next row" when reading from a CSV file, hence my example of replacing that specific character.
03-25-2013 12:04 PM
You can always use Spreadsheet string to Array and Array to Spreadsheet string to convert a line of text to array of words. In the same way you can create array of lines by using newline character as a delimiter. So while writing to a file use the appropriate delimiters and convert to spreadsheet string and then write to a text file so while reading it use the same delimiter so that you would read it in the same way. Excuse me if you already know all these things
03-25-2013 12:37 PM
If I understand the original problem properly, there is an array of multi-line strings. When the "array to spreadsheet string" function is used, evertything looks good but when the "spreadsheet string to array" is used afterward, the operation creates a lot more of entries in the array, all of which are single lines.
The problem I am trying to work around is that in a 2D array, LabVIEW Array to Spreadsheet string function automatically uses EOL to separate Rows. If you cannot change this behaviour, then you must escape the EOL. The help content below seems to point in this direction as well.
I've added a better example of the behaviour.
From the help file:
Array To Spreadsheet String Function
Owning Palette: String Functions
Requires: Base Package
Converts an array of any dimension to a table in string form, containing tabs separating column elements, a platform-dependent EOL character separating rows, and, for arrays of three or more dimensions, headers separating pages.
03-25-2013 12:56 PM
I would use the XML format instead of the spreadsheet string way. If the file is not going to be read by human directly, then you can simply pass the array to "Flatten to XML". You also can create your own xml format.
03-25-2013 12:57 PM
I appreciate the help. You may be wandering off course slightly.
Take a blank vi front panel and create an array of strings. In some of the cells of the array, put two lines of text.
I would like to write that array to some file.
Read in the file just created, either another vi or frame of a sequence, and see if the new array matches the original array.
I have not found any way to do it.
03-25-2013 01:01 PM
Yes I understand. I have another way around but for that you need to save the array size also.
03-25-2013 02:00 PM - edited 03-25-2013 02:04 PM
This last entry from Mr. P@Anand is very interesting.
I added a Write Text File and Read text File in the middle to provide the storage functionality and had a working program...sometimes! I put the two halves in separate frames of a sequence and added a Wait Until Next ms Multiple to add a slight hesitation between the write and read to stabilize the operation.
Thank you
The boolean check in the bottom right reulst in False! Text1 has an extra space/non-printing character that does not appear in the saved text file or the read-in text.