home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / mac / programm / 14818 < prev    next >
Encoding:
Internet Message Format  |  1992-08-31  |  1.7 KB
  1. Path: sparky!uunet!sun-barr!cs.utexas.edu!wupost!waikato.ac.nz!ldo
  2. From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: Getting the alias'd name from a drag-and-drop app?
  5. Message-ID: <1992Sep1.175230.10505@waikato.ac.nz>
  6. Date: 1 Sep 92 17:52:30 +1200
  7. References: <alen.714928925@crash> <1992Aug28.152653.10332@bmers95.bnr.ca> <1992Aug29.202734.24330@newstand.syr.edu>
  8. Organization: University of Waikato, Hamilton, New Zealand
  9. Lines: 24
  10.  
  11. In article <1992Aug29.202734.24330@newstand.syr.edu>, greeny@top.cis.syr.edu (J. S. Greenfield) writes:
  12.  
  13. > As for the standard file package--I find it acceptable since one is able to
  14. > circumvent the automatic alias resolution (and other things); however, I
  15. > find it very strange (and problematic, perhaps, for compatibility with
  16. > older applications) that one has to specifically include alias file types
  17. > when constructing type lists.  That is--by default, alias are *not* invisible
  18. > to the standard file package.  If your standard file dialog includes "APPL"
  19. > for example, you have to explictly include "adrp" in the list in order to
  20. > have aliases to applications included.  This mix of transparent/non-transparent
  21. > behavior is problematic in my eyes.
  22.  
  23. Applications are a special case, but document aliases *do* in fact appear
  24. automatically in the Standard File list, without the application having to
  25. take any special action.
  26.  
  27. The file type and creator for a document alias are the same as for the
  28. original document.
  29.  
  30. Let's face it, applications which open other applications are fairly unusual,
  31. and don't tend to be used by novices, anyway...
  32.  
  33. Lawrence
  34. (bracing himself for a barrage of counterexamples)
  35.