Broken type identifiers

I noticed something annoying whilst testing my script.
When I used

type identifier of (info for (choose file)

to get the type identifiers of files, all the pages documents return “com.apple.iwork.pages.pages”, so then I try

choose file of type {"com.apple.iwork.pages.pages"}

You would think all the pages files are selectable, but no, a select few are! What is going on! I hate these kinds of bugs!

I guess that you missed that Pages is able to create native documents with different ID.

com.apple.iWork.Pages.pages – standard package

com.apple.iWork.Pages.sffpages – standard flat file

com.apple.iWork.Pages.pages-tef – format used by Pages for iOs (or by all versions in the Cloud)

com.apple.iWork.Pages.template – template package

com.apple.iWork.Pages.sfftemplate – template flat file

I guess that your code is in fact missing the flatfiles.

KOENIG Yvan (VALLAURIS, France) mardi 9 juillet 2013 17:59:48

No, because when I work out the identifier for every file, they are all pages.pages! :frowning:

Infact I made a script to prove it is broken:

choose file of type {(type identifier of (info for (choose file)))}

When I select a certain ‘broken’ pages file, the second choose file will not allow me to choose it again!

Maybe the problem is not were you guess.

Maybe it is with “info for” which is deprecated :wink:

In fact I’m puzzled. Here it behaves flawlessly.

I ran :


choose file of type {"com.apple.iWork.pages.pages", "com.apple.iWork.pages.sffpages"}
choose file of type {"com.apple.iWork.Pages.sffpages"}
choose file of type {"com.apple.iWork.Pages.pages"}

As you may see, to be sure I use pages and Pages to be sure that it’s not case sensitive.

And I posted three screenshots in my Public Box aa :
https://www.box.com/s/8r3gym4lf2x1v0t65vo2

You will see that here the behaviour is absolutely perfect.

Maybe it would be a good idea to rebuild the LaunchServices database.

KOENIG Yvan (VALLAURIS, France) mardi 9 juillet 2013 18:49:00

In fact, it seems that I got it.

Info for as well as
tell application “System Events”
properties of theFile
(*
{type identifier:“com.apple.iwork.pages.pages”, package folder:false,"}

{type identifier:"com.apple.iwork.pages.pages", package folder:true"}
*)

end tell
return wrong values.
Above you may see that I got “com.apple.iwork.pages.pages” for an item whic is a flatfile and for an other item which is a package.

Try to use :

choose file of type {“com.apple.iWork.pages.pages”, “com.apple.iWork.pages.sffpages”}

KOENIG Yvan (VALLAURIS, France) mardi 9 juillet 2013 19:05:08

Thank you! That explains everything, I can’t believe it’s depreciated now!
I made my app a long time ago, now I’m updating it. It appears that I went to the trouble of finding the identifiers for a large collection of file extensions, I must have had a reason for it, it would make more sense to just use for example

choose file of type "pages"

but I didn’t, I can’t remember why using file extensions was a bad policy, I guess I’ll just leave it mostly how it is, silly me! :stuck_out_tongue:

info for is deprecated for years but it’s not the problem striking here.

As I wrote, info for and system events return the type identifier “com.apple.iwork.pages.pages” for packages AND for flatfiles.

The difference appear if we look at the “package” property.


my beCurious((path to users folder as text) & "Important:iWork:documents_Pages:SCR leaflet-1.pages") # flatfile
(*
--> {package folder:false,  type identifier:"com.apple.iwork.pages.pages"}
--> {type identifier:"com.apple.iwork.pages.pages", package folder:false}
		*)
my beCurious((path to users folder as text) & "Important:iWork:documents_Pages:emafre.pages:") # package
(*
--> { package folder:true, type identifier:"com.apple.iwork.pages.pages"}
--> { type identifier:"com.apple.iwork.pages.pages", package folder:true}
		*)
on beCurious(a_doc)
	info for file a_doctell application "System Events"
		properties of disk item a_doc
	end tell
end beCurious

Given that, I repeat that the only valid scheme (at least at this time) is to use :

choose file of type {“com.apple.iWork.pages.pages”, “com.apple.iWork.pages.sffpages”}

In fact I assume that I discovered that long time ago and forgot it because in several of my scripts, I use the two type identifiers and don’t rely upon this property to decide if I must expand a package to be able to decipher the embedded index.xml file.

I apologize if I am a bit late but I was fighting against an invasion by caterpillars in my garden.

KOENIG Yvan (VALLAURIS, France) mardi 9 juillet 2013 21:26:30

Don’t worry, you’re being incredibly helpful. :slight_smile: Can you think of any reasons not to just quote the extension in a choose file of type?

With iWork documents there is no problem.
If the docname doesn’t end with the name extension the apps are unable to open them.
It’s not the same with other applications.
When I used AppleWorks, I was accustomed to put the name extension (cwk) but the application was able to open files with no extension so, testing this attribute wasn’t a valid test.

KOENIG Yvan (VALLAURIS, France) mercredi 10 juillet 2013 11:22:39