I have a client who downloads .csv file from a web cart. When trying to open the file with “Openfile dialog” in Panorama 6, selecting the file throws a message that says “Only Overvue, Panorama and text files can be opened” or something like that. If I open the file in Excel, then save it as a .csv file, Panorama will open it when it is selected via the “Openfile dialog”. Can anybody think of why this might be the case?
Thanks.
CSV can have different field separators, depending on (inter)national number formats. E.g. here in Germany CSV files are not comma-separated, but semicolon-separated. I think Excel is more flexible in handling all those (inter)national format differences than Panorama 6.
(Panorama X knows about those international differences, but I still have to take care myself whenever I as a German Pan X user want to import a comma-separated CSV file.)
The only way I can duplicate this is to use an openfile procedure statement with the file as its parameter. This produces the error you describe.
Local folder,file,type
OpenFileDialog folder,file,type,""
if file = "" stop endif
OpenFile "+"+folderpath(folder) + file
This does not.
OpenFile dialog
If what you are doing is something like the first one, you can replace OpenFile, with OpenTextFile.
Changing all the commas to semicolons, didn’t produce the error. It just caused everything to be imported into a single field.
Thanks Dave. I was definitely using OpenFileDialog folder,file,type,"" , but I would think that should still recognize a .csv file, which is why I made the original post.
I ended up using OpenTextFile, then import that file into the original file, then close the temporary file.
Jeff, I’m not sure you understood Dave’s suggestion. The problem is not the openfiledialog statement, it’s the openfile statement. You should replace that with the opentextfile statement.
Local folder,file,type
OpenFileDialog folder,file,type,""
if file = "" stop endif
OpenTextFile "+"+folderpath(folder) + file
You mentioned that the user “downloaded a .csv file”, but did they give the downloaded file a name that ends with .csv? I’m guessing they didn’t, and that’s why openfile could not recognize what sort of file it was. The openfile statement tries to figure out what kind of file it is based on the extension, if there is no extension, or an extension it doesn’t know about, it won’t work. (It can also try to figure out the type of file from the type/creator code, but web browsers don’t support that old MacOS technology.)
The opentextfile statement does not try to figure out what kind of file it is. It simply assumes that any file you pass to it is a text file.
Because of this ambiguity, I stopped using openfile a long time ago. If I want to open a database, I use opendatabase. If I want to open a text file, I use opentextfile. This wasn’t a problem back in the Mac OS 9 and earlier days, back when all files had type/creator codes. But OS X deprecated type/creator codes, so few apps use them any more. Instead we all really need to put extensions on every single file will create, otherwise programs won’t be able to figure out what’s in them. It’s really a move backwards by Apple, but it is in line with what DOS and UNIX do, so it does make it easier to move files from platform to platform.
A really unfortunate choice Apple made is to hide the file extension of files in the Finder by default. Whenever I first set up a new computer, one of the first things I do is change this preference so that file extensions are shown. Otherwise it’s a constant source of confusion. Unfortunately, few users follow this practice.
Jim, I understood what Dave said. I was using OpenTextFile in the past, but I wanted a temporary database to run some procedures on the imported data before bringing it into the permanent file. As I said, I ended up using OpenTextFile to make a temporary file, then appending that data to another temporary file with the procedures, then bringing the data into the multiuser permanent file.
What you said about the extensions is interesting. It’s actually the exact opposite situation. The file they download has the .csv extension, which OpenFileDialog folder,file,type,"" won’t open. When I open the .csv file in Excel, then save it as a .csv file, the name doesn’t have the extension, but OpenFileDialog folder,file,type,"" will open it.
OpenFileDialog doesn’t open anything. It just gives you the dialog, and sets the file, folder, and type parameters. It’s the OpenFile, or OpenTextFile command that follows that does the actual opening. The OpenFile command needs a type code. A file downloaded from the internet doesn’t have one. Apparently, Excel is giving it one when you save from there.
When you use OpenFile dialog Panorama 6 will look at the extension, but otherwise it does not.
OpenTextFile will also let you use “+” to append or “&” to replace.
Sorry Dave, I’ve been busy. To follow up, you are correct, OpenFile is what opens the database. I have the type code set to “TEXT”.
The client’s file does have the .csv extension when downloaded. They have a shopping cart that they log into and create a .csv export of the orders since their last log in. When that file is downloaded it is named “orders.csv”. If I “Get Info” on the file, the Name and Extension are “orders.csv”. OpenFile will not recognize it as a text file in Panorama X.
If I open the file in Excel and save it as a .cvs file, it is named “orders”. If I “Get Info” the Name and Extension are “orders.csv”. This one will open.
It’s no big deal; just seems curious.
What I believe to be happening is this. When you download the file, it has the .csv extension, but it does not have the TEXT type code. OpenFileDialog will recognize files with that extension as text files, so the file won’t be greyed out in the dialog, and you can choose it. But then the OpenFile command ignores, the extension, and does not know there even was a preceding OpenFileDialog command. All it knows is that it has been asked to open a file that has neither a TEXT or ZEPD type code, and you get the error message that you got.
Excel apparently saves the file with the TEXT type code, so it will open that one.
What do you mean you have the type code set to “TEXT”? You cannot set the type code of a file that is downloaded from a browser – the browser would have to do that. And the browser is clearly not doing that. Excel, however, apparently is.
In Panorama 6, the OpenFile statement relies on the type code to determine the file type. It doesn’t care what the extension is, only the type code. Recall that the original Mac operating system didn’t have or use extensions at all, only the hidden type codes. If a file doesn’t have a type code, then the OpenFile statement assumes it is a Panorama database. When it tries to open your file as a Panorama database, of course it doesn’t work.
To get around the problem of files with no type codes, the OpenTextFile statement was created. This statement assumes all files are text files, no matter whether or not they have a type code or an extension.
The solution to your problem is to use the OpenTextFIle statement with the + or & prefix to import the data into your existing database
Note: In Panorama X the OpenFile statement works differently – it uses the extension instead of the file type (because that’s what OS X programs are supposed to do). So if you were programming this in Panorama X you could use the OpenFile statement with no problem. However, the OpenTextFile statement would also work in Panorama X.
I took that to mean the last parameter in the OpenFileDialog statement was “TEXT”.
Could be, but of course as you pointed out the OpenFile statement knows nothing of that.
Dave was right. I was referring to the last parameter of the OpenFileDialog statement.The downloaded file is greyed out in the open file dialog; the Excel saved .csv is accessible.
I fixed this weeks ago. I was just replying to Dave’s point that a file downloaded from the internet doesn’t have a type code. I mistook that to mean an extension.
