Replace EndOfLines: Strings end in EndOfLines?!?

Probably unrelated, but TextArea converts line endings to chr(13). If you pull text from a TextArea, it will have that line ending.

1 Like

Wow! That is interesting! I agree that it’s not related to the OP’s issue, so sorry about veering off topic for a bit. But I found a further complication: On Mac (not Windows, don’t know about Linux), any text that is prefilled in the IDE will use CR line endings, but text either entered in the running application or added in code (with EndOfLine) will have LF line endings. On Windows it’s always CR. So screwy!

I do see that the CR issue in Windows was reported and verified in 2015, and like most non-super-critical bugs has yet to be addressed. :pensive:

I vaguely recall that there was a change on the Mac side of things that went from the old CR to LF. But I’m not a Mac guy, so it didn’t affect me. It does highlight the importance of ReplaceLineEndings when you’re dealing with user input.

Maybe some pictures will help:

All is fine here, no surprises:

Inserted EndOfLine, now you can see one character beyond last in Text pane, analyzer shows it’s a carriage return while binary view is unfazed by all this:

Exact identical thing with chr(13):

Of course this could be something the IDE adds, but why only when there already is a carriage return in the string and not if there isn’t?

But the second one is identical. What are we illustrating?

Oh well, that explains why my XML has carriage returns, because i load it into a text area for editing and then do some replacing before i use them elsewhere…

Correct, the second one is identical to the third one but both of these close with carriage returns which are definitely NOT in the code while the first one doesn’t, even though i follow the same procedure of copying the text from the text thing in the debugger.

[quote=“Patrick_Wania, post:25, topic:66697”][/quote]


Did you get that from withing Xojo ?

When I say I saw an EOF earlier it was a part of the editor that was showing the file literally had ended, not that there was an added 0x0D

What tool are you using to view that data as I’m not seeing the data when inspecting the clipboard using Free Clipboard Viewer?

It looks like a bug since you have never (visually) defined the ending Carriage Return Unless:

  • You are showing a different variable we can’t see that here.
  • You copied the string including the CR in there

What is this “analyser” thing to which you refer? If it’s not part of the IDE, what is it?

So here we find the real culprit. Your “analyzer” tool is adding that final CR. As I and others have already stated, we’re not seeing any extra CR being added, just like the IDE binary view shows.

So, the solutions to the two main issues covered in this thread are:

  1. Always use <text>.ReplaceLineEndings(EndOfLine) on any external text OR text from a TextArea, when you need to perform some type of processing based on line endings.
  2. Use RegEx to remove all leading spaces from all lines, which is more compact (and probably more efficient) than your looping process.

Somehow i feel like i have started some kind of panic here or else i cannot explain the amount of interest as well as the extreme need to explain this away.

So one last try:

If you look closely at my screenshots 2 and 3, you will notice an arrow pointing at something BEHIND what should be the last character in the ide text debug pane thing which isn’t there in the first screenshot (the one without any carriage returns – i guess i should have added an arrow to point out that there is nothing there?). I noticed that and this is the only reason i even selected all of the text and copied it into an analyzer i wrote a while back which does nothing other than list the ascii code for every single character it finds. And no, my analyzer is not adding carriage returns, or there would also be one in the first screenshot!

Now i am totally fine with the suggestion that this is a bug in the ide text pane thing and now that i know this, i will no longer look out for ghost characters tagged onto my strings … :slight_smile:

The reason we are keeping on this topic is because we’re trying to understand where the extra 0x0d has come from because no of us see it but on the off chance that there’s a undiscovered bug somewhere we’d like to find out where it has come from.

I’ve noticed that extra character that you mention, you can also get that in example one by dragging across the string with the mouse instead of using ctrl+a or by putting the caret at the start of hello world and pressing shift+end. However, after the copy, I’ve checked the clipboard using an external tool that shows raw clipboard data and the extra 0x0D isn’t there.

I’ve just pointed a tool I use to inspect windows controls at the text box in the debugger and I don’t see the extra 0x0d in there either.

As we’ve now discovered that you’re using a custom tool to check the data, we can only assume that the problem lies there.

Now that we know its a custom app made in Xojo, here we go, I knew it reminded me of something that was in the back of my mind <https://xojo.com/issue/51479>. It’s a known bug from 2018!!

Extra line added when copy and pasting from and to a textarea

When you copy and paste from and to a textarea an additional blank line is added to the content but only if that content is over multiple lines.

This perfectly explains why you only see it on the multiline example above.

1 Like

I had just finished testing and coming to the same conclusion. I had searched for relevant bugs, but as usual the sheer volume of bugs makes it difficult to find truly relevant ones. Thanks for the reference.

But I noticed that Robin placed this bug in the IDE/Inspector category, when actually it’s a TextArea bug that affects our applications as well as the IDE. This will probably hinder (even further) it’s attention by the developers.

Patrick, if you would design your “analyzer” to take the text directly from the clipboard instead of from a TextArea (which I assume is what you’re doing), then you would see that your selected text does not really contain the extra CR.

Also Patrick, this might explain why you see (or think you see) that your XML file uses only CR line breaks. If you are using your analyzer to determine this by pasting the XML into a TextArea, then it is converting the line breaks to CR only.

The text area bug does explain the perceived anomaly on both ends: Inside the ide as well as my analyzer. This is what it must feel like to be stuck in a confirmation loop :wink:

And Jay, knowing this, it does make sense to analyze the clipboard rather than whatever was copied to the text area. This is a good occasion for an update of my analyzer!

Thanks everyone for your help and insight!!!