saved file doesn%27t match original text

[altenbach]

---

@rickford66 wrote:

Augh, I found one of my read/writes that still had the convert EOL checked.  How embarrassing.  I went through them twice and didn't see it.  Apparently I have to check things 3 times.  Thanks everyone.  Sorry about that.

---

No problem. Notice that the actual icon changes depending on the eol setting, so things should be immediately obvious, even without right-clicking. 😉

[crossrulz]

This is why I much prefer to use the Read/Write Binary File instead of text file.  Byte arrays are much easier to deal with than strings, mostly due to the "convert end of line", which is on by default.

[rickford66]

I did notice that the icon changes, but for some reason I didn't see it.  I know I looked right at it.  It was only when I was stripping it down to post the code that I noticed it, then I looked back at my original code and there it was staring me in the face.  I don't know how I missed it because I was looking for it.

[rickford66]

When you use binary files and store as a byte array, is it then enough to just say that the format is a byte array?  I've worked with binary files before but always had to provide information on what the file format was.

[crossrulz]

---

@rickford66 wrote:

When you use binary files and store as a byte array, is it then enough to just say that the format is a byte array?  I've worked with binary files before but always had to provide information on what the file format was.

---

Actually, you want to read with the data as a Byte and read everything (count = -1).  For the write, you need to make sure the "Prepend Array/String Size" is set to FALSE.

[rickford66]

Ok, I'll keep that in mind.  Thanks.

[altenbach]

Stored as byte array or stored as string is binary identical and I already mentioned how to use the binary file IO with strings. 

Read/write it as whatever is more convenient and matches the rest of the code. In this case you are apparently dealing with strings, so "converting" to/from byte arrays is just a detour. In this case I would stay with the text file IO with convert EOL disabled. Fewer paramteres needed. 😄

[Darin.K]

For me this is one of the most annoying API choices that NI has made.  It is as if they studied my code and carefully crafted things so that I have to do extra clicking no matter what I am trying to do.

Most times I want to read a mixed file, some text, some binary, I want to read it all (usually) or large chunks (4K+).  Two things I do not want to do very often are convert EOL or read things one byte/cluster or whatever at a time.  These are the default behaviors for the two functions.  Either I go the text route and right-click or the binary route and create constant.

I tried to suggest the following:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Default-Count-for-Read-From-Binary-File-Should-be-1/id...

Setting the default count for the binary function to -1 so you can drop it on the BD and read your file, as is, in its entirety.  No more creating a constant.  When you want a fixed count, it probably is not going to be '1' so you are going to be wiring that terminal anyway.

The other option is to make 'convert EOL' default to off for the text functions.  Then they argue that nobody will know about it, hidden feature, blah blah blah.  I say hide that sucker.  Why on Earth should that be a compile time decision anyway?  At least make it a boolean option.  That way you know it exists because there is a terminal 'Convert EOL (false)' and it can default to a more reasonable value IMO.  The Pre LV7 (I think) version did it this way.

As it now stands, NI can make all of the arguments they want about why they did what they did and I will stack it up against the number of solutions and Kudos I have around here for saying 'Right Click and turn off Convert EOL'.