About the new File Type Set Editor

General
1

Using the latest 2015r3 release, I’m trying to update a (very) old program that still uses FileTypes and Creators, and I’m hoping the new File Type Set Editor (UTI’s, etc) will be exactly what I need. I’ve found this page…

http://developer.xojo.com/file-type-sets

…which talks a bit about what all the fields mean when using the File Type Set editor, but I must admit I have tons of questions left unanswered by that page. I’ve examined some Apple documents, but they’re even more confusing.

Does anyone know if there are additional Xojo documentation pages about using the File Type Set Editor (other than the one I found and listed just above)? Does anyone know if there’s a tutorial or blog entry or maybe even a sample project included with this release that includes a few FileType sets to peruse?

(When my old project is opened by 2015r3, the FileType Editor, reading my old FileTypes entry appears to set some of the fields improperly. At least, I think they are wrong, but I’m too new to know for sure. For instance, one of my file types is a totally custom file type that only my program would understand, it’s a file that my program creates and no other program other than this one should be able to open it…yet Xojo marked that FileType as a UTI-type of Imported, when I would have thought from what I’ve read it should be of UTI-type Exported. I’m hoping Xojo has more info somewhere that I’m missing about this and many other fields of the File Type Set Editor.)

Thanks for thoughts…

2

When reading old projects the imported / exported you’re seeing is a default - a guess quite literally
Old apps never provided this so the default was (in r3) to say “imported”
Thats been changed for a future release
Just switch it
If your app defines & creates the files then it should be EXPORTED

3

Defines is the most important part

4

Yes
And the new help tags on imported / exported have short novels in them about this :stuck_out_tongue:
There was some good feedback about this new thing in the beta’s

5

[quote=224536:@Norman Palardy]When reading old projects the imported / exported you’re seeing is a default - a guess quite literally
Old apps never provided this so the default was (in r3) to say “imported”
Thats been changed for a future release
Just switch it
If your app defines & creates the files then it should be EXPORTED[/quote]

Thanks Norman, I’ll do just that of course.

BTW, if you’re making changes (such as the imported/exported default), you might also check the EXTENSIONS field for validity? When Xojo opened my old project, it put my custom file extension in as “ABC”, instead of “.ABC”, with the period in front…small matter, but thought I’d mention it. (I probably DID use upper case in my original project.) I’ll change it to “.abc”, since from the examples I’ve seen you enter file suffixes as lower-case, and it will automatically recognize lower or upper case at run time. (I gather if extensions are entered only as lower case, upper case will also be properly handled as well?)

As mentioned, the file types in question are totally custom files created by my app, and are only really open-able or examin-able by my app, that being the case, would it be right to assume (in addition to choosing EXPORTED)…that CONFORMS TO should stay blank (since the file has nothing to do with anything but my own app, conforms to no standard), and MIME TYPE should also be blank?

And, as for the OSTYPE field, when Xojo read my old project, it correctly, I believe, inserted the old 4-letter filetype (e.g. ABCD) into the field. Is that important to still include for compatibility with old documents, or is that now superfluous once moving to UTI and file extension mechanisms?

6

[quote=224539:@Norman Palardy]Yes
And the new help tags on imported / exported have short novels in them about this :stuck_out_tongue:
There was some good feedback about this new thing in the beta’s[/quote]

How do I see these little short novels? I like that idea, the more help the better. I tried hovering the mouse over the Imported/Exported buttons and other fields or field labels hoping to see help info magically appear, but didn’t see any. Am I in the wrong place or do I have to turn on such help? Thanks!

7

[quote=224569:@Ken Winograd]Thanks Norman, I’ll do just that of course.

BTW, if you’re making changes (such as the imported/exported default), you might also check the EXTENSIONS field for validity?
[/quote]
File a feature request please :slight_smile:
the list of things to do in the IDE ha a very long queue and that would be appreciated to make sure it doesn’t get missed.

[quote=224569:@Ken Winograd]When Xojo opened my old project, it put my custom file extension in as “ABC”, instead of “.ABC”, with the period in front…small matter, but thought I’d mention it. (I probably DID use upper case in my original project.) I’ll change it to “.abc”, since from the examples I’ve seen you enter file suffixes as lower-case, and it will automatically recognize lower or upper case at run time. (I gather if extensions are entered only as lower case, upper case will also be properly handled as well?)
[/quote]
That’s up to the OS and how it handles the various dialogs etc where they’re used
USUALLY that is the case but if you’re on a case sensitive file system (say OS X with HFS+ case sensitive) then quite possibly not

Conforms to can, as far as I understand, still be blank BUT public.data (I think, basically means “a file full of bytes” so everything can conform to that at the very least)

File type is completely unused by OS X now
Older versions like 10.7 and 10.8 may use it but nothing newer does as far as I understand things

8

[quote=224583:@Norman Palardy] @Ken Winograd Thanks Norman, I’ll do just that of course.

BTW, if you're making changes (such as the imported/exported default), you might also check the EXTENSIONS field for validity?

File a feature request please :slight_smile:
the list of things to do in the IDE ha a very long queue and that would be appreciated to make sure it doesn’t get missed.

@Ken Winograd When Xojo opened my old project, it put my custom file extension in as "ABC", instead of ".ABC", with the period in front...small matter, but thought I'd mention it. (I probably DID use upper case in my original project.) I'll change it to ".abc", since from the examples I've seen you enter file suffixes as lower-case, and it will automatically recognize lower or upper case at run time. (I gather if extensions are entered only as lower case, upper case will also be properly handled as well?)

That’s up to the OS and how it handles the various dialogs etc where they’re used
USUALLY that is the case but if you’re on a case sensitive file system (say OS X with HFS+ case sensitive) then quite possibly not

@Ken Winograd As mentioned, the file types in question are totally custom files created by my app, and are only really open-able or examin-able by my app, that being the case, would it be right to assume (in addition to choosing EXPORTED)...that CONFORMS TO should stay blank (since the file has nothing to do with anything but my own app, conforms to no standard), and MIME TYPE should also be blank?

Conforms to can, as far as I understand, still be blank BUT public.data (I think, basically means “a file full of bytes” so everything can conform to that at the very least)

@Ken Winograd And, as for the OSTYPE field, when Xojo read my old project, it correctly, I believe, inserted the old 4-letter filetype (e.g. ABCD) into the field. Is that important to still include for compatibility with old documents, or is that now superfluous once moving to UTI and file extension mechanisms?

File type is completely unused by OS X now
Older versions like 10.7 and 10.8 may use it but nothing newer does as far as I understand things[/quote]

Thanks again Norman. Per your request, I did enter a Feature Request into the Feedback app to remind you about the period in the extension in the File Type Set Editor (at least when opening an old project).

public.data in the CONFORMS TO sounds reasonable to me. Thanks.

I assume you agree that in this case (totally proprietary type of exported file) that MIME TYPE can be blank?

Back to extensions, I hadn’t thought of case-sensitive OS’s as you’ve mentioned…so I wonder if when I am specifying extensions, I should make it “.ABC;.abc” to account for both possibilities? (The Help Page for the File Type Set Editor only shows example extensions in lower case, so I wouldn’t have thought I would have to specify both cases, but after your comment, I’m not sure. I guess I’d feel safer entering both, but not sure?

9

As far as I understand it much of the data is optional so you dont require the mime/type
Those are just additional ways the OS might use to identify your files but the primary one is the extension nowadays

I would use ONE consistent way only of ever setting an extension on your file and stick to it
Otherwise ABC might be
ABC ABc Abc aBC aBc abc AbC
etc :slight_smile:

10

Thanks Norman. I think, even though it’s not quite like the examples I’ve seen, I’ll stick with pure upper-case, as that’s what I’ve used in past version. (e.g. “filename.ABC”)

One more question if I may…I wonder just how magical the File Type Set Editor is. Since the file type I’m talking about is NOT a standard type file but a proprietary file, I’m imagining the UTI field should hold something like “com.mycompname.myprodname.mydoctype”. Is that right? And, if so, now the magic part…does Xojo create this XML addition to info.plist file in the Bundle when my application is built?

11

Yes - otherwise the OS won’t associate files with the ABC extension to your app
In fact in a future release an exported type with NO uti wont be written to the info plist because its useless

It does
Set things up then compile (debug or build) & then examine the bundle’s info.plist & look for the UTExportedTypeDeclarations section

12

Fantastic. Thanks Norman.

13

Norman (if you’re still willing)…I’m actually having some problems getting my changed over program to work correctly. Going from old MacCreator and OSFileTypes to new UTI-method. I feel pretty stupid as Xojo’s new File Type Set Editor sure does supposedly make it effortless! For some reason, if I build my program, run it as a Guest User (to make sure old files or file associations don’t mess with anything), if I create a new document, save it, quit the program, and then double-click the newly created document (which appears fine, works fine, has the right info when doing a GET INFO, showing it did get the info from my new FileType set settings), it runs TextEdit instead of my app which is supposed to open it. Not sure why yet! Still working on it…

Meanwhile, a couple of related questions if you’d be so kind…

1 - When you change a program to use the new UTI method instead of MacCreator/OSFileType, do I assume correctly that ALL references to any 4-letter Mac Creator Codes (as given to me by Apple way back when) and OS File Types 4-letter codes are no longer needed? (or ignored, if present?)

For instance…

  myfolderitem.MacCreator = mymaccreatorstring 
  myfolderitem.MacType = mymacdoctypestr

…those should be gone, right? And, the OS TYPE in the File Type Set Editor (such as where the TEXT OSTYPE might go), I used to have my old 4-char Mac OS Type for my custom document. That too, can be gone right?

2 - Also, if a user double-clicks an old document (created by my program BEFORE the switch to UTI-method of associating docs with apps, and thus created in the Creator/FileType days), would it be correct to assume that if my new UTI-using program is built correctly, all that would be required would be to append a file extension to the old document (MyFile would become MyFile.abc, and the abc extension would be enough to tell the Mac to use my newly created program to open it?

14

Hi Ken,
UTI is basically an encompassing solution, when you specify a UTI in the IDE you enter in the information the the OS can use to associate your file with your application, such as specific file extension or Mac type/creator, mime type…

In your app you still need to create the file in a way that the OS can then identify it as being relevant to your application, so you still need to use a specific file extension or Mac type/creator.

Yes, Mac type/creator is phasing out; leaving a specific file extension the most likely
Replacement, although you can still use Mac type/creator at the moment. I would recommend using the name of your app as the file extension.

I hope this helps in some way.

15

In the file type editor I’d make sure you set the old type & creator if you still have old files that used those
And set the extensions
Set everything you reasonably can
The OS will use them in some not well defined order

And make sure that your app has this new file type in the list of documents that it can / will open & that the type is Editor
You get at this list by selecting the OS X build settings item in the project and editing the File Types list there
That should then add an entry to the plist under CFBundleDocumentTypes
This is the list of types the app understands along with whether it can edit, or just view or possibly only write out files of certain types

16

Thank You!! Thanks Sam and Norman. I must admit this is frustrating. I’m trying to do it right, to switch over to what I thought is the right way, only to apparently find out, I shouldn’t really try to eliminate the old way either but do both. VERY interesting. I really thank you for your thoughts, I"ve got a lot more experiments to try. And, Norman, I do remember looking at the File Types list, and the proper document was checked so that it could be opened, but the EDITOR setting was not selected. So, more things to try. I’ll get there…still learning…

17

The interaction between both those entries in the PLIST is … well … under documented is being polite

18

Heh-heh! I hear ya Norman! Yeah, the only bummer is that I remember that that’s how it was a year ago too! I’d have thought things would have settled in by now as to how to approach it. BTW, just FYI, this whole hubbub (for me anyway) came about because my old program (still using MacCreator and OS File Types 4-letter codes and NOT UTI’s) suddenly stopped working for some users when they upgraded to El Capitan. Well, actually, the program worked fine, but double-clicked documents suddenly “forgot” to which application they belong. An easy fix was to just tell users how to use the OPEN WITH item in the Get Info of the document. Once you did that, the program continues to work just fine with double-clicked documents bringing up my program. I just figured now would be a good time (!!!) to do it right, and finally fix things (mistakenly thinking I could do away with the past and just use the new method…but I figure I’ll have to find some kind of combo of both worlds to make things work right in all cases. Still working on it.)

19

I think Apple has several hundred (maybe several thousand) developers and 1 guy writing ALL the documentation for everything including the iApps etc
To say their docs are not keeping up with changes is … charitable ?

20

And FWIW if youre going to test things out create a brand new account thats NEVER had your software on it and put a copy there
Run your software in that new account
Then see if double clicking a file from your software opens your software as expected