[futurebasic] Re: [FB] Recursive scan folder

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : January 2008 : Group Archive : Group : All Groups

From: Brian Stevens <bstevens33@...>
Date: Mon, 28 Jan 2008 12:27:15 -0700
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

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.