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,@tCreator,@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,@pCreator,@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."
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
