Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!pt.cs.cmu.edu!henry.ECE.CMU.EDU!hairston
From: hairston@henry.ECE.CMU.EDU (David Hairston)
Newsgroups: comp.sys.mac.programmer
Subject: Re: DA's, just say no!
Message-ID: <12265@pt.cs.cmu.edu>
Date: 6 Mar 91 22:32:17 GMT
References: <12182@pt.cs.cmu.edu> <12406@goofy.Apple.COM>
Organization: Gaia II
Lines: 28

[hairston@henry.ECE.CMU.EDU (David Hairston) writes:]
[]  ...
[] nothing useful).  Since it assumes MultiFinder, I've decided
[] not to add support for DA's within my application (after all,
[] there's DA Handler).  This only means that if you install a

[lsr@Apple.COM (Larry Rosenstein) writes:]
[] You have to support DAs in order for MultiFinder to work.  For example,
[] when the user picks a DA, the only way for MultiFinder to know this is that
[] your application calls OpenDeskAcc.  The same is true of switching
[] applications by choosing the name in the Apple menu.  It might be possible
[] to leave out some of the other calls, but you're not talking about much
[] code, so you might as well put it in.

no, you misunderstood.  i didn't mind calling up DA's as long as they
went into DA Handler.  DA's opened by option-clicking or DA's installed
in my app were to be verboten.  well, i played around with this a lot
and found out that its just not worth it trying to not support DA's
correctly.  the easiest thing to do is simply follow the rules and
pray that DA's also follow the rules (i.e. check available memory when
starting up).  the code overhead is _very_ minimal and you don't have
to worry about possible loopholes or future system patches breaking
your code, etc.

moral: DA's just yes, maybe ...    ;)

  -dave-  
hairston@henry.ece.cmu.edu