Getting the type code of a file under OSX

[Joel Guillod]

Hi Eric,


> So, I propose another approach:
> As usual, is this one the last one?
> :-)
> [...]
> function CreatorAndType pFilePath
>    local tDefaultFolder,tFile,tCreatorType
>    -----
>    if the platform <> "MacOs" then return "Error: filetype not
> supported"
>    put the defaultFolder into tDefaultFolder
>    set the itemdel to slash
>    set the defaultFolder to item 1 to -2 of pFilePath
>    put the detailed files into tFile
>    filter tFile with urlEncode(item -1 of pFilePath) & ",*"
>    set the defaultFolder to tDefaultFolder
>    set the itemDel to comma
>    put item 11 of tFile into tCreatorType
>    if tCreatorType = empty then return "Error: could not determine
> the filetype"
>    return char 1 to 4 of tCreatorType,char 5 to 8 of tCreatorType
> end CreatorAndType


This is the function handler I will retain for own my file&folder  
library:

/**
@usage local tCreator,tType; if file_getCreatorAndType 
(pFilePath, at tCreator, at tType) is not empty then
@result The returned value will not be empty if the pFilePath file  
does not exist. Also tCreator and tType will be set to the creator  
and type of the file pFilePath; when empty, the creator and type are  
not set for the OS plateform.
@version 30.7.2005 - Modified by Joel Guillod from a proposal by Eric  
Chatonnet.
*/
function file_getCreatorAndType pFilePath, at pCreator, at pType
   local tDefaultFolder,tFile,
   put the defaultFolder into tDefaultFolder
   set the itemdel to slash
   set the defaultFolder to item 1 to -2 of pFilePath
   put the detailed files into tFile
   set the defaultFolder to tDefaultFolder
   filter tFile with urlEncode(item - 1 of pFilePath),"*"
   if tFile = empty then return "Error: could not find file"
   set the itemDel to comma
   get matchtext(item 11 of tFile,"(....)(....)",pCreator,pType)
end file_getCreatorAndType



Remarks:
- I dont want to have the handler to rely on one specific platform.  
So I dont check that the platform <> "MacOs". The result will be  
empty on not MacOS plateforms and this is safe (or a contract for the  
result).
- The function is intended to extract the file creator and/or type  
(at least one of both), so not to repeat the char 1 to 4/char 6 to 9  
on the result in the calling handle, I propose to directly set the  
value in the function by passing by reference the pCreator and pType  
variables. This should save some fractions of millisecs...
- ... and better it will be safer for future use: if you call your  
function and then forget that comma can be in the 4-chars of the  
creator or type, you could wrote buggy code like:
    put CreatorAndType(pFilePath) into tct
    put item 1 of tct into tCreator -- correct is: char 1 to 4 of tct
    put item 2 of tct into tType -- correct is: char 6 to 9 of tct



> When working on the "Getting the type code of a file under OSX"
> thread, I noticed that the long files function return an empty
> filetype for TextEdit files (raw text or RTF).
> FileBuddy reports correctly, Rev not.
> Could you confirm?

Yes I confirm such a behavior. Remember that under MacOSX, not all  
files have a creator/type. Suffix of the file (e.g. ".pdf") is  
usually sufficient for the MacOSX to know its type and therefore how  
to deal with it (e.g. application to open it).

One question: how can I get the application(s) which can open a file  
given its filepath? One answer to open the file but does not give the  
application(s) names:
    revgourl URL ("binfile:" && tFilepath)
Other solutions for each supported platform?

Joel
------------------------------------------------------
"Ils ne savaient pas que c'était impossible, alors ils l'ont  
fait." (Mark Twain)
"They did not know that it was impossible, so they did it."