Path: utzoo!utgpu!watmath!clyde!att!rutgers!cs.utexas.edu!ut-emx!jdm
From: jdm@ut-emx.UUCP (Jim Meiss)
Newsgroups: comp.sys.mac.programmer
Subject: Re: DA problem under Multifinder
Summary: Problem Solved!!--> set wStorage to NIL
Keywords: LSC, option key, DA Handler
Message-ID: <8467@ut-emx.UUCP>
Date: 3 Dec 88 22:52:52 GMT
References: <8268@ut-emx.UUCP> <7776@well.UUCP> <8328@ut-emx.UUCP> <8437@ut-emx.UUCP>
Reply-To: jdm@emx.UUCP (James Meiss)
Organization: UTexas Computation Center, Austin, Texas
Lines: 38


	The saga of the DA which opens improperly under multifinder 
is solved!

	As you may recall, when we last left our DA, it was 
exhibiting the following behavior: Under Multifinder, open 
the DA in an application's layer by holding down the option 
key. Now select the DA from the apple menu again, this time 
without option down. This time multifinder trys to launch 
the DA handler with disastrous effects since the DA is already open.

	Now for the conclusion of our story: The problem was 
that I allocated a DialogRecord for my window (it was a global, 
so it went into my DrvrStorage) and passed this to GetNewDialog. 
If instead I simply set the dStorage parameter to NIL, letting 
the DialogRecord be allocated on the heap, everything works okay.
	You can try this for your self by taking the HEX Dump DA 
example that comes with LSC 3.0. Modify the Create_Window() 
routine as follows:
--------------
WindowRecord WRec;  /*new global*/
Create_Window()
...
   wp = NewWindow(&WRec, &bounds, "", FALSE, 8, 0L, TRUE, 0L );
               /* ^^^^^ nolonger NIL*/
---------
This reproduces the bomb.

	So it seems that Multifinder somehow checks the heap 
to find the WindowRecord for an open DA. However, if this is 
true then how would it know a DA with no windows is open ?????
	I would think a much smarter thing would be to check 
the UnitTable to get the DCE, and check the dOpened flag. This
can't be what it does however. Why not?

				Jim Meiss
				jdm@emx.utexas.edu
				jdm@fusion.utexas.edu