I would like to associate the last installed version of my Mac OS X application with a certain type of file. A little experimentation shows that the info.plist file seems to be read and interpreted by the operating system when launching the application, not when dragging the application bundle to the disk. Apple's documentation on run-time configuration does not say much on that topic.
Is there any way, using a simple .dmg
image as installation medium, to make sure the system associates that particular file type with my newly installed app without having to launch it first?
I should clarify that I want this to be done automatically during the installation (I don't want my users to have to do it themselves).
When a user drags an application into the Applications folder, the system should register it with Launch Services automatically. See Application Registration in the Launch Services Guide.
You can do that by typing apple-I on the file you want to associate the application with, use the little box called "Open with..." and select your app. You can check the little box below "Change All..." to make the change for all similar files.
Although Tony's information is correct -- also explained here -- (that dragging the MyApp.app
to Applications
will register with Launch Services automatically using information from Info.plist
xml file and setup file associations), it doesn't fully answer the question about file association.
If people follow these instructions, they'll have their application open, but no specific file opened.
[...] make sure the system associates that particular file type with my newly installed app
File association is a bit different on Mac as when compared to other platforms. Most platforms, when *.foo
is registered with myapp
, when MyFile.foo
is double-clicked, it dispatches something along the lines of:
/path/to/myapp MyFile.foo
And although you're free to use this technique on command line on a Mac with success, it simply won't work through Finder and also won't work through double-clicking the associated file on the desktop.
Asked and answered here:
https://stackoverflow.com/a/19702342/3196753
Some claim is this approach is advantageous over conservative document-open-file-handling in main()
because it "only opens one instance of the application". Regardless of the reasoning behind this decision, it further complicates matters from a C++ perspective.
- The 108 page PDF available here (warning, this is marked as "legacy", linkrot may occur).
- Relevant documentation from apple's developer portal available here.
- Qt's approach is documented here.
From qt.io:
When a user double clicks on a file in the Finder, Finder sends an Apple event to the application associated with the file and asks it to open the file. If the application is not running, it is launched and then the request is made. The advantage of this approach is that there is only one instance of the application running.
On Windows, this usually is done by launching the application and passing the name of the file as a command line argument. Looking at many files results in launching many instances of the same application. (The QtSingleApplication component, available as a Qt Solution, addresses this issue.)
Qt 3 does not provide an abstraction for handling Apple events, but it is straightforward to add support for them in your application using Mac's Carbon API. Let's assume we have an application called XpmViewer that displays XPM files (an X11 image format). The main window class declaration follows: [code snippet removed]
(BOOL)application:(NSApplication *)theApplication
openFile:(NSString *)filename
Handling Mac OS X file open event BEFORE C++ main() executes
AEInstallEventHandler handler not being called on startup