I have a field that contains tracking numbers of items we ship. It is a simple text field that the user types FedEx or UPS tracking numbers; when there are more than one they are entered as a list, separated by using the Return key. When I look at the separator character in the Pan 6 original, the separator character is chr(10), a line feed. After conversion to Pan X, that separator character is chr(11), a vertical tab. They display the same, but my attempts to parse the array assuming ¶ separator don’t work, not surprisingly. Is this intentional, or have I discovered a bug? Note that this concerns data converted from Pan 6, when I hand enter tracking numbers the usual way using the Return key to separate them, the separator is a line feed as expected.
FWIW, the ¶ character is chr(13).
Aside from Kurt’s non sequitur, deathly silence. I discovered today that this is not a bug at all, but a “feature.” To quote the release notes for version 0.1.025
That’s wonderful if I’m exporting to Excel, but I’m not. I’m not “exporting” at all, I am bringing an up-to-date Pan 6 database into Pan X to do a File>Import>Import Database to bring my X version up to date. So every text field in which the Return key was used to make a new line now has \x0B as the “new line” character instead of the \x0A that was originally inserted. This wouldn’t be so bad if all new entries I made with the Return key also embedded \x0B and I could just count on that, but instead they insert \x0A, as they did in 6.
As I said in my original post, there are many places where a procedure needs to break out the lines in a text field that are separated by the Return key, but it can be a real mystery just what the separator character is, and whether my array( function is going to break it predictably, when my database is a combination of imported data and newly entered (or edited) data, and they don’t look any different.
Can Export/Import be made a little smarter to not automatically assume that the intent is export to Excel, especially (or only) in the case where the user is doing a direct database import?
It’s not clear to me what you are actually doing. You cannot use File>Import>Import Database to import a Panorama 6 database to Panorama X – the database must already be in Panorama X before this command is used.
The 0.1.025 release notes item you mention surely doesn’t apply to what you are doing. First of all, that would only apply to exporting from Panorama X, and you clearly are not doing that. Also, Panorama 6 also converts carriage returns to vertical tabs when exporting, so this was just a fix to make Panorama X work the same way as Panorama 6 did. In addition to Excel, FileMaker also expects new lines in text files to be represented as vertical tabs, and in fact Panorama (both 6 and X) does also. When importing a text file, Panorama will automatically convert any vertical tabs encountered. So there actually is no way to get a vertical tab into the database via importing.
I don’t know of any situation where line breaks are converted to vertical tabs internally within Panorama. If you can be more specific about what exact steps you are following, perhaps this can be investigated further.
This can be true. In “classic” versions of Mac OS (Mac OS 9 and earlier), the carriage return was used as the line break character. In OS X, linefeed characters are used as the line break character. Panorama X uses carriage returns when possible, but there are some situations where linefeeds get in. If this happens, you can use the lftocr( function to make sure that all line breaks are carriage returns (or the crtolf( function if you would prefer linefeeds). This one line program will make sure all line breaks in the current field are carriage returns.
formulafill lftocr(«»)
As I mentioned, I don’t know of any situation where Panorama will generate vertical tabs. However, here is a one line program that will convert all vertical tabs in the current field into carriage returns.
formulafill vtabtocr(«»)
I am doing a very standard operation, one we discussed a couple of weeks ago. With a Pan 6 database, I make a copy, open it in 6, disconnect it from the server, then save it with a .pan extension. I move that file over to my X environment, then open it in X. The corresponding Pan X database is already there, open, from having converted it to X earlier. To update my ongoing database, I do File>Import>Import Database choosing my newly brought over Pan 6 database (which is now X by virtue of having opened it in X) to import from, replacing all records. This updates my data without touching any of the X procedures I’ve been working on. That works fine, except what had been \x0A in my 6 database (many different fields) now are \x0B. Simply that. I have no control over what goes on under the hood during that Import process, but that conversion clearly happens. Try it yourself.
Ok, there is no problem in converting from 6 to X. When brought it over to Panorama X, carriage returns stay carriage returns, and line feeds stay line feeds. No vertical tabs anywhere in sight.
There is, however, a bug in the code that imports one Panorama X database into another. Any line break character will be turned into a vertical tab. This happens even if both databases were originally created in Panorama X, it has nothing to do with conversion from Panorama 6.
It’s too late for this fix to be in the next version of Panorama X, which is about to be released momentarily. But the fix should be simple and will be in the release after that. Here is the bug report I have filed.
In the meantime you can use the vtabtocr( function as I mentioned in the last post. You’ll have to do that after the import database.