When to use cr() vs lf()?

Seems like I’m seeing and dealing with a lot more linefeeds in PanX. Considering only future work with PanX, with no regard to backward compatibility, what is the “best practice” for using and dealing with cr vs. lf? It was pretty simple before, just using the ¶ symbol. Is there any kind of protocol that can regain that simplicity?

Unfortunately, it’s not possible to completely go back to not thinking about cr() vs. lf() any more.

The original Mac always used carriage returns, so that’s what Panorama always did. This continued with the Carbon APIs.

UNIX has always used linefeeds, so that is what NeXT used, and then OS X followed suit.

To try to help maintain compatibility, Panorama X internally converts the linefeeds to carriage returns in most cases. But that’s not always possible. So if there is any question, I always wrap whatever formula I am using in the lftocr( function. That is an easy way to make sure that you are dealing with carriage returns and only carriage returns. (It will also convert cr-lf pairs, which are used by Windows, to carriage returns.)

Thanks, Jim. Is there anywhere I could get a deeper understanding of where this might come into play? Just curious… got into trouble typing in a Text Editor, then looking for ¶-delimited array elements, and was surprised to learn that my returns were recorded as linefeeds. How many more instances of user-input would be that way? Procedure text, maybe? if not that many I wonder if a TE setting might not be handy, allowing user to specify lf, cr or lf-cr. (?) Down the road, of course. :wink:

Mark, I think you make it more mysterious than it is. If you press the return key in Panorama X (or let’s take an Apple application like Pages where you can show invisible characters), you get the carriage return chr(13).

The problem arises when you have to import text files into your database.

Gary Yonaites offers a fantastic tool in the Panorama X Database Exchange, a great help when you need to analyze the structure of an imported text file: Reveal Invisible Text.pandb

1 Like

I’m familiar with the import problems, and really appreciate the tools Panorama has developed to handle it. What I’ve recently encountered, though (which might easily be pilot error), was typing a Return key in a Text Editor gave me a linefeed-delimited array, instead of cr-delimited, as I expected (and would have seen in Pan6). That was what raised my concern. What I’m trying to determine, if possible, is where else I might see the same behavior.

I just checked this out with a simple Text Editor Object and Mark is correct. If you press return you will get a line feed chr(10) and not a carriage return. I checked this with a manually entered list of words separated by returns as well as simply entering a return and then using a message asc(myText) and see 10 as the output.

OK, I just tested it in a cell the Data sheet, and you are right: The returns are converted to LFs.

That also applies when I copy text with carriage returns from TextEdit or Pages into a database cell.

I believe the data sheet used to convert cr’s to vertical tabs (chr(11)) to keep Panorama from jumping to the next record, as cr’s were once the end of the line. That way you could view multi-lined records in a cell. Panorama handled the conversion internally, so import/export was usually the only time I needed to deal with it. As Gary and Kurt point out, in Pan X, they are definitely recorded as linefeeds (chr(10)). Is there anyplace that Return produces a solitary cr()? Again, going forward, with new Pan X stuff, no backward compatibility concerns, might it not be better to just go with the lf’s? Importing and exporting would be their own issues, and you’d know when and what to do. It would be nice to find a path with consistency in that regard.

1 Like

Here is something to throw our there. Would it be possible to use another symbol to stand for cr() or lf() or even cr-lf pairs? Possibly a simple character like the almost equal to character produced by option clicking the X key as in . Then there could also be a function equivalent possibly named crlf(). The result would be a special character that is recognized as either a carriage return, a line feed or a combination of the two. Probably a programming nightmare for Jim but great to use in things like arrays where you don’t know for sure what the line endings might be. Just a random thought from my isolation cell.

Code written in a procedure window will recognize a return as a carriage return. Anything copied and pasted from the clipboard will have the carriage returns changed to line feeds.

That name is already used - dummy! Maybe crorlf() or something else relatively short.

This is an old thread, but as is too often the case, I’ve waded into this swamp again.

I was having a problem breaking down some addresses that I expected to have cr(). I found that pressing the return key in a Text Editor with default settings creates line feeds; not returns. I can change them to returns, then add more lines and end up with a combination of the two.

Of course lftocr( cleans it up, but it has become a bump in the road.

Screenshot 2023-06-13 at 3.16.09 PM

Unfortunately, this is a permanent swamp. Before OS X, the Mac always used carriage returns, and Panorama was programmed accordingly. Now the Mac always uses line feeds. Unfortunately the result is that now you pretty much have to always use either crtolf() or lftocr() at the start of any code that will process or detect line breaks.

I seem to have missed this suggestion three years ago. However, I think that implementing this would be impossible. Sorry it took me three years to shoot down your idea (which certainly would be cool if possible).