[net.micro.mac] Closing DAs

baron@runx.OZ (Jason Haines) (08/25/86)

If you have a number of open DAs, and you quit from the current application, 
all the DAs are killed without allowing them to clean up (save files,etc.).
Isn't it possible for an application to keep track of the open DAs, and their
refnums (which can be found from the windowKind field of its window), so that 
when it exits to shell, it first calls CloseDeskAcc for all open DAs??

Jason Haines

/* Jason Haines            ACSnet: baron@runx
 * Sydney, Australia       CSNET:  baron@runx.oz
 *                         ARPA:   baron%runx.oz@seismo.css.gov
 * UUCP:
 *   {enea,hplabs,mcvax,prlb2,seismo,ubc-vision,ukc}!munnari!runx.oz!baron
 */

dubois@uwmacc.UUCP (Paul DuBois) (08/28/86)

> If you have a number of open DAs, and you quit from the current application, 
> all the DAs are killed without allowing them to clean up (save files,etc.).
> Isn't it possible for an application to keep track of the open DAs, and their
> refnums (which can be found from the windowKind field of its window), so that 
> when it exits to shell, it first calls CloseDeskAcc for all open DAs??

Won't a properly written DA set its flags to request a goodbye kiss from
the OS in case the application exits out from under it?
-- 
Paul DuBois     UUCP: {allegra,ihnp4,seismo}!uwvax!uwmacc!dubois    |
                ARPA: dubois@easter                               --+--
                                                                    |
Begin at my sanctuary...                                            |
                          Ezekiel 9:6

st94wb@sdcc12.UUCP (wade blomgren) (08/29/86)

In article <49@runx.OZ>, baron@runx.OZ (Jason Haines) writes:
> 
> If you have a number of open DAs, and you quit from the current application, 
> all the DAs are killed without allowing them to clean up (save files,etc.).
> Isn't it possible for an application to keep track of the open DAs, and their
> refnums (which can be found from the windowKind field of its window), so that 
> when it exits to shell, it first calls CloseDeskAcc for all open DAs??
> 


I was under the impression that the responsibility for cleanup prior to a
heap reinitialization was on the DA itself, and if a DA has potential for
needing cleanup, it should set the dNeedGoodBye flag in the drvrFlags for
the DA.  Then the system will notify the DA if you are going to quit the
application out from under it.  (IM II-188..189)

Of course, this does not help if there are x amount of DA's already 
written that don't do this.  

Wade Blomgren
UCSD
...!sdcc12!st94wb

dwb@well.UUCP (David W. Berry) (08/29/86)

In article <49@runx.OZ> baron@runx.OZ (Jason Haines) writes:
>
>If you have a number of open DAs, and you quit from the current application, 
>all the DAs are killed without allowing them to clean up (save files,etc.).
>Isn't it possible for an application to keep track of the open DAs, and their
>refnums (which can be found from the windowKind field of its window), so that 
>when it exits to shell, it first calls CloseDeskAcc for all open DAs??
	Yah, you could, but why bother.  If the DA is correctly written
and needs to know if the application is going out from under it so it can
save files or whatever elses is appropriate it should have the dNeedGoodBye
bit set in it's flags word.  That way it will receive a "goodbye kiss"
when the application exits.  The kiss comes in the form of a control
call with a csParam of -1.
-- 
	David W. Berry
	dwb@well.uucp                   dwb@Delphi
	dwb@GEnie                       293-0752@408.MaBell

parent@suvax1.UUCP (Sean Parent) (08/31/86)

I'm currently writing a DA in TML Pascal (v1.1) and would greatly appreciate
more info on this "goodbye kiss" from the OS.  If some one could mail me this
info or post it to the net (I think lots of people could be interested or does
the whole world get TN's :-), actualy I'm just waiting for mine I ordered them
from APDA and am waiting for them to get rolling).  Incedently, I've run into
a few bugs in the TML system - Improperly defined control record, menu's in
their sample DA don't work (problems with GetMenu and the menu parameters),
etc.  Does any one know if 2.0 is less prone to these "mistakes".  I like TML
and am currently using a friends copy until he can buy a second DD or go to
a double sided disk and plan to buy 2.0 if it looks a bit more polished.
I had a brief discussion with Carl Nelson at the A.P.P.L.E. co-op meating
and he said that TML 2.0 did not support IF DEF's (conditional compiles)
making MacApp use with TML difficult - any one know more about this? Also,
no comments on MPW I know all about it but do not have the funds for the
needed hardware (I currently own a 512K with 2 400K flops :-( ).

				Sean R. Parent
				Seattle University

Standard Disclaimers Apply

-----------
\  !  /!  /
 \ ! / ! /
  >!<  !/
 / ! \ !
/  !  \!

dwb@well.UUCP (David W. Berry) (09/02/86)

The Device Manager section of IM defines three things of importance
to the GoodBye kiss feature:

	dCtlFlags - a word at offset 4 in the device control entry
	drvrFlags - a word at offset 0 in the driver header
	dNeedGoodBye - bit number 4 for usage in bit munger
		calls or 16 for direct operations.

In order to receive a good bye kiss when an application goes away
set the dNeedGoodBye bit in dCtlFlags.  THis can be done at run
time with:
	dce->dCtlFlags |= dNeedGoodBye
or
	BitSet(@dce^.dCtlFlags, LONGINT(dNeedGoodBye))
or by setting it in the header, however you happened to get that
defined.

Having done so your Control routine will be called with csCode
equal to -1 when the application heap is about to be reinitialized,
which happens mainly when an application is Launched.  Exiting
an application is really Launching the Finder so it works as
expected.

I will now refrain from the usual exhortation to buy a copy of
Inside Macintosh if you plan on doing any programming of the mac.

If the pascal function call is incorrect please forgive me as it
has been quite a few years since I gave it up.
-- 
	David W. Berry
	dwb@well.uucp                   dwb@Delphi
	dwb@GEnie                       293-0752@408.MaBell

oster@lapis.berkeley.edu (David Phillip Oster) (09/02/86)

Read David Berry's posting on the subject! Now, some things he left out:
Your desk accessory gets called to process _Control calls.
Control calls come in two flavors: IMMED and queued. 
(You can tell an IMMED one, because the IMMED bit is set in the trap word
in the IO Parameter block.)
IMMED calls must return via an RTS instruction,
all other control calls must return via a JMP to IODone, but leave the
original return address on the stack.

T.M.L. Get this wrong!  The example that comes with the compiler is broken
on this point.

People work on their Macs.  A buggy desk accessory can easily cost someone
a days work.  You have a duty as a Mac programmer to get those bugs out.
The only way to get the bugs out is to have good information.  Buy a copy
of Inside Mac, and get the tech notes or for God's sake have your "about"
message say that you are a dilettante.

--- David Phillip Oster		-- "The goal of Computer Science is to
Arpa: oster@lapis.berkeley.edu  -- build something that will last at
Uucp: ucbvax!ucblapis!oster     -- least until we've finished building it."