spreadsheet string to array eol

[Garvacious]

I am trying to use the Spreadsheet String to Array function and it seems to be interpreting both "\n" and"\r\n" as EOL characters.  This is a big pain as I need it to ignore "\n" only and only index the array based on "\r\n".  What is confusing to me is that an EOL is supposed to be "\r\n", so why is this function indexing a new element on anything but an EOL character?  

Strange behavior?  Or am I missing something here?  

[Garvacious]

I probably should mention that I am working in LV 8.5 under Windows... sorry

Message Edited by Garvacious on 09-23-2008 12:09 PM

[Garvacious]

Here is a VI I created that does what I need- this is what I expected the Spreadsheet String to Array function to be able to accomplish...in case anyone else is having this problem...

[G-Money]

Garvacious-

Could you post a screenshot of your code so I can see what's happening? I have attached an example of how you would use this vi. The delimiter should only accept the \r\n. In my example it does. If you change the spreadsheet string constant to /n instead of /r/n then it will return the whole character instead of the desired name. Try this out and post your code and we will be better able to help. Thanks!

[G-Money]

Sorry, I was in the middle of writing your post when you put up your code. Does your code work for your application?

[Garvacious]

Sure, my code provides a good workaround but I am wondering, is the Spreadsheet String to Array supposed to index a new line on \n as well as \r\n?  Or is this a bug?  If not, the help file for it is misleading.

Note that I am not talking about the "delimiter" here, that should still be "\t".  It is the EOL character I am referring to (indexes a new line or "2nd dimension" in the array), which cannot be changed in the Spreadsheet String to Array vi.

[G-Money]

Gravacious,

Could you post the file you are trying to parse up? Basically, I don't run into the same problem you are having so maybe it has something to do with the file you are using. The EOL character acts as an "expression" so if your EOL was "LabVIEW" and the file had "Lab", it should not be parsed because it's not "LabVIEW". I don't doubt what you are seeing but I am trying to recreate on my end. This is where your file would come in handy. Thanks!

[Dennis_Knutson]

I think I understand what Gravacious is seeing and can easily reproduce. Say you have the string ('\' Codes on) of "1\t2\t3\t4\t\r\n5\t6\t7\t8\r\n". The output will be a 2D array of 1,2,3,4 in the first row and 5,6,7,8 in the second. The second row is caused by the windows EOL character of \r\n. If instead of \r\r after the value 4, you have a \r, you get exactly the same array out and the question is why because \r is not the windows EOL.

I think part of of this issue can be explained by the help in some of the old file functions (ie.e. Read Lines From File). There, there is a button to convert or not convert EOL. The help, in part says "The system-specific end of line marker is a carriage return followed by a linefeed on Windows, a carriage return on Mac OS, and a linefeed on Linux. The LabVIEW end of line marker is a linefeed." Because the cross-platform compatiblity of LabVIEW, it uses it's own definition of EOL and would treat a \r, a \n and a \r\n all the same.

[Garvacious]

Dennis has explained my problem perfectly.  So it seems like maybe \r, \n, and \r\n are all treated as EOL in that function.  What makes this bad for Windows users is that often a spreadsheet file will contain carriage returns inside of individual cells (problem I am having) and this gets interpreted into the array incorrectly becuase of the behavior mentioned above.  Oh well, at least there is a fairly easy workaround.