On Windows, if your app is associated with a specific file extension, if a user double-clicks a file of that type Windows starts another instance of your app, which can then determine the file that launched it by inspecting ParamStr(1).
On OS X, if your app is associated with a specific file (via creator code or extension), if a user double-clicks this file OS X checks to see if your app is running - if not, it starts it - then sends an open-doc Apple Event to your app with information about the file that was double-clicked. Double-clicking can occur at anytime your app is running or another app could send an open-doc event to your app to have it open a file. The timing of these events means that putting this information in ParamStr(1) doesn't make sense the way it does with an OS X console app. Instead, this open-doc event needs to be handled by an event handler that your app installs. I've attached code with an example handler. OS X programmers can test this by calling InitOpenDocHandler in your main form's FormCreate method, passing a pointer to a method of the form that has the required parameter signature. When a file associated with your app is double-clicked, this event handler will call your form's method, passing the file's path. To associate a file with your app, select the file and press Cmd+I, then choose your app in the Info dialog that pops up. The question is where this event handler code should go. If it's put in the Carbon widgetset, then programs would need to add its unit to their uses. Normally we don't specify widgetset units in our apps, only the LCL units. There probably isn't anything that corresponds to this in the LCL, so it would be unique to the Carbon widgetset. Any ideas or suggestions? Thanks. -Phil
CarbonOpenDoc.pas
Description: CarbonOpenDoc.pas
