Replace string with line break

[Mocte117]

Hello all. I'm trying to replace a word with a line break, but I'm not getting any results (image 2). Can anyone tell me what I'm doing wrong?

I have a text file, the file has three columns and more than one line, in the third column there is a string with several words and the word JUMP. My idea is that the text file is read, and the word JUMP is replaced by a line break so that the file looks like image 3.

Code:

image 1

Image 2

Image 3

[OneOfTheDans]

You're using LF (\n). You need to use CR+LF (\r\n). It's called "End of Line Constant" on the palette.

[cordm]

What kind of loop did you use?

How does auto-indexing work for this type of loop?

When will the loop terminate?

Spoiler

replace the while loop with a for loop

[Bob_Schor]

One of the first things I learned on the LabVIEW Forums (quite a while ago) is that Index Array doesn't need you to wire each index if they are all sequential.  As you did, I numbered them 0, 1, 2, etc., but unlike you, I used all of the entries.  A kind LabVIEW user said not to bother putting numbers in for sequential indices -- LabVIEW will "assume" that's what you want to do.

I will admit I haven't actually tried this, but it seems to me that the entry in Column 3 is a single String, and stays a single String.  So what you want to do (which you can do with Columns 1 and 2, as well) is search each string for "JUMP" and replace the sub-string (if it is found) with <CR><LF> (which appears on the String Palette as "End of Line Constant".  You can use "Search and Replace Substring" with your input string as the "Input String" argument, "JUMP" as the "Search String", the "End of Line Constant" as the "Replace String", and the Offset as (initially) 0.  Read how this works (read the detailed Help).  Note in particular the three outputs, and ask yourself what would happen if you did this in the following three cases:

• a string without "JUMP"
• a string with a single "JUMP"
• a string with more than one "JUMP"

How would the outputs look in each case?  Can you think of a clever way to take the single "Search and Replace Substring" and (by adding a LabVIEW Structure) make it handle all three cases?

Doing this exercise by yourself will teach you not only about LabVIEW's String operators, but also how to build tiny test routines (such as the one I just describe) that can lead to "Aha!" moments when you really start to "get it" ...

Bob Schor

[altenbach · Accepted solution]

---

@Mocte117 wrote:

Hello all. I'm trying to replace a word with a line break, but I'm not getting any results (image 2). Can anyone tell me what I'm doing wrong?

---

Your loop can never stop, so the ItemNames property will never get written, no matter how long you wait. The only way to stop your VI is by using the abort button. In that case, the code stops whatever it is doing and won't continue. It never get to the property write. Dataflow principles!

In addition your output array stored in the indexing output tunnel will grow by millions of empty string elements every second. Ultimately you'll run out of memory.

[altenbach · Accepted solution]

Here's one possibility:

(Except for the mentioned dataflow problem, your inner code was functional (but a bit awkward). A linefeed \n (LF) is perfectly OK. I have no idea why others try to distract with mentioning CRLF. That's not the problem and just makes the string longer without any benefit. The only problem where details such as the distinction between  /n, /r, /r/n, /n/r, etc. still matters is probably with serial communications.)

Also, don't add useless decorations if you can just color the background instead. Don't focus on decorations at all until the code is complete.

[paul_a_cardinale]

As a side note: The End of Line Constant, , isn't necessarily CR LF.  It is platform dependent.  It could be CR, or LF, or CRLF.

[altenbach]

---

@paul_a_cardinale wrote:

As a side note: The End of Line Constant, , isn't necessarily CR LF.  It is platform dependent.  It could be CR, or LF, or CRLF.

---

Yes, historically almost all combinations have been use in different OS (Details), but we only care what can run LabVIEW here.

This all goes back to the old tractor and teletype printers where two different motors were responsible for the two directional movements. You could even do ASCII art by doing CR without LF and overprint for a darker shade, or go down one line without changing current column position.

LabVIEW indicators only require a \n on any supported OS and creating artificial OS dependence can increase the string length on windows without benefit and might even wreak havoc on poorly designed downstream code because the length can now differ.

Even windows notepad is now more forgiving. Early versions had problems displaying unix text files with correct line breaks..

Some of you might still remember certain FTP modes where newlines got converted based on OS (... and destroyed any binary file if accidentally set!) 😄

[billko]

---

@altenbach wrote:

---

@paul_a_cardinale wrote:

As a side note: The End of Line Constant, , isn't necessarily CR LF.  It is platform dependent.  It could be CR, or LF, or CRLF.

---

Yes, historically almost all combinations have been use in different OS (Details), but we only care what can run LabVIEW here.

This all goes back to the old tractor and teletype printers where two different motors were responsible for the two directional movements. You could even do ASCII art by doing CR without LF and overprint for a darker shade, or go down one line without changing current column position.

LabVIEW indicators only require a \n on any supported OS and creating artificial OS dependence can increase the string length on windows without benefit and might even wreak havoc on poorly designed downstream code because the length can now differ.

Even windows notepad is now more forgiving. Early versions had problems displaying unix text files with correct line breaks..

Some of you might still remember certain FTP modes where newlines got converted based on OS (... and destroyed any binary file if accidentally set!) 😄

---

"Still remember?" a year ago we were trying to figure out why an FTP upload was inserting EOLs in our upload.  We knew why (FTP in text mode) but not how.  Turns out that the script was logging in a user named "binary".  I'll let you guess the rest.

[paul_a_cardinale]

---

@altenbach wrote:

---

@paul_a_cardinale wrote:

As a side note: The End of Line Constant, , isn't necessarily CR LF.  It is platform dependent.  It could be CR, or LF, or CRLF.

---

Yes, historically almost all combinations have been use in different OS (Details), but we only care what can run LabVIEW here.

This all goes back to the old tractor and teletype printers where two different motors were responsible for the two directional movements. You could even do ASCII art by doing CR without LF and overprint for a darker shade, or go down one line without changing current column position.

LabVIEW indicators only require a \n on any supported OS and creating artificial OS dependence can increase the string length on windows without benefit and might even wreak havoc on poorly designed downstream code because the length can now differ.

Even windows notepad is now more forgiving. Early versions had problems displaying unix text files with correct line breaks..

Some of you might still remember certain FTP modes where newlines got converted based on OS (... and destroyed any binary file if accidentally set!) 😄

---

The Teletype terminal that I used (1970's) was the model 33 which had a single motor.