mckernon wrote:
> Dear friends,
> 
> I fear I'm caught in the VRefNum vs. WDRefNum vs. FSSpec tangle, 
> hopefully one of you smart folks can see where I'm screwing up.
> 
> What I'm trying to do is make a list of all the files (of certain types) 
> within a specified folder within my application's folder. Then, I let the 
> user select one of those files from a pop-up menu and display it onscreen 
> or print it using USR IMAGEFILETOPICT.
> 

Unfortunately, USR IMAGEFILETOPICT is designed to work with pseudo 
working reference numbers. Fortunately, you can look at what the 
function does since you have access to the source code of the sub 
image files.INCL header file and write a custom function that accepts 
a pointer to an FSSpec instead (perhaps, you might even use the 
override statement for that matter).

> I call FN CheckFolderApp, which calls FN ProcessFolder, which calls FN 
> AddToFileList. However, when I use the filenames and volume numbers that 
> are sent to FN AddToFileList with USR IMAGEFILETOPICT, I first check to 
> see if they exist and they don't. The filenames are all correct, but the 
> VolNum is always the same, no matter which sub-folder the routines have 
> been asked to process. My guess is the scanStuff.ScanSpec.vRefNum isn't 
> what I need, or it needs converting to a WDRefNum, but I don't know how 
> to do that.
> 

I guess that's normal to get the same volume reference number for all 
the files located in the same folder and they should have also the 
same parID.

Notice that you can check for the existence of a file given its FSSpec 
with the very same function that is used to set the structure:

err = FSMakeFSSpec( vRefNum, parID, name, fSpec )
if err = _fnfErr then print "file doesn't exist"

The FSSpec is still valid even though it refers to a non existing file 
(for instance, you may wish to write to disk a new file, you can then 
use the FSSpec later in other statements)

If you want to check for the existence of a file inside a function 
that has received a pointer to an FSSpec, you would probably have to 
write something like this:

local fn doSomethingWithThatFile( f as .FSSpec )

select FSMakeFSSpec( f.vRefNum, f.parID, f.name, #f )
case _noErr  : // file OK, can be opened
case _fnfErr : // missing file, maybe needs to be created
case else    : // other error
end select

// etc.

end fn


Looking at USR IMAGEFILETOPICT, I see you don't even need to test if 
the file is valid before calling that routine, because it already does 
the checking for you. Perhaps, you could rewrite that function like so 
(caution not tested):

local
dim as handle                  @ myPict
dim as GraphicsImportComponent @ grphImpComp
dim as ComponentResult           crslt
dim as OSERR                     err
local fn FSImageFileToPICT( f as .FSSpec )
'~'
myPict = 0
long if fn FSMakeFSSpec(f.vRefNum,f.parID,f.name,#f) = _noErr
long if fn GetGraphicsImporterForFile(#f, grphImpComp) = _noErr
crslt = fn GraphicsImportGetAsPicture(grphImpComp,myPict)
err   = fn CloseComponent(grphImpComp)
end if
end if
end fn = myPict

> I'm running this in OSX, with the PG runtime (not Appearance), but it has 
> the same problem in a PPC compile. All of the functions I'm using are out 
> of the Examples folders included with R7 of FB^3.
> 
> Any hints?
> 

> 
> CLEAR LOCAL FN AddToFileList(FileName$,FilTyp&,fParID&,fVrefNum)
>     'This just puts the info into arrays for storage & display by the 
> pop-up,
>     'nothing of interest here
> 
>      '(Note that although I collect the fParID&, I haven't actually found 
> a use for it yet.)
> END FN
> 

Instead of passing all those parameters to the function above, I think 
I would pass directly the FSSpec of the file along with its file type.

The dirID might be useful (and required) in some of the FB commands 
related to file operations, that is if you don't go with pseudo 
working directory numbers, it is not sufficient to use the name and 
the volume reference number to reference correctly a given file; you 
need also its parID (for an example, look at the syntax for the KILL 
statement in the Reference manual)

Working directory numbers are dead in OS X, it's just Andy's magic 
that keeps them alive in order to avoid conversion headaches to the FB 
programmers. Thousands of old FB programs can still run in OS X 
without too much bothering, that's good, but the troubles start when 
you mix up the fake thing with the FSSpec approach. You must choose 
one or the other and stick with it all along.

-- 
Cheers,

A. Pastor