NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/sys/mac/programm/14797

Text File | 1992-08-31 | 3.4 KB | 64 lines

Newsgroups: comp.sys.mac.programmer
Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!ames!agate!iat.holonet.net!uupsi!psinntp!newstand.syr.edu!greeny
From: [e-mail] (J. S. Greenfield)
Subject: Re: Getting the alias'd name from a drag-and-drop app?
Message-ID: <[e-mail]>
Organization: Syracuse University, CIS Dept.
References: <alen.714928925@crash> <[e-mail]>
Date: Sat, 29 Aug 92 20:27:34 EDT
Lines: 53

In article <[e-mail]> [e-mail] (Ross Brown) writes:
>
>No.  The alternative ('odoc' Apple event handling) would give you the same
>thing.  The Finder and Standard File package always, always (see *EXCEPTION*
>below) resolve aliases before handing files to your application.  This is good
>for at least two reasons:  one, it allows most System-7-unaware applications to
>continue to work under System 7 (since document aliases have the same creator
>and type as the originals, how could the application be expected to know the
>difference?); and two, it forces the vast majority of System-7-aware
>applications to behave consistently in their handling of aliases, to the relief
>of users everywhere.

I disagree.  I think it was a big mistake for Apple to leave no way for an
application to received dropped aliases without resolving them.

I think it is fine to make it the *normal* technique for doing things; however,
I can't see any good reason why the resolving of alias files upon dropping
them should not have been made optional by, for example, using one of the
currently reserved bits in the SIZE resource.  This would preserve the
proper operation of old applications, allow normal applications to have
aliases resolved, but still allow special applications--for example, those
which extend the functionality of the Finder in some manner--to handle aliases
in the same, straightforward manner that the Finder handles aliases.

Remember, the Finder doesn't *always* handle aliases the same way.  Sure
many operations, like double-clicking an alias, for example, are equivalent
to double-clicking the original--but many other operations, like dropping an
alias into a folder, for example, operate on the *alias* itself, and not the
original.

As for the standard file package--I find it acceptable since one is able to
circumvent the automatic alias resolution (and other things); however, I
find it very strange (and problematic, perhaps, for compatibility with
older applications) that one has to specifically include alias file types
when constructing type lists.  That is--by default, alias are *not* invisible
to the standard file package.  If your standard file dialog includes "APPL"
for example, you have to explictly include "adrp" in the list in order to
have aliases to applications included.  This mix of transparent/non-transparent
behavior is problematic in my eyes.

In my view, apple should have made the use of aliases in *both* cases
completely transparent for normal use, with a simple optional removal of the
automatic resolution.

I remain hopeful that Apple will see fit to do something along these lines
for the case of drag-and-drop alias-resolution in the release version of
7.1, or at least, at some point in the future.

--
J. S. Greenfield                                         [e-mail]
(I like to put 'greeny' here,
but my d*mn system wants a
*real* name!)                        "What's the difference between an orange?"