rlr@lad.med.utas.edu.au (Dr Ross L Richardson) (01/04/91)
Just a quick MultiFinder gripe:
Whilst debugging a WDEF (ID = 128), I "discovered" that MultiFinder
[6.1b9] refuses to perform a major switch when varCode 1 is used. Is this
documented somewhere I missed?
Seems rather severe to me. Applies to (rDocProc + 1) too. [What became of
the corners of diameter 4 - IM I p274?]
What will System 7 do?
- Ross -
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Dr Ross L Richardson, (Dept of Medicine, Uni of Tasmania, Australia)
Domain: ross@cor.med.utas.edu.au (ross%cor.med.utas.edu.au@uunet.uu.net)
UUCP: {uunet,ubc-cs,ukc,enea,mcvax,nttlab}!munnari!cor.med.utas.edu!ross
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++stevec@Apple.COM (Steve Christensen) (01/04/91)
rlr@lad.med.utas.edu.au (Dr Ross L Richardson) writes: >Just a quick MultiFinder gripe: > > Whilst debugging a WDEF (ID = 128), I "discovered" that MultiFinder >[6.1b9] refuses to perform a major switch when varCode 1 is used. Is this >documented somewhere I missed? > >Seems rather severe to me. Applies to (rDocProc + 1) too. [What became of >the corners of diameter 4 - IM I p274?] > >What will System 7 do? It won't let you switch because the standard WDEF (ID=0) varCode 1 is the modal dialog window. Normally if a modal dialog is the front-most window, you don't want to allow switching because a critical operation needs to be completed. Yes, this creates problems with other WDEFs, but it's been this way since MultiFinder came out, so I guess it's now a feature? I don't know if 7.0 will do the same thing, but I suspect it will... steve -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Steve Christensen | Apple Computer, Inc. | Disclaimer: | 20525 Mariani Ave, MS-81CS | the above may be stevec@apple.com | Cupertino, CA 95014 | a lie...or not.
bin@primate.wisc.edu (Brain in Neutral) (01/04/91)
From article <rlr.662947742@lad>, by rlr@lad.med.utas.edu.au (Dr Ross L Richardson): > Just a quick MultiFinder gripe: > > Whilst debugging a WDEF (ID = 128), I "discovered" that MultiFinder > [6.1b9] refuses to perform a major switch when varCode 1 is used. Is this > documented somewhere I missed? Tech Note 158, in the "When exactly does juggling take place?" section. I notice the documentation for Eudora claims that switching is allowed during alerts. I don't know how that's done, perhaps by some tricky switching of the window type...but evidently there is a way to defeat MultiFinder's behavior. -- Paul DuBois dubois@primate.wisc.edu
dorner@pequod.cso.uiuc.edu (Steve Dorner) (01/04/91)
In article <47731@apple.Apple.COM> stevec@Apple.COM (Steve Christensen) writes: >It won't let you switch because the standard WDEF (ID=0) varCode 1 is the >modal dialog window. Normally if a modal dialog is the front-most window, >you don't want to allow switching because a critical operation needs to be >completed. I wonder about that. When I put up a modal, I'm usually trying to inform the user that <something bad> has happened, or trying to get some piece of information my program needs before it can do what the user has asked it to do. "Sorry, disk full." "Sorry, malformed address." "Please enter your password:" "Please configure me:" I see no reason in any of these cases NOT to allow switching. In fact, I can't think of a SINGLE SPOT in my program where it would hurt the user to switch, and several where it could be beneficial. So I've hacked (and I mean hacked) my filterProc to always allow switching. I can hear some of your knees jerking out "you shouldn't use modals!" I'm afraid I can't agree. Users expect them for error conditions, and it also makes perfectly good sense to use them for obtaining vital info. I would like to see the "don't switch on modals" restriction simply REMOVED. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
dorner@pequod.cso.uiuc.edu (Steve Dorner) (01/05/91)
In article <3686@uakari.primate.wisc.edu> bin@primate.wisc.edu writes: >I notice the documentation for Eudora claims that switching is allowed >during alerts. I don't know how that's done, perhaps by some tricky >switching of the window type...but evidently there is a way to defeat >MultiFinder's behavior. I saw this in the MPW dox: Note: Although you cannot move Shell windows or pull down menus while a tool is running, remember that you can switch applications by clicking the application icon in the menu bar. So I settled on that method for allowing switches during modals; you click on the right side of the menu bar. (What's sauce for the goose is after all sauce for the gander.) I have a filterProc that sees such clicks, and then calls a function that does switching. Switching is done by searching the apple menu for the name of my application, and then calling OpenDeskAcc on the next item in the menu (it's a touch more complicated than that, since I do handle hidden apps and being at the end of the application list). I could post my switching function if anyone is interested. It is definitely a hack. I have no idea if it will work under system 7, having never seen a copy of that Holy Item. I have no idea if it will even be necessary under system 7. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
hairston@henry.ece.cmu.edu (David Hairston) (01/05/91)
[stevec@Apple.COM (Steve Christensen) writes:]
[] It won't let you switch because the standard WDEF (ID=0) varCode 1 is the
[] modal dialog window. Normally if a modal dialog is the front-most window,
[] you don't want to allow switching because a critical operation needs to be
[] completed.
[dorner@pequod.cso.uiuc.edu (Steve Dorner) writes:]
[] I wonder about that. When I put up a modal, I'm usually trying to inform
[] the user that <something bad> has happened, or trying to get some piece of
[] information my program needs before it can do what the user has asked it
[] to do.
[] ... {stuff deleted}
[] I see no reason in any of these cases NOT to allow switching. In fact, I
[] can't think of a SINGLE SPOT in my program where it would hurt the user to
[] switch, and several where it could be beneficial.
[]
[] So I've hacked (and I mean hacked) my filterProc to always allow switching.
[]
[] I can hear some of your knees jerking out "you shouldn't use modals!"
[] I'm afraid I can't agree. Users expect them for error conditions, and it
[] also makes perfectly good sense to use them for obtaining vital info.
[]
[] I would like to see the "don't switch on modals" restriction simply
[] REMOVED.
it seems your trying to blur the valid distinction between modal and
modeless dialogs (valid, in my opinion).
my knee jerk reaction is to suggest that you try other varcodes if
simply want the modeless behavior. i'm not aware that the user is
so discriminating that a similar appearing window, in this case, will
lead to disaster. better yet, since you hack extensively, blow off
WDEF 0 and roll your own! this eventually will make better use of
your extensive hacking ...
hmmm, seems like one of those ;-) thingies might be appropriate here.
-dave- "it's all in your mind ..."
hairston@henry.ece.cmu.edukeith@Apple.COM (Keith Rollin) (01/05/91)
In article <47731@apple.Apple.COM> stevec@Apple.COM (Steve Christensen) writes: >rlr@lad.med.utas.edu.au (Dr Ross L Richardson) writes: >>Just a quick MultiFinder gripe: >> >> Whilst debugging a WDEF (ID = 128), I "discovered" that MultiFinder >>[6.1b9] refuses to perform a major switch when varCode 1 is used. Is this >>documented somewhere I missed? >> >>Seems rather severe to me. Applies to (rDocProc + 1) too. [What became of >>the corners of diameter 4 - IM I p274?] >> >>What will System 7 do? > >It won't let you switch because the standard WDEF (ID=0) varCode 1 is the >modal dialog window. Normally if a modal dialog is the front-most window, >you don't want to allow switching because a critical operation needs to be >completed. > >Yes, this creates problems with other WDEFs, but it's been this way since >MultiFinder came out, so I guess it's now a feature? I don't know if 7.0 >will do the same thing, but I suspect it will... Versions of MultiFinder that come with System Software after MultiFinder 6.1b9 was created work a little differently. What they do is look for a call to ModalDialog to inhibit switching, rather than look at the variant code of the window. Therefore, the original poster's WDEF should work when using the MultiFinder that comes with the normal customer's system. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
dorner@pequod.cso.uiuc.edu (Steve Dorner) (01/07/91)
In article <HAIRSTON.91Jan4124144@henry.ece.cmu.edu> hairston@henry.ece.cmu.edu (David Hairston) writes: >it seems you're trying to blur the valid distinction between modal and >modeless dialogs (valid, in my opinion). I do think there's a valid distinction. I just think that disallowing switching is a counterproductive distinction to make. I fail to see why "Application A cannot continue without user input" should INCONTROVERTIBLY imply that "The user must not use Applications B, C, and D before she fixes A." I can't see the justification from a human interface point of view. Now, perhaps there are technical reasons that it is bad to switch out from under a modal. If so, I've never heard it said, nor have I experienced any problems in doing so. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (01/07/91)
Brain in Neutral writes in a message to All
BIN> I notice the documentation for Eudora claims that switching is
BIN> allowed during alerts. I don't know how that's done, perhaps
BIN> by some tricky switching of the window type...but evidently there
BIN> is a way to defeat MultiFinder's behavior
They may have faked the interface for a Modal Dialogue the way the Dialogue
class does in MacApp or the CAboutBox class does in the TCLs.
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.orgd88-jwa@nada.kth.se (Jon W{tte) (01/08/91)
In article <> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >I fail to see why "Application A cannot continue without user input" >should INCONTROVERTIBLY imply that "The user must not use Applications B, C, >and D before she fixes A." One example is SFGetFile, which uses global space and therefore is not reentrant. There could be more examples of non-reentrancy. Also, most modal dialogs are of the error-alert type, and one might argue that other apps could mess things up during error conditions they didn't create. Also, many modals are NOT designed to be updated properly if overdrawn. >Steve Dorner, U of Illinois Computing Services Office But, behold ! The MOVABLE MODAL from Apple Computer Inc ! The solution to all your problems ! Also, you can brew your own modals so as to allow context switcing out of the app, using plainDBoxes and a little state logic. Happy hacking, h+ -- Jon W{tte, Stockholm, Sweden, h+@nada.kth.se