mystone@caen.engin.umich.edu (Dean Yu) (01/24/89)
In article <1459@ditsyda.oz> vincent@ditsyda.oz (David A. Vincent) writes: >There's a minor but irritating bug in MultiFinder (or is it in Finder?). >When an application other than the Finder is frontmost, the Finder can >of course still have windows open, but they'll all be inactive. At >least they'll all *look* inactive, but won't be, because clicking on >the (invisible) zoom box of the one which would have been frontmost >will bring the Finder to the front, but also cause the window to zoom. > Who was it that said "It's not a bug, it's a feature!"? At any rate, the reason that the window zooms is because the Finder has the getFrontClicks bit in its SIZE resource set. If this is set, then when the user presses the mouse button in a window belonging to an application in the background, that app will be brought to the front, and that mouse down will be passed to the application. To turn off this option, ResEdit the Finder's SIZE resource (I forget which ID at the moment) and set the FrontClicks field to 0. ______________________________________________________________________________ Dean Yu | E-mail: mystone@caen.engin.umich.edu University of Michigan | Real-mail: Dean Yu Computer Aided Engineering Network | 2413 Kelsey House ===================================| 600 E Madison "These are MY opinions." (My | Ann Arbor, MI 48109 employer doesn't want them. |========================================== Actually, they don't really care | what I think. But President | This space intentionally left blank. Duderstadt does...) | ------------------------------------------------------------------------------
vincent@ditsyda.oz (David A. Vincent) (01/24/89)
There's a minor but irritating bug in MultiFinder (or is it in Finder?). When an application other than the Finder is frontmost, the Finder can of course still have windows open, but they'll all be inactive. At least they'll all *look* inactive, but won't be, because clicking on the (invisible) zoom box of the one which would have been frontmost will bring the Finder to the front, but also cause the window to zoom. ...D.A.V. David A. Vincent vacation student, CSIRO Division of IT ACSnet: vincent@ditsyda.oz Post: GPO Box 1710-T Phone (w): +61 2 887 9383 Hobart TAS 7001 FidoNet: 3:670/700 Australia ---------------------------------------------------------------- Common sense is not all that common. -- Bertrand Russell. D
jellinghaus-robert@CS.YALE.EDU (Rob Jellinghaus) (01/25/89)
In article <1459@ditsyda.oz> vincent@ditsyda.oz (David A. Vincent) writes: >When an application other than the Finder is frontmost, the Finder can >of course still have windows open, but they'll all be inactive. At >least they'll all *look* inactive, but won't be, because clicking on >the (invisible) zoom box of the one which would have been frontmost >will bring the Finder to the front, but also cause the window to zoom. That thar ain't no bug, it's a feature! Basically, clicking on a background layer not only brings that layer to the front, but also acts just as if you had clicked at that location with the layer active. I think this is handy. F'rexample, if you've got your WP in the background and you see a misspelled word, just double-click on the word and retype. Otherwise, you'd have to click three times to get the same effect. I see no reason to require the third click. >David A. Vincent vacation student, CSIRO Division of IT >ACSnet: vincent@ditsyda.oz Post: GPO Box 1710-T >Common sense is not all that common. -- Bertrand Russell. You said it. :-) Rob Jellinghaus | "Next time you see a lie being spread or a jellinghaus-robert@CS.Yale.EDU | bad decision being made out of sheer ignor- ROBERTJ@{yalecs,yalevm}.BITNET | ance, pause, and think of hypertext." {everyone}!decvax!yale!robertj | -- K. Eric Drexler, _Engines of Creation_
leonardr@uxe.cso.uiuc.edu (01/26/89)
vincent@ditsyda.oz(David Vincent) writes in comp.sys.mac >There's a minor but irritating bug in MultiFinder (or is it in Finder?). >When an application other than the Finder is frontmost, the Finder can >of course still have windows open, but they'll all be inactive. At >least they'll all *look* inactive, but won't be, because clicking on >the (invisible) zoom box of the one which would have been frontmost >will bring the Finder to the front, but also cause the window to zoom. > This is NOT a bug but a feature. With the latest MultiFinder came a new bit in the SIZE resource called 'getBackgroundClicks'. If an application has this bit set, then it only takes one click to bring that application to the front and in the process continue to handle the event (rather than one to switch layers and a second to do the action). The Finder does this so that you can quickly launch an application from another application (if that makes any sense ??). We have also implemented this 'feature' in the new MicroPhone II so that our Icons can be quickly activated from the foreground. +---------------------------------+-----------------------------------+ + + Any thing I say may be taken as + + Leonard Rosenthol + fact, then again you might decide+ + President, LazerWare, inc. + that it really isn't, so you + + + never know, do you?? + + leonardr@uxe.cso.uiuc.edu + + + GEnie: MACgician + MacNET: MACgician + + Delphi: MACgician + AppleLink: D0025 + + + + +---------------------------------+-----------------------------------+
vincent@ditsyda.oz (David A. Vincent) (01/27/89)
in article <48596@yale-celray.yale.UUCP>, jellinghaus-robert@CS.YALE.EDU (Rob Jellinghaus) says: [...] >>least they'll all *look* inactive, but won't be, because clicking on >>the (invisible) zoom box of the one which would have been frontmost >>will bring the Finder to the front, but also cause the window to zoom. > > That thar ain't no bug, it's a feature! Basically, clicking on a background > layer not only brings that layer to the front, but also acts just as if you > had clicked at that location with the layer active. I think this is handy. Yes, it is handy to be able to do things without requiring that extra click, but that's not what I'm arguing with. What I'm saying is that applications shouldn't hide an active control from the user. The Finder does this with the aforementioned zoom box. The Finder's problem is that it hides but fails to de-activate the zoom box when it's in the background. I'd be quite satisfied with a zoom box which was active, provided I could see whether it was. > F'rexample, if you've got your WP in the background and you see a misspelled > word, just double-click on the word and retype. Otherwise, you'd have to [...] Note that not all applications use this Multifinder feature. For instance, the above scenario isn't possible in Word 3.01. [...] > Rob Jellinghaus [...] David A. Vincent vacation student, CSIRO Division of IT ACSnet: vincent@ditsyda.oz Post: GPO Box 1710-T Phone (w): +61 2 887 9383 Hobart TAS 7001 FidoNet: 3:670/700 Australia ---------------------------------------------------------------- Common sense is not all that common. -- Bertrand Russell. ( And I didn't say that, Bertrand did. ) D
jrk@s1.sys.uea.ac.uk (Richard Kennaway) (01/31/89)
In article <46100264@uxe.cso.uiuc.edu> leonardr@uxe.cso.uiuc.edu writes: >vincent@ditsyda.oz(David Vincent) writes in comp.sys.mac >>There's a minor but irritating bug in MultiFinder (or is it in Finder?). >>When an application other than the Finder is frontmost, the Finder can >>of course still have windows open, but they'll all be inactive. At >>least they'll all *look* inactive, but won't be, because clicking on >>the (invisible) zoom box of the one which would have been frontmost >>will bring the Finder to the front, but also cause the window to zoom. >> > This is NOT a bug but a feature. With the latest MultiFinder came a >new bit in the SIZE resource called 'getBackgroundClicks'. If an application >has this bit set, then it only takes one click to bring that application to >the front and in the process continue to handle the event (rather than one to >switch layers and a second to do the action). The Finder does this so that >you can quickly launch an application from another application (if that makes >any sense ??). We have also implemented this 'feature' in the new MicroPhone II >so that our Icons can be quickly activated from the foreground. That's all right as far as it goes, the problem with zoom boxes is that the Finder doesnt handle them uniformly. An application should handle clicks in inactive windows identically, whether the window is inactive because another of the application's own windows is in front, or another application is in front. The Finder handles clicks on close boxes that way: if you cant see the close box, clicking just brings the window to the front, doesnt close it. If a Finder window is behind another Finder window, you cant see its zoom box, and clicking where the zoom box is just activates the window. But if the Finder is in the background and you click in the invisible zoom box of its inactive front window, it zooms. Not consistent. Not wysiwyg. Not Mac! (And not all that important, just irritating, I hope it gets fixed.) -- Richard Kennaway SYS, University of East Anglia, Norwich, U.K. uucp: ...mcvax!ukc!uea-sys!jrk Janet: kennaway@uk.ac.uea.sys
francis@pawl.rpi.edu (Frank J. Schima) (10/13/89)
I seem to be having a problem using Multifinder on my Mac IIcx. I can open the apple menu just fine and get information about finder and Multifinder, but the menu bar blinks when I select a DA, and nothing else happens. I have 5 Meg RAM, the only INIT file is SAM interceptor. Virus Rx 1.5 shows no infections (run from a bootable floppy), neither does SAM. Does anyone know the problem? Email is fine. -- francis@pawl.rpi.edu - Francis Schima
Adam.Frix@f200.n226.z1.FIDONET.ORG (Adam Frix) (10/14/89)
Frank J. Schima writes: > I seem to be having a problem using Multifinder on my Mac IIcx. I can > open the apple menu just fine and get information about finder and > Multifinder, but the menu bar blinks when I select a DA, and nothing > else happens. I have 5 Meg RAM, the only INIT file is SAM interceptor. > Virus Rx 1.5 shows no infections (run from a bootable floppy), neither > does SAM. Does anyone know the problem? Email is fine. Aha. This is getting trickier, as the symptoms change but the problem remains the same. Your menu bar is flashing because you have the volume turned down to 0 in your General cdev. When volume is set to 0, the menu bar flashes instead. So what you're getting is the infamous beep when trying to open DAs under MultiFinder--which, of course, is caused by either not enough memory to open the DA, or that the file DA Handler is not in your System folder. --Adam-- -- Adam Frix via cmhGate - Net 226 fido<=>uucp gateway Col, OH UUCP: ...!osu-cis!n8emr!cmhgate!200!Adam.Frix INET: Adam.Frix@f200.n226.z1.FIDONET.ORG