3

Updated 4-9-2013 This is a total repost of my earlier question. As I have learned much more about Launch Services, UTIs and the depreciated creator codes, I feel I can better ask the question from scratch.

Problem Description:

We have an application that was designed for Legacy Mac 9.xx which still runs on Snow Leopard(with Rosetta). The application uses bundled files We developed our new app for Snow Leopard and beyond. The issue is that Launch Services does not properly associate the new app based on the plist configuration we are currently using and I need to know what I am doing wrong.

If I right click on the bundled document and select GetInfo, I can associate the bundled file to either the legacy app or the new app and it will work as I expect it to. I believe that is because snow Leopard still used the Creator Code technology for this type of association. If I tell the file to associate itself with the old legacy app and I press "Change All" , Launch Services will correctly associate all files of that type and it will work as expected. If I tell the file to associate itself to the new App and I select "Change All", The app will open but the files will not. From what I can tell, Launch services is assigning a dynamic UTI to the app and it when the file is clicked on, The OS doesn't know what app to use.

I found a couple of posts out there that seem to suggest Apple might have made some design mistakes in the new UTI methodology. One post here shows how to add an array of string file extensions to the ExportedUTIs dictionary of the new apps pList. This gets the app to function correctly, but that is not going to solve the problem; If we allow our users to name their files anything, we cant predict in an array what their file extension is going to be. We need Launch Services to operate correctly strictly with the UTI code, or some how get the OSType code to work.

Post about UTI's

Once the new app decides it can't open it's related file, I have to open the LanchServices.plist, delete the entry and restart the lsregister database. Then I can once again open a file with the new app(by associating it without pressing "Change All").

I am attaching some images to the app plists , the bundled document plist and the Launch Services entry:

Old App Plist

New App Plist

plist from the Bundled Document

The Launch Services entry for the new app

Any help and our guidance is much appreciated.

Mike

Updated : 4/16/2013

The link to the post about UTI's I provided also includes a link to an open source software app called RCDefault app. This app will associate your APP to the given file based on your choice of UTI's , file extensions, OSType codes, and file types. Strangely, this app is able to associate the file to the app based on the UTI's structure that is provided in our plists.

Is it possible this is all just a bug in Launch Services for Snow Leopard for this specific scenario and Apple has chosen to just ignore it at this point(considering they no longer support Snow)?

Miek
  • 1,127
  • 4
  • 20
  • 35
  • Are all of these steps required to reproduce the problem? Do you have any working way of opening the file in the new version of the app? – paulmelnikow Mar 13 '13 at 22:44
  • Yes, If I associate only one file to the new app, it opens. Its,only when I try to set the association to all like files then the problem occurs. Once the problem occurs, I can only undo it by deleting the com.apple.launchsercives.plist file in the /Users/Library/Preferences dir. I believe this file does not get updated unless he option to "Change All" is selected. – Miek Mar 14 '13 at 02:50
  • Alright. Would you clarify in the question what happens when you try to open the file through Finder? You mention drag-and-drop and but I'm not sure I see what validateDrop has to do with it. Are the file types identical between the two apps? – paulmelnikow Mar 14 '13 at 02:53
  • @noa Whether the file is dropped onto the applications NSOutlineView, or it is double clicked on, or I use the finder and double click on the file, the behavior is all the same; the problem only occurs when the com.apple.launchservices.plist adds the application(global association)into its file. If the association is not global(just for this file), then the launchservices.plist file is not edited by the system and everything works as it should. – Miek Mar 14 '13 at 18:57
  • Are the file types set up identically in the two apps' info plists? – paulmelnikow Mar 14 '13 at 19:00

2 Answers2

1

You're missing your CFBundleTypeExtensions. Create a CFBundleTypeExtensions of type Array, and Item 0 should be your file extension.

You're also missing your CFBundleTypeName, which is the alias type that the file will use. Makes it nice and pretty. :)

Reference (CFBundleDocumentTypes): https://developer.apple.com/library/mac/#documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html

Derek
  • 1,170
  • 12
  • 16
  • Where to I create CFBundeledTypeExtensions and the CFBundeledTypeName ? in the bundled File or the app? If the App, under which area? – Miek Apr 12 '13 at 21:26
  • In the info plist under the Documents section. Quickest way to see what I mean would to be creating a new document-based application and compare with your plist. – Derek Apr 14 '13 at 00:17
  • I see what you mean , but it does't make any difference. The only way I can get the app to properly associate itself with Launch Services is to add an array of file extensions to the (Xcode names)Exported Types UTI section under the Equivalent Types dir , which ironically , isn't a UTI at all. As I stated before though, thats not gonna cut it. Thanks for the link to the keys reference. I'm still studying that. – Miek Apr 15 '13 at 16:18
0

Its been awhile since I originally posted this, but just in case this is interesting to anyone else I have made some additional discoveries:

This problem doesn't have much to do with trying to be compatible with a legacy app and an OSX app. The bundled file contains a creator code and an OSType code. As long as these two items exist in the legacy apps plist it will open when ever it is asked to, globally or individually.

The problem appears to be trying to include the ostype code in the newer apps plist as an equivalent type under Exported type UTI's.

The only solution that appears to work is to add the array of file name extensions as an equivalent type as @Derek mentioned to begin with.

That is the only solution that solves this problem. Ironically this violates apples human interface guidelines which states to some degree that a user should not be forced into file extension restrictions.

It appears that UTI's only work on non bundled documents(files), which is also supported by a few posts out there that basically say apple really screwed this up. What is the point of worrying about UTIs if in the end you need the array of extensions anyway?

Miek
  • 1,127
  • 4
  • 20
  • 35