On Jan 27, 2008, at 3:55 PM, Alain Pastor wrote: > Brian Stevens a écrit : >> On Jan 27, 2008, at 3:11 PM, Alain Pastor wrote: >>>>> Thanks Brian & Steve. >>>>> >>>>> ........ but I stopped programming nearly 80 years ago......... >> You really opened the door for comments on this one Alain. > Sorry, just a typo. I meant 800, of course. > >>>>> >>>>> The problem is that the file$ function seems to return a wrong >>>>> FSSpec when it involves a folder (using _FSSpecFolder). The >>>>> misbehavior arises only when running through FBtoC although the >>>>> code compiles without errors. On the other hand, it works as >>>>> expected through FB. >> Do you have an example to recreate the problem? >>>>> >>>>> In the code I posted previously I was not interested in finding >>>>> a specific folder but rather in dealing with the folder the >>>>> user has chosen in the Navigation Services dialog box. >> The only previous posts I have from you are the IterateFolder post >> which doesn't use FILES$ and sending apple events to system >> processes. I don't see a post like the one mentioned but I've >> overlooked things before. >>>>> >>> The question still remains: is this a bug in my code or should I >>> report a bug to the FBtoC team? >> Alain, please post the code snippet showing the problem. If it is >> a bug that will be the only post necessary. > > OK. Here you are: Thanks Alain. As you suggested, it is an FBtoC bug specifically in files$ using _FSSpecFolder. It can be reproduced by running the following with FBtoC: '---------------- dim as FSSpec spec dim as str255 name name = files$( _FSSpecFolder, "Choose a folder",,spec ) print "spec.name = ";spec.name,"spec.parID = ";spec.parID,"spec.vRefNum = ";spec.vRefNum do handleevents until gFBQuit '--------------- It is interesting the FB does not return a name in the filespec but the parID and vRefNum are intact. I will log this with FBtoC. My initial perusal of the C runtime code didn't uncover the exact problem although I didn't see a 'case' for kFBFSSpecFolder after the NavDialogRun. Brian S.