FileType question

I have an app that for years used the VirtualVolume as its project file format. Since VirtualVolume has been deprecated, I’ve rewritten the file format. Here are the things I’ve implemented:

  • be able to open the old files and mark them internally as being in the old format
  • alert users when saving old files that the saved files will be in the new format, can’t be opened by previous versions of the software
  • save and open new files in the new format

So far it all works. But …

Both files, old and new format, have the same extension. I have not made a new FileType because I don’t want to change the file extension. I never expected to have to change the format. All my apps just use the app name as the extension and I’d like to maintain that convention.

My question is: is it a bad idea not to have 2 clearly different file types with different file extensions? I’m thinking, probably yes, it’s a bad idea, but I’d like your input. Thanks.

While your new versions of the app can distinguish between old and new file format, your old versions cannot. If an old version of the app tries to open a new format file, it will probably crash. It would be best, in my opinion, to use a different file extension for the new format so previous versions won’t try to open it.

It also has the added benefit of giving the user a “checkpoint” when he switches versions of the app. The old version file will still be on disk in case he needs to revert.

2 Likes

Agree with Tim here for the exact same reasons.

1 Like

With a new extension, you can also have a different icon.

2 Likes

Thank you guys for responding. Although it’s more work to make a new FileType with a new extension and new icon, I’ll be going that route.

Incidentally, I did already have a file version checker in place in old versions of the app, but what I didn’t have was a “VirtualVolume checker”, because I assumed I would always be using that method. That means old versions of the app do crash when loading the new format, and that is the main reason I need to have two extensions now. Had I simply checked the VirtualVolume for Nil, I could have at least avoided the worst of the issues faced now and had the option of retaining only one extension. So, advice to self and other developers: never think “I’ll always be able to do it this way”. Try to code in such a way that things can be changed when needed. Not easy in general, but in this case, an easy thing I could have planned for.

FWIW, If you’re delivering on macOS, take the time to learn about Uniform Type Identifiers and set up your new and old types to use them.

1 Like

Yes. I still don’t know what to do with “Conforms to” for custom binary files beyond public.data ? The rest of it I have a handle on.

What I can say in regards to Conforms To, is that it allows multiple types to be grouped.

For instance PNG and JPG all conform to public.image.

If you’re on a Mac, you can see how other files are set up by simply dropping files on a file types editor.

1 Like

Thanks, that’s helpful.

But so far the new FileType is not working.

My new FileType is set up exactly like the old one but with a different name, identifier and extension, role:Edit, Rank:Owner, new custom icon. The app saves a file with the new extension. But the FileType isn’t working. The new file with the new extension has no custom icon and is NOT associated with my app in the Finder. My app also does not see these new files in an open dialog even though I have added the FileType to the dialog filter.

I thought maybe I had to first compile and run the compiled app for Finder to take notice. So I did that. No effect.

No, I don’t want to rebuild LaunchServices to try to solve this. If I have to do that then so will my customers, and there is no way I’m going to ask them to do that.

Any ideas what I could be doing wrong? Because it looks like I’ve done nothing wrong, and it simply doesn’t work. I’ve been through all this before, had forgotten how maddening this is.

I’m sticking with one FileType. The user gets a warning when saving a file in the new format, and that’s good enough. It’s (mostly) a MAS app, so users don’t revert, and projects aren’t shared. Keeping the extension the same is the better option, especially because adding a new FileType simply doesn’t work.

Make sure you check the “File type is unique to this app” checkbox and increment the version number on your app (bug version will do) because launch services will use the newest one available.

1 Like

Hindsight is wonderful
Many years ago I included a version number in the first few bytes of my custom file format.
All subsequent versions of the app included code to say ‘Thats a newer version of the file than I was written to handle. I’ll try but the results may be unpredictable’

And over time I have learned that XML as a format allows so much more future proofing.
If you have added elements that an older version of your app cannot use, it simply doesn’t see them.

2 Likes

Jeff, in fact I do basically the same. The first block of all files created with any of my apps is XML and contains a file version. The problem with this particular app is that, since I couldn’t add bytes to a VirtualVolume header, I had to put the XML in the VirtualVolume as a file. So when the VirtualVolume can’t be read, my app has no way to read the file version. I should have just made my own package binary format to begin with, VirtualVolume was just easier, so I used it. Now the VirtualVolume no longer works for saving files (it crashes). Luckily the class still works for opening files, who knows how long that will last.

Thank you Greg, I had checked that box, but I was not aware of said behaviour in LaunchServices, that’s good to know.

I’m trying to change the UTI for my app. I’ve checked the “File type is unique to this app” checkbox, incremented the bug version number of my app, and built it. My app doesn’t see these new files in an open dialog despite adding the new file type to the dialog filter. Is there something else besides this that needs to be done to change the UTI?

Could you post a screenshot of the file type editor for the type you are having trouble with?

Please show the code you are using to create the OpenFileDialog.

Var file As FolderItem
Var textStream As TextInputStream

file = FolderItem.ShowOpenFileDialog(“SCPF”)
If file <> Nil Then
If file.Exists Then

try
  textStream = TextInputStream.Open(file)