[futurebasic] Re: [FB] FSSpecs vs FSRefs

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

From: Robert Covington <artlythere@...>
Date: Wed, 23 Jan 2008 18:25:25 -0500
I love FSRefs (FSSpecs are spiffy other than the filename length  
issue though), would be nice if we had a convention for a keyword  
based return of an FSRef for a non-existent file. Such are often  
needed for various purposes.

It could be like,

FSRef = USR MakeFSRef

Alas, I know the support code behind that would be like, 3 pages  
long. :) (have seen the apple demo code for such a case of the non- 
existent file case)


On Jan 23, 2008, at 10:39 AM, Brian Stevens wrote:

> On Jan 23, 2008, at 2:12 AM, Ken Shmidheiser wrote:
>> With the recent discussions concerning FSSpec vs FSRefs,
> Just two quick points for all FBers using files with FBtoC:
> 1) Please read the FBtoC help docs. The OPEN verb, for example, is  
> different from FB's OPEN. This is documented.
> 2) FBtoC supports only an FSSpec or FSRef with the OPEN verb.  
> Again, please see the FBtoC docs.
> FSSpecs were implemented in FBtoC  so existing code wouldn't break  
> (assuming someone was using the most modern FB offered --- 
> FSSpecs) . It would have been much easier in FBtoC to use only FSRefs
> If you are not using FSSpecs, consider going directly to FSRefs  
> instead. FSSpecs do NOT handle long ( > 31 chars) files names and  
> your users will call/email asking why their file names have garbage  
> in them. Some users won't notice the file name but mangled file  
> names can cause other issues including (under the right conditions)  
> inadvertent data loss. Apple deprecated FSSpecs for good reasons  
> and it wasn't just some whimsical choice to annoy programmers.
> Brian S.
> --
> To unsubscribe, send ANY message to: futurebasic- 
> unsubscribe@...