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."