on 03-08-23 11:25 PM, Bryan Lund at <blund...> wrote:
> I have noticed that the NSApplicationName key of the dictionary
> returned by activeApplication of NSWorkspace is not always the same
> name that is recognized by the rest of the system (including
> Applescripts).
>
> A good example is almost all the Microsoft and Adobe applications.
> "Microsoft Word" for example returns "Word" as it's NSApplicationName
> but will only respond to "Microsoft Word" from an AppleScript (and is
> listed as such in the dock).
>
> So my question is this: How can I get the name of an application
> reliably and expect it to be the same name that the rest of the system
> uses?
I ran into this problem some time ago and managed to resolve it to my
satisfaction. The problem stems from the fact that there are at least five
application names floating around, at least in concept: (1) the file name
the Finder sees, which in the case of an application package is the package
(bundle) name; (2) the name of the executable inside the package, (3) the
long name used in many places for display purposes only; (4) the short name
used as the application menu title and in a few other places where a long
name won't fit for display purposes; and (5) the process name of a running
application. They aren't always the same, especially in Microsoft and Adobe
products.
I believe, in general, that Apple recommends you always use the
"displayName" of an application when you're providing file names for viewing
by the user. This will ensure consistency, and it helps with some
localization issues. According to Apple, a file name should never be
localized at the Finder level, but its displayName can be localized and the
Finder will honor the localization when displaying file lists. This implies
(and Apple states) that you should not use the displayName for file system
manipulation purposes.
Here's an example of getting your own app's display name for user
interaction purposes: [[NSFileManager defaultManager]
displayNameAtPath:[[NSBundle mainBundle] bundlePath]].
I believe this is equivalent to the name AppleScript uses. It seems to work
for AppleScript in all cases, in my rather extensive testing. AppleScript
finds the real app (or process) in the file system behind your back and
supplies the ".app" file name extension at compile time if it is required.
However, technically, according to my correspondence with AppleScript
engineers about a year ago, AppleScript has been around for a very long time
and the fanatically correct technique to emulate what AppleScript does is
(1) if the application is running, use the GetProcessInformation function to
get the process name, otherwise (2) call the FSGetCatalogInfo function with
the appropriate FSRef and use the LSFindApplicationForInfo function to get
the exact file name. AppleScript, via the System Events application in
/System/Library/CoreServices, currently uses the old GetProcessInformation
function instead of the more modern CopyProcessName function, although this
may change in the future (or it may already have changed).
If you want to get your app's process name while it is running (which is
apparently what Adobe does in Photoshop and elsewhere, based on my
experiments), you can do this if you want to take the fanatic approach and
emulate what AppleScript does:
pid_t pid = <get the process identifier number somehow, e.g., from
NSWorkSpace>;
ProcessSerialNumber psn;
GetProcessForPID(pid, &psn);
/* use this in the future when System Events is modernized:
CFStringRef name;
CopyProcessName(&psn, &name);
return [(NSString *)name autorelease];
*/
// Use this currently:
CFStringRef name;
Str31 pName;
ProcessInfoRec info;
info.processName = pName;
info.processAppSpec = nil;
info.processInfoLength = sizeof(ProcessInfoRec);
GetProcessInformation(&psn, &info);
name = CFStringCreateWithPascalString(NULL, pName,
kCFStringEncodingUTF8);
return [(NSString *)name autorelease];
If you want to focus on your own app's package (bundle) name in the file
system for purposes of manipulating files, you can do this: [[[NSBundle
mainBundle] infoDictionary] objectForKey:@"CFBundleName"]. I believe this
should always return the same string as the NSApplicationName key of the
dictionary returned by NSWorkspace. NSString's lastPathComponent should also
return this string, I think.
If you want to focus on your own app's localized file name for display
purposes, you can do this: [[[NSBundle mainBundle] infoDictionary]
objectForKey:@"CFBundleDisplayName"]. I believe this should always return
the same string as -displayNameAtPath:.
This may not be the information you're looking for. It was floating around
on my screen when I saw your message, and it seemed relevant, so I decided
to post it. Hope it's helpful one way or another.
Somebody please correct me if I've got anything wrong.
--
Bill Cheeseman - <wjcheeseman...>
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.comThe AppleScript Sourcebook -
http://www.AppleScriptSourcebook.comVermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
