Paths Relative to the Current Database goofed by other apps?


#1

I ran a lengthy program unattended. I heard the OS reading a Panorama X message stating that the file for a certain database did not exist. I returned, saw the error message and also saw that one of my utility programs had put up a dialog offering to upgrade itself since I’d left. I was able to determine Panorama X had stopped at an opendatabase statement for that database. I’d only listed the filename for the statement’s path, but that database was in the same folder as the running procedure’s database and I don’t think my code had changed what database was active. That database opened fine from the finder. I closed and reran the procedure without change and it completed without error.

Could the upgrade dialog from the utility program have changed in what folder PanoramaX was looking, so that it couldn’t find the database to open using the shorthand path? If so, such third party dialogs being unpredictable and not rare, this could be an intermittent recurring problem. Other than not using paths relative to just the current database, which I find very convenient, would there be a way to avoid this hypothetical extra-PanoramaX triggered error?


#2

That seems very unlikely. Other programs should have no effect on the internal operation of Panorama X. In macOS, each program operates independently and should have no effect on any other program (other than thru deliberate communications via AppleScript).


#3

Good, I’m glad the update dialog was a coincidental red herring! I’d feared PanoramaX was reading something from the system which could be changed by having a foreign window appear on top of it. Another intermittent bug from unintended/unexpected consequences of my own code is something I know how to approach and eventually squish.