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