'fileexists' function behavior

Appears the ‘fileexists’ function doesn’t recognize PanX files. In playing with the routine below appears the function recognizes Pan6 and other kinds of files. Other’s experience with this function??

local myFilePath
choosefileDialog myFilePath
IF myFilePath<>""
IF fileexists(myFilePath)
message "File found!"
message "File NOT found"

Pan X databases aren’t exactly files. They are packages that contain several files. If you replace fileexists( with folderexists( in your procedure, it should work.


Interesting, and, indeed it does! Thanks!!

Bill A.

The problem with this is that 90% of users are going to see a Pan X database as a file. Also, what if you want to check real folders, excluding Pan X databases?

A note for Jim - would it not be better if fileexists( did indeed recognise Pan X databases?


I’m wondering if there is some way to make use of the unix file statement with this problem. Used with the -b option it will return information about the file. If the file does not exist it will return something like “cannot open `/Users/garyyonaites/Desktop/starimages.gif’ (No such file or directory)”. A Panorama X file would simply return “directory” as would an application bundle or a folder. Standard documents would return various information about the file. A Panorama 6 file would return “data” while other files would return more information as is the case with an image file and a pdf file.

I used this simple test code to see the various results. The file path was simply dragged into the procedure directly from the Finder. Note that I used the unixshellstring( function that automatically properly encodes the dragged-in file path.

thepath=unixshellstring("/Applications/EazyDraw Folder")
message shellscript({file -b }+thepath)```

One of the options of the ChooseFileDialog statement is OpenPackages, so it would seem that that statement at least knows a package when it sees one.

The following AppleScript returns true when a Pan X database is chosen, and false if a regular file is chosen.

set theFile to choose file tell application "System Events" package folder of theFile end tell

Indeed it would be better, and this is on my private list of issues to investigate. Ok, I’ve added a public bug report:


By the way, this problem isn’t limited to Panorama X databases – there are many applications that use packages, which all of Apple’s system calls see as folders (also called directories), not files. After some quick investigation, I see that I have already fixed a similar issue with the listfiles( function. So I think it shouldn’t be too hard to get this working with the fileexists( function also.

At https://bitbucket.org/jimrea/panoramax/issues/538/fileexists-function-doesnt-work-with you report,

“The fileexists( function now correctly recognizes that a package is a file, not a directory. This includes Panorama X databases, applications, etc.”

It isn’t working for me, on either of two machines, if I omit the path details and just provide the name of a file in the same folder. Could somebody please check whether fileexists("name of file in same folder") returns True or False? For me, it’s False.

The active database was on the desktop, and I had two other, unopened, databases on the desktop. One was a Pan 6 database, and the other was a Pan X database, so one was a file, and the other was a package. In both cases it correctly reported that the file had been found. In both cases, I used the file name without the path.

Thanks Dave - that means that I now have two crazy, mixed-up computers.

Michael: Did you remember to have the file extension as part of your file name?

I don’t believe that’s necessary but I tried it anyway - makes no difference.

Yes, the fileexists( function absolutely requires the extension, as it has no way of knowing what the extension is – you could be asking about a .jpg file, .txt, .html, .pan, .pandb, anything.

And if I have “Show all file name extensions” unchecked in Finder Prefs? Will that affect it?

And, with my brain clearly in neutral, I tested it with a .pan extension instead of .pandb.

All is now OK. My apologies Bill for doubting your sage advice.

No. That setting only affects how filenames are displayed in Finder. It doesn’t affect Panorama or any other program.

If you think about it, suppose you have these three files in the same folder:

  • flower.jpg
  • flower.png
  • flower.gif

Now if you ask Panorama if "flower* exists, it will have no idea which of these files you mean. So you must include the extension.

This is also why I recommend always turning on the *Show all file name extensions" option in the Finder Prefs. If this option is off, my example folder is going to look like it has three files with the same name. Really, I don’t understand why Apple even has this option, and if they must have it, why it defaults to off. At least they do give you the option so you can make it work correctly.

Oh, this has been so – without extensions – since the classic Mac OS 1.0, and for later decades this was a differentiation between “the Mac way” and “the Windows way”. It took years to accustom myself to file extensions, and finally, it was Panorama X that convinced me to use “Show File Extensions” in the Finder now regularly.

I endorse all of that Kurt - but I still find Panorama 6 and Panorama X extensions annoying. I’m sure I’ll get over it.

Another thought on this topic - the problem arose when I migrated a Panorama 6 file to Panorama X. The fileexists( function worked fine in Panorama 6 without an extension. Has this been a deliberate change in Panorama X?

It worked fine if the file didn’t have an extension, but if it had one, you needed to include it.

With a file named “Utility.pan” in the same folder as the active database, I ran this procedure in Panorama 6.

if fileexists(folder(""),"Utility")
    message "Yes"
    message "No"

The message was “No.” Changing that to

if fileexists(folder(""),"Utility.pan")
    message "Yes"
    message "No"

Changed the message to “Yes.”