Well yes, you can do it manually as you were earlier. But why?
There’s a standard format and a standard associated behavior for document titles (dimmed icon for dirty docs, ability to drag to Finder, and ability to control-click and see file’s hierarchy, and open from the Finder there). Do you have good reason to potentially annoy the user by doing something different from every other doc-based app?
Cocoa programmers have a saying: Don’t fight the frameworks. It’s usually good advice.
This is what I did to obtain what I want, without fighting the frameworks and to stay in the Guidelines:
-- NSDictionary and NSFileManager are declared in properties as classes
.
set theFilePath to |path| of theFileURL as text
set fDic to NSDictionary's dictionaryWithObject_forKey_(1,"NSFileExtensionHidden")
manager's setAttributes_ofItemAtPath_error_(fDic,theFilePath,missing value)
.
Ex-Toolbox programmers also have a saying: “Where there is a will, there is a way”.
I don’t think that works if the Finder preference is set to always show extensions.
But it still strikes me as a bit odd: the default behavior is to show the extension, unless the user turns off the extension for the file, and you’re having the app turn it off rather than the user, so they you’re setting their behavior in the Finder as well.
You’re right, Shane, and finally it’s just a detail: many people don’t even notice the extension and what it means (maybe former Windows users can’t live without extensions), and my user remains free to show the extension of its wrapper, and even to ruin its contents if he wants to.
But this extension affair is the tree hiding the forest, as my problem is only partially solved: I have at last my wrapper, but I can’t tell the finder to use it as a regular folder, open it and writing files into it. Do I have to use Cocoa methods instead of Applescript to do this?