jdm@ut-emx.UUCP (Jim Meiss) (11/28/88)
I'm perplexed about the some weird behavior in a DA I'm writing using LSC 3.0. First the setting: Mac SE System 6.02 multifinder DA has dNeedLock and dNeedGoodbye Here's what I do: Launch the DA holding down the option key. It will load itself into the current application's layer...though I note that its actually loaded into the system heap (like all good da's under multifinder). While the DA is thus open, try to open it again, using the apple menu, but NOT holding down the option key. In most cases when you do this to a DA, the DA Handler is not launched. If you are in a different layer from the DA, multifinder switches you to the layer which contains the DA. All well and good however... Not so for my DA: Multifinder attempts to launch DA handler and open my DA again. It uses the already open (and locked) DRVR segment in the system heap, but bad things happen when DA Handler thinks it should have control of the DA. Now I don't see how this can be my fault, since all the bad stuff seems to happen before my DRVR open routine gets called... I checked the system heap, and my DCE is in place, locked and properly indicates that the driver is open. Any ideas? Does Anyone have an LSC da that doesn't have this problem? How does multifinder tell that a DRVR is open... and it shouldn't launch the DA Handler? Thanks Jim Meiss jdm@emx.utexas.edu
wdh@well.UUCP (Bill Hofmann) (11/29/88)
In article <8268@ut-emx.UUCP> jdm@ut-emx.UUCP (Jim Meiss) writes: > > I'm perplexed about the some weird behavior >in a DA I'm writing using LSC 3.0. As far as I know, the problem you describe is not your fault. Here's what happens: 1. When you open a DA with the option down, the DA is opened and the DCE entry FOR THE TOPMOST APPLICATION is filled. 2. When you open a DA without option, DA Handler takes care of it (ie, MultiFinder checks to see whether it's launched, if not, do it and make it frontmost, else, just make it frontmost, and then there is some unknown (to me) hack to make it open the DA you chose. In this case, the DCE in the DA Handler is filled. Each application has its own version of the Unit Table (that is, unique entries are swapped out). This is the problem. MultiFinder only knows how to launch DA Handler, it doesn't know how to (or doesn't) search through all the open applications for an open driver. -Bill
jdm@ut-emx.UUCP (Jim Meiss) (11/30/88)
In article <7776@well.UUCP> wdh@well.UUCP (Bill Hofmann) writes: >In article <8268@ut-emx.UUCP> jdm@ut-emx.UUCP (Jim Meiss) writes: >> >> I'm perplexed about the some weird behavior >>in a DA I'm writing using LSC 3.0. > >As far as I know, the problem you describe is not your fault. Here's >what happens: >1. When you open a DA with the option down, the DA is opened > and the DCE entry FOR THE TOPMOST APPLICATION is filled. >2. When you open a DA without option, DA Handler takes care > of it (ie, MultiFinder checks to see whether it's launched, .... > In this case, the DCE in the DA Handler is filled. As far as I can tell, all the DCE's are contained in the system heap. Thus multifinder should check there to see if a DA is currently opened or not. I don't know how I can tell which application layer contains the DA, but it seems to be able to, with most DA's. My DA, created with LSC 3.0, seems to not be able to tell Multifinder that its loaded into an application layer, and so Multifinder trys to launch DA handler. Something is wrong with my code, or with LSC's DRVR code, because other DA's don't have this problem.... Jim Meiss jdm@emx.utexas.edu
jwhitnell@cup.portal.com (Jerry D Whitnell) (12/02/88)
Jim Meiss writes... | Something is wrong with my code, or with LSC's DRVR code, because |other DA's don't have this problem.... I'm using LSC's DRVR code and have no problems of the sort you are describing. I can load it in an application, load something else in the DA handler and get swapped back to the application by selecting my da. Does your DA have a window? It is possible that MF uses the window layer to decide which application to swap in. I'm just guessing here. -- Jerry Whitnell Several Species of Small Furry jwhitnell@cup.portal.com Animals Gathered Together in a ..!sun!cup.portal.com!jwhitnell Cave and Grooving with a PICT.
jdm@ut-emx.UUCP (Jim Meiss) (12/03/88)
I wrote the following: > Something is wrong with my code, or with LSC's DRVR code, because >other DA's don't have this problem.... > Jim Meiss > jdm@emx.utexas.edu Stick foot in mouth # 233: There is nothing wrong with LSC's code: I just tried out the HEX Dump Da that comes with LSC, and it works fine. Now I just have to get serious and find the problem in my code... Sure wish someone could tell me how Multifinder checks to see if a DA is open..... Jim Meiss (again)
jdm@ut-emx.UUCP (Jim Meiss) (12/04/88)
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