This has happened several times with files I’ve put into the /Application Support/PanoramaX/Libraries/ folder, edited and removed to the desktop (see Custom statements - #7 by admin):
Sometimes it also says that the file doesn’t exist. Quitting, restarting, re-installing all have no effect. Is there a secret potion to fix it? Otherwise I’m faced with a huge amount of work to relocate the contents to a new database, testing at each step to see where the problem might lie.
Moving files to atypical locations should only be done when there is an absolute reason to do this. Later editing and moving files should happen with consideration that an open file should never be moved while open. Close the file, and for absolute safety, quit the app, before accessing the file again. The location of a file is maintained for reasons that benefit you but you can work against yourself by not paying attention to the ‘rules’.
Robert Ameeti
All covered - there’s nothing atypical about the desktop as a file location, Panorama X was quit before moving and there are no “rules” - it’s my file and I can put it anywhere I like.
Robert’s advice was all excellent – in the past. Certainly it is excellent advice for Panorama 6.
Panorama X uses Apple’s standard document handling code for loading and saving files. Apple’s documentation for this indicates that this code will work correctly even if you move a file in the Finder – while the file is open. Before today, I had never tried that. Oddly, I had been thinking about this just a day or two ago. So, just now I tried it. Lo and behold, it works. I opened a database, then went to the Finder and moved it to the desktop folder. Made changes to the database and saved it, no problem, the file on the desktop changed. Command-clicked on the icon in the window and it showed that the file was on the desktop.
I even tried using the dbinfo(“folder”,…) function, and it correctly returned new path for the file in the desktop. So, in Panorama X you can move a file even when it is open, and Panorama X will immediately recognize that this has happened and everything will just continue to work. I believe this should work for any modern NSDocument based application.
That still leaves the mystery of why Michael Kellock is running into a problem saving his database. Unfortunately, I have no idea why that is. A downside of using Apple’s code is that when there is an error generated by Apple’s code, I have no idea what the problem is or how to fix it. And this error is coming from Apple’s code. You might look in the Console and see if any additional information is output there when this error occurs. Maybe there is some sort of permission problem?
Since apparently you can open the database, one thing I would recommend would be to save this database as a blueprint – use File>Export>Blueprint. This will save the structure of the file, including all forms and procedures, as a collection of text files in a package. The blueprint file is saved in the same folder as the database. You can then create a brand new database with the same structure by using File>New>New Database from Blueprint. The blueprint doesn’t include the data, so if you need that, you’ll have to export it separately as a text file and re-import it after creating the new file from the blueprint. The end result will be a brand new file with no connection to the original, but all the same structure.
Geek note: Blueprint files work great with git for source control. I use that with all the coding in Panorama X to keep track of what has changed. Whenever I’ve completed significant work I export a blueprint and then commit those changes to the git repo. I realize what I just said will make no sense to most of you, you can just ignore it. But someone in the future is going to read this and say “hey – that’s fantastic.” Here’s an example of how a change I made in _DatabaseLib yesterday appears in the git repo (I’m using an app called SourceTree to work with the repo). As you can see, I can easily see exactly what was changed and when.
Among other things, I use this information to compile the release notes that are included with each release. I also use it if something goes wrong to see what exactly was changed.
LOL
One of my mantras is “Just because you can, doesn’t mean you should.”
While it may be both permissible and not cause problems most of the time, I’m still not comfortable with it working in all situations. I like to stick with what works. I will not be advising my clients to move their open files as they are not likely to have any clue if their app is a properly coded 100% NSDocument based application.
It is the little things that get in way all too often. As in I just was using the OpenFileDialog and the FileName that gets returned has the .pan extension as the suffix of the file name, yet the OpenFile statement wants nothing to do with the .pan extension and requires the suffix to be stripped off. It is these little things that bite us while in transition from one standard to another or one version to another. Don’t look for trouble as it will come your way plenty often when you really don’t need another problem.
Robert Ameeti
The described problem certainly suggests the Permissions could be the issue.
I’m confused by this statement. If you are using Panorama 6, it should work with or without the .pan extension. If you are using Panorama X, it will open .pandb files with or without the extension. If you are trying to open a Panorama 6 file (.pan) extension then you must include the extension.
As far as I know, code that uses OpenFileDialog and OpenFile will work exactly the same between Panorama 6 and Panorama X. That is certainly the intention.
I will not be advising my clients to move their open files
I probably wouldn’t either. In this case, however, the point is that this doesn’t seem to have anything to do with the original problem. Another point is that Apple is looking out for customers to protect them from themselves. I don’t think this ability to move documents behind an application’s back has always been there – I think maybe it goes back to 10.6 or 10.7. The cool thing about using Apple’s code for things like this is that your application can get new features like this “for free” simply by running on a newer system.
Working in Pano 6…
Interesting. Originally, I had this…
OpenFileDialog LFolder,LFileName,LType,""
LRemoteFileName = LFileName
OpenFile LRemoteFileName
and it did not work for me. Then I changed it to this…
OpenFileDialog LFolder,LFileName,LType,""
LRemoteFileName = LFileName[1,-5]
OpenFile LRemoteFileName
and it worked.
I’ve changed it back to the original, and that too works now. But that contradicts with your statement that Pano 6 requires the extension.
Can I just reiterate that I quit Panorama X before moving the file.
I quit panorama, cleared the console, opened, changed and saved the file (still on the desktop) and this single message came up in the Console:
“23/01/2017 10:32:03.243 am com.apple.xpc.launchd[1]: (com.apple.imfoundation.IMRemoteURLConnectionAgent) The _DirtyJetsamMemoryLimit key is not available on this platform.”
Does this tell us anything other than DirtyJetsam being a great name for a rock band?
Thanks Jim - that worked fine and the file has no data so that wasn’t a issue. Now I’ll try to reproduce the problem.
And Robert, your advice is always appreciated.
I think Jim was referring to opening a P6 file with PX.
Correct, that’s what I meant. It’s not needed when opening a P6 file with P6.
Any ideas on this?
I did a google search on this (which is my go to technique for weird stuff like this), it appears this is a common message. This is the most useful link I found, but you could always do a google search yourself. Sounds like this probably has nothing to do with Panorama or your problem.
