Re: Choosing Files Based Upon Type
Re: Choosing Files Based Upon Type
- Subject: Re: Choosing Files Based Upon Type
- From: "David W. Halliday" <email@hidden>
- Date: Mon, 18 Jun 2001 19:07:58 -0500
- Organization: Latin AmeriCom, formerly Latino Online
Richard Schreyer wrote:
>
On Monday, June 18, 2001, at 12:12 PM, Joe Muscara wrote:
>
>
> On Thursday, June 14, 2001, at 02:17 PM, Ali Ozer wrote:
>
>
>
>> But rest assured that Cocoa is constantly being enhanced
>
>> (for instance, in 10.0 open panel can now choose files based on types
>
>> in
>
>> addition to extensions).
>
>
>
> While I did find this mentioned in the introductory text for the
>
> NSOpenPanel help page, I haven't been able to figure out how to
>
> actually implement it. All I could think of trying was
>
>
>
> NSArray *fileTypes = [NSArray arrayWithObject:@"TEXT"];
>
>
>
> but that resulted in the obvious - only allowing selection of items
>
> whose extension was "TEXT."
>
>
>
> How is this done? And, am I reading the original post correctly that
>
> this has been available since 10.0?
>
>
To get NSOpenPanel to choose files based on type, you use 'TEXT'. The
>
surrounding single quotes indicate a type code, not a file extension.
>
>
For example, you might want:
>
NSArray *fileTypes = [NSArray arrayWithObjects:@"txt", @"'TEXT'"];
>
>
This is available in 10.0.0.
>
>
Richard Schreyer
While this format is, in truth, the /present/ implementation,
the documentation /clearly/ stated that one should /not/ rely upon
this format.
Use the appropriate function calls.
Along these same lines, the fact that the NS Type strings
/have/, traditionally, been simply the file extensions (without
the period), is also simply an implementation detail---it,
likewise, should not be relied upon.
Use the appropriate method calls.
The reality, as far as the programming model is concerned, is
that there are Type strings (used primarily by the pasteboard
system), which make a perfectly good abstract type system, and
then there are implementation dependent methods for representing
that type within any given file system (HFS TYPE code, file name
extension, MIME type, etc.). The appropriate
functions/methods/etc. /must/ be used to translate, when
necessary. The programmer /must/ not rely upon a particular
implementation's mapping since this may change with any given
release.
This is a fundamental tenant of abstraction (information
hiding) that, when violated, will either destroy future
flexibility (by breaking down the abstraction), or will hit you
when the underlying implementation is changed for whatever reason
in the future.
(In fact, a proposed fix for the weaknesses of TYPE/CREATOR
codes and file name extensions, and their [present lack of]
integration, that will allow for far greater flexibility in future
solutions, relies upon the logical [if not actual] distinction
between the internal Type strings and any particular type system
used upon any particular file system, or other OS.)
Please take these warnings to heart, for their intent is to
help the programmer avoid future "gotchas", and to allow the Mac
OS X system the flexibility to grow into the best system in the
world.
David email@hidden