On 11/27/04 4:56 PM, OL&L Lists didst favor us with:
> The Unicode thought police are on the rampage........
Sorry, but
- Mac OS X uses Unicode, so applications should support it.
- The FSSpec APIs also don't support creating files or folders with more
than 31 characters in the name (even in English). So if you have a specific
need to create files with known names over which the user has no control and
never need to create any other files, then FSSpec APIs may be fine. But for
general purpose file creation where the user can specify the name, using
FSSpec APIs in Mac OS X is a bad idea. I always prefer one set of functions
to do something over two, so as long as I have code to create files with the
FSCreatexxxUnicode APIs, I might as well use it all the time.
FWIW, there probably isn't anyone who has written more FSSpec-based code
than I have, or replaced more of it with FSRef-based code than I have. It
wasn't fun (mostly tedious), but fighting it just seems silly. It's not
rocket science, it's not hard, it's just one more thing on the list of
changes that come with writing for Mac OS X.
Larry
> Michael
>
> At 8:35 PM -0500 11/21/04, Laurence Harris wrote:
>> On 11/21/04 8:09 PM, OL&L Lists didst favor us with:
>>
>>> Some of the FSSpec-based routines require an FSSpec before they can
>>> be used (such as FSpCreate).
>>
>> FSpCreate can't be used to create files with long or Unicode file names and
>> hence shouldn't be used in Mac OS X except possibly in very special
>> circumstances.
>>
>>> Hence one may want to make an FSSpec with FSpMakeFSSpec or some such before
>>> the object pointed to by that FSSpec actually exists.
>>
>> One shouldn't want this. FSSpecs don't support long or Unicode file names,
>> and hence as a rule should not be used to represent items which don't exist
>> in Mac OS X.
>>
>>> IMHO not being able to have an FSRef that can
>>> point to a non-existent object is a step backwards from FSSpecs in
>>> which this was allowed.
>>
>> The HFS+ file system introduced in Mac OS 9 supports file names with up to
>> 255 UniChars. An HFSUniStr255 file name uses 512 bytes. As such a struct
>> containing a HFSUniStr255 not a good choice for a general purpose file
>> reference, however handy it might be at times. So it's not so much a step
>> backward, as a reasonable decision to support a new technology.
>>>
>>> Michael
>>> Orbital Launch & lift, Inc.
>>> http://www.orbitallaunch.com
>>>
>>> At 2:41 PM -0500 11/21/04, Laurence Harris wrote:
>>>> On 11/21/04 1:42 PM, Turbo3D didst favor us with:
>>>>
>>>>> And now that we have the user directory, how to create a private
>>>>> folder into it and then create some file this folder .
>>>>> We got the FsRef of the user domain, but how to get a FsRef ( then a
>>>>> FsSpec) to a non existing folder/file path ?
>>>>
>>>> BTW, have you read
>>>>
>>>> TN 2078: Migrating to FSRefs & long Unicode names from FSSpecs
>>>>
>>>> http://developer.apple.com/technotes/tn2002/tn2078.html
>>>>
>>>> And why do you want an FSSpec?
>>>>
>>>> Larry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
