On 08-05-07, at 06:54, Craig Hunter wrote: I've been using various means to get the resource path of my app bundles for the last few years, the most useful being "resource path of main bundle". Other ways include variations on "path to me". These all seem to provide the path of the app when it is first launched, which theoretically should be fine. Unfortunately, I have found that a small number of users like to move apps while they're running, which invalidates the resource path determined at launch time. And then many of the "do shell script" calls in my apps go haywire as the files they're referring to are not in the right place.
Does anyone have an idiot-proof way to determine the app bundle path in real time that would be practical for on-the-fly location of resources to be used in do shell script calls? Right now, I found I can sort of handle the situation by doing a "path to me" call within a try block at top level handlers in my script, and when it fails, I put up a dialog telling the user the app was moved and needs to be quit now. But if there's an efficient way to avoid the situation altogether, that would be even better.
I've also been running into users who skip the advice to install my apps directly in /Applications and stick them in folders with names like "~~ Bill's <freakin> Wonderful! $oftware Folder ~~", which wreaks havoc with do shell script when it tries to refer to resources in the app bundle, but I think that is best handled with a warning at launch time, since I can detect it right away. But if anyone has ideas on that, I'd like to hear them as well. Generally, the judicious application of quotes (or quoted form of) can handle most meta-character that have special meaning in the UNIX shell, but there are some oddball situations.
You may need a custom class and 'call method' for the following. Depending on the nature of your bundles, the CFBundle calls from CoreFoundation can locate resources from arbitrary URLs. There is also CFBundleGetBundleWithIdentifier() so you can get the Carbon bundle and then get it's URL or path. However CarbonBundles are not toll-free-bridged to NSBundles so don't try to load any code from those calls while in an NSApplication run loop.
If you want to locate your containing bundle from an arbitrary C symbol, search the Carbon-Dev list for a function listing by me that is called something like dl_bundle. It was quite sometime ago I posted it.
Philip Aker
|
