I have a Cocoa app "PDFHistory" on Mac OS X that uses the NSDocument architecture to save and load PDF files that are internally formatted specially for my app. I want to make it so whenever I save a file (e.g., "mydoc.pdf") from PDFHistory, then subsequently double-clicking on mydoc.pdf will automatically open it in PDFHistory.app. However, I don't want to make it so all .pdf files are automatically opened in PDFHistory, but rather use the system default (probably Preview.app). The .pdf suffix is a requirement, though, since I need the user to be able to e-mail the files to other users who can view the file in their default PDF viewer.
The problem is that if I set the LSHandlerRank to "Owner", then all .pdf files will be opened with PDFHistory, which is bad (since I only understand the internals of the .pdf file that PDFHistory wrote out). But if I set LSHandlerRank to "Alternate", then all .pdf files will be opened to the system default app (Preview.app), which is confusing for the user who had just created the file using my app.
Once upon a time, "creator codes" could be used to implement this sort of capability, but launch services started ignoring them back in Snow Leopard (see http://tidbits.com/article/10537). UTIs are not a substitute that provide this capability (see http://boredzo.org/blog/archives/2009-09-22/how-not-to-use-utis).
Using Finder to get info on the file allows the user to specify a specific app to use to open the specific file. This supposedly works by setting a "usro" property in a the file's resource. There is some open-source code to mimic this behavior (https://github.com/AlanQuatermain/SetAppAffinity), but is uses deprecated functions, and so would cause Apple to reject the app from the App Store. Similarly, people have posted AppleScript to set this property (https://discussions.apple.com/thread/2597365), but sandboxing would prevent me from invoking it.
Although the .pdf suffix is a requirement in order to be able to send the files to users on other systems/platforms, I considered trying to have the suffix registered with two extensions as ".phistory.pdf", which would allow "file.phistory.pdf" to be opened in PDFHistory, but "file.pdf" would be opened in the default PDF viewer. However, this simply didn't work: it appears that the final suffix is the only one used by launch services, and everything before that is ignored.
So is there any way to have my app be the default app for opening files that it created itself?
Related
I have a sandboxed application that uses a document format which can contain embedded filenames. E.g. some of these referenced files are for image files which the user selects in order to associate the image file with data stored in the document. Whilst such images will sometimes be located in the users pictures folder, sometimes they are elsewhere. The document format itself cannot be changed for portability reasons (it is shared with an existing Windows version of the app).
In order for the app to be able to access the files whose names are embedded within the document, when the user selects a filename (using nsopenpanel) to be stored in the document like this, the app also creates an app-scoped security scoped bookmark for each such stored filename. It then stores these bookmarks by serialising them to another file. When the app runs again it loads its previously serialised bookmarks and uses them when accessing the 'embedded' filename and that works fine.
But when I copy such a document (and its associated serialised bookmarks file) from one Mac to another, it doesnt work, even though all the files the bookmarks refer to are known to exist on both Macs. What happens is that whilst the app opens the document file ok (after the user selected it with an nsopenpanel), and successfully reads in the serialised bookmarks from its associated serialised bookmarks file (which again the user has selected using nsopenpanel), and even though the exact same filenames that the bookmarks refer to are known to exist on the other Mac (and can be accessed by the user through finder etc), the sandboxed app still cannot access them. Resolving the bookmarks seems to fail.
The question is: are app-scoped bookmarks restricted to only working on the Mac on which they were created? If I cannot move an app-scoped bookmark from one system to another, how else can I achieve the effect I want without forcing the user to have to manually re-select every such 'embedded' filename with an nsopenpanel?
Tried to find the answer to this question in the Apple docs without success.
I take it it goes without saying that security-scoped bookmarks can only be used by the app that creates them.
No, because if this were possible, developers could save security-scoped bookmarks to sensitive files/directories on their own computers and then deploy their apps and have access to those same sensitive files/directories on other peoples' computers.
I am working on a Mac app. I ultimately want to use default app icons within my app. From the Info.plist and the Resource folder of an app I can get the .icns file and convert that to the image format I need. But I need to know the default application associated with the particular file extension, if any.
So how to get the default application that the system currently associates with a given file extension?
Don't go digging in other apps' bundles. It's always best to work at the level of abstraction that suits the question you want to ask. If you want to get the icon that the Finder (or a Mail attachment, etc) would display for a file of a particular type, use the NSWorkspace iconForFileType: method.
I think what you're looking for is part of the OSX Launch Services: LSCopyDefaultApplicationURLForContentType API. This returns the info on apps that can open specific Uniform Type Identifiers. There's also a similar API called LSCopyDefaultApplicationURLForURL to check which app opens a specific known file.
I am distributing my OS X application on individual USBs and, for this reason, everything must be self contained.
The app itself lets users input information and then saves this information to an existing text file (specifically an ObjectDB database). Herein is my problem.
I'd like to keep this text file inside the app itself (i.e. inside the Content folder) so it's out of the way and can't be deleted by the average user. But once the app is signed, it seems the text file can't be altered with any new information without getting flagged by Gatekeeper. Is this really the case? There's no way to store data files within apps now?
I'd appreciate any suggestions. Thanks.
Yes, you are correct. If you modify the application package, the signed package is no longer valid. That's kind of the purpose of signing a package.
Your options are to store the text file in a temporary folder on the user's computer, or to instruct your users to disable gatekeeper (don't do this).
I have a legacy app (minimally ported from Mac System 7 to Carbon to Cocoa) where users are reporting that the kMDItemKind metadata, as reported my mdls, of text files saved by the app seem to be set to "Microsoft Excel 97-2004 workbook". The legacy file creator and type should have been set to 'cBaS' and 'TEXT' (as was registered with Apple in ye ole ancient days), and the legacy file extension is ".bas".
What sets the kMDItemKind metadata of saved files under Mac OS X?
How do I make sure that the kMDItemKind is set correctly when saving these text files, so that my app will open them?
You can't directly set the kMDItemKind of a file. It is derived from other metadata. The file type code 'TEXT' is quite generic. The creator code is ignored these days. The file extension is probably what the system is relying on.
Unfortunately, in your case, you have multiple apps which handle .bas files. Which of those the system picks is somewhat arbitrary and subject to change. Launch Services is assigning the kind based on which would actually be used and how that app defines the document type or UTI that's matching the file extension.
Normally, you should leave the association of files with specific applications to the user. If they want to change it, they can do so with Always Open With accessible in the Finder's File menu or context menu when the Option key is held down. Or they can use the Get Info menu.
Your best bet would be to switch to using a more-likely-to-be-unique file extension
This is only under windows env.
As I know windows os identifies associated application of a particular file by file extension.
Like wise each file (binary) starting with corresponding symbols ("starting symbols"). For an example .JPG starts with ÿØÿà. Let say I open this .JPG file in a Hex editor or a Text editor and then I change that starting symbols into another file type. for an example I can change ÿØÿà to .Eߣ (.mkv). So when I double click on the .JPG the Windows Photo Viewer says there are some errors or similar message. So I need to get some information about the application that tries to open that kind of a file. If I can, I need to open that file using the application that associated with "starting symbols".
Briefly when I open .JPG I need to open a default video player .mkv files. But It may not work for this example. Because I changed only the "starting symbols" of my .JPG.
Please give me any idea to do this.
Thanks!
When you encrypt the file, give it a new extension. e.g. Picture.jpg becomes Picture.encrypted-jpg. You then register as the handler for encrypted-jpg, decrypt the file, then launch the normal jpg handler.
When the shell is asked to perform a verb on a file, the shell does not use the contents of the file to determine which app to pass it to. The file extension is what determines how the file will be treated.
You wish to use the contents of the file to influence which app processes a shell verb. In order to do so you would need to create a launcher app that reads the file header and then decides which app to pass the file on to. You would assign your launcher app as the handler app for all file extensions that you were interested in.
Although you could do this, it would be much easier just to set the file extension appropriately.
The proper way to do this sort of thing is to replace the files with reparse points.
The downside is that this involves writing a file system filter driver, i.e., an operating system extension, which is a whole level of trouble above and beyond ordinary application programming. (Since Windows already does file encryption, I doubt it would be worth the effort.)