Write string array to tab-delimited text file without Report Generation Toolkit

[Darin.K]

I believe the link you posted refers to the fact that if you have an existing Excel file (*.xls) and try to append data to it, it will fail.  This is not so surprising since there is a lot of extra info in the .xls format.  This refers to xls files saved by Excel, and not simple text files named ?.xls.

You can write your strings to a tab-delimited file, append all you want, then open it in Excel.  If you call it a.xls, Excel won't choke on it, but will complain that the format is unexpected.   Not very pretty.

You can write the same tab-delimited data to a file and call it ?.dat (or .txt or whatever).  You can Open it in Excel and after a click or two get the data.

My preference is to change the delimiter to a comma and name the file ?.csv.  CSV files are typically associated with Excel already so you can double-click them to open in Excel.  No extra clicks required, Excel simply assumes you are opening a file of comma separated values.

Other problems appending will have to be considered pilot error and my completey unoriginal suggestion in this case is to post some code.

[mistercat]

I am not at liberty to post my employer's code on a public forum.  It would also require instruction on how to run the program etc.  As I have stated, I never made an xls file.  The files are txt.  The demonstration files were never opened in Excel.

I understand that it is much easier to have code to work with.  The array-goes-in and file-comes-out simplicity of this problem led me to believe someone else might have seen it and learned how to deal with it.  

If there is truly no one who has encountered this, I can file a engineer contact request and provide my code privately.

"You don't always have to bring the car to have your flat tire repaired."

[RavensFan]

---

@mistercat wrote:

"You don't always have to bring the car to have your flat tire repaired."

---

No.  But you do have to bring the flat tire!

[LV_Pro]

By which I think he means "encapsulate the parts you have shown us, and possibly a dummy version of the info to be written and post it". You have posted the image of the code, which we could, given time, recreate. That runs the risk that there is some default, or control setting that we might do differently. As to text files renamed ".xls" behaving the same as an actual Excel file, probably not. As you mention Excel files are carrying a lot of other info and their actual structure isn't the same as a tab or csv delimited text file. Try opening one in notepad!

[tinnitus]

"I am not at liberty to post my employer's code on a public forum"

Did you ask to him ? did you sign something about that ?

Unless your code is outstandingly innovator, just data could have value...

Regards

Tinnitus

[mistercat]

I have filed an engineering support request.

[LV_Pro]

When you have a resolution to this could you post a description in this thread to help future generations of LabVIEW users?

Thanks,

[mistercat · Accepted solution]

The source of the append problem (append to existing text file generated by Write to Spreadsheet VI and read by Read from Spreadsheet File VI) was traced to extraneous line feed characters at the end of the original file.  Once those line feeds were removed the append worked properly.  In the process of resolution, I was also informed that the number of columns in the existing file did not have to match the number of columns in the rows to be appended.  I thought that was a good thing to know.  National Instruments was able to resolve the problem after I reduced it to a simple read file/write file  VI that used my actual data files.

If you have a similar problem, you can use Notepad++ or a hex-base editor program to identify the otherwise invisible characters at the end of the file.