maye_ltd@uhura.cc.rochester.edu (Robert Mayer) (11/16/90)
devil was Shadow.setup2 designed to do. As far as I can find there are no dox to be found anywhere. I assume that it has something to do with graphics... mainly due to it's rather bizzare interaction with Deluxepaint II. Has anyone else had the rather odd problem with Shadow.setup running under 5.0.3 eating the menu bars in Deluxepaint? To describe: when you move to the far right of the screen to select different tools/brushes/whatnot the pointer simply paints over the menu in white. The menu can be restored my hitting 0 to clear it then 0 to restore. This will not rectify the problem with it being "eaten" but will let you see what's going on again. It also tracks white over the picture, although it only seems to affect what is printed to the screen, as opposed to the actual picture file. In any case it is a rather odd condition, and went away as soon as I pulled Shadow.setup2 out of the system.startup folder. It's not a real problem, but I would dearly love to know just what in the world it was designed to do, as a routine that would overprint the screen while not altering the picture beneath is rather neat...although this was clearly not the intent. Upon further reflection I wonder if it could just be some bizzare confusion with the ROM 3 version? In any case, it's late, I'm tired, and this is all just too odd for now... _____________________________________________________________________________ | Robert Mayer | The ideas in this message do not | | maye_ltd@uhura.cc.rochester.edu | necessarily reflect those of the author| | MAYELTD@UORVM.BITNET | or anyone else for that matter... | |___________________________________|_________________________________________| | | | 1000101 1000101 1001011 01000001 <-- You do the translation | |_____________________________________________________________________________|
avery@netcom.UUCP (Avery Colter) (11/25/90)
Correct me if I'm wrong, but I think the Shadow.Setup was supposed to
take the menu boxes and draw them so that they have those cute little
offset shadows that one sees on the Mackensteins which make the menu
boxes look raised above the desktop background like so many glorious
cabinet drawers.
--
Avery Ray Colter {apple|claris}!netcom!avery {decwrl|mips|sgi}!btr!elfcat
(415) 839-4567 "I feel love has got to come on and I want it:
Something big and lovely!" - The B-52s, "Channel Z"ifar355@ccwf.cc.utexas.edu (David H. Huang) (11/27/90)
In article <17402@netcom.UUCP> avery@netcom.UUCP (Avery Colter) writes: > >Correct me if I'm wrong, but I think the Shadow.Setup was supposed to >take the menu boxes and draw them so that they have those cute little >offset shadows that one sees on the Mackensteins which make the menu >boxes look raised above the desktop background like so many glorious >cabinet drawers. > >-- >Avery Ray Colter {apple|claris}!netcom!avery {decwrl|mips|sgi}!btr!elfcat >(415) 839-4567 "I feel love has got to come on and I want it: > Something big and lovely!" - The B-52s, "Channel Z" I think menus already have a drop shadow. The Shadow.Setup program is supposed to speed up QuickDraw II by forcing programs to use memory shadowing from bank 01. BTW, does anyone know what happens if another program is already using that space? Orca/M seems to use memory in the 1/2000 area. -- David Huang | "I didn't order any Internet: ifar355@ccwf.cc.utexas.edu | pizzas, especially America Online: DrWho29 | green ones"
meekins@CIS.OHIO-STATE.EDU (timothy lee meekins) (11/27/90)
In article <40190@ut-emx.uucp> you write: >In article <17402@netcom.UUCP> avery@netcom.UUCP (Avery Colter) writes: >> >>Correct me if I'm wrong, but I think the Shadow.Setup was supposed to >>take the menu boxes and draw them so that they have those cute little >>offset shadows that one sees on the Mackensteins which make the menu >>boxes look raised above the desktop background like so many glorious >>cabinet drawers. >> > >I think menus already have a drop shadow. The Shadow.Setup program is supposed >to speed up QuickDraw II by forcing programs to use memory shadowing from bank >01. Because bank one runs at system speed, and bank $E1 (default) is only at 1 MHz. ^^^--(well, you do reads and writes at this speed) > >BTW, does anyone know what happens if another program is already using that >space? Orca/M seems to use memory in the 1/2000 area. > If $01/2000.$9FFF is being used by another program, then QD II will use bank $E1. So..... if you ever request to use bank 1, and wish to do direct memory writes, make sure you're actually using this memory. Almost always you'll get this memory, BUT, if you're using the Orca/APW shell, you'll almost never get this memory, Orca hogs. In my Software Experience demo awhile back, I did direct page 1 writes w/o checking, so about 50% of the time I had to reboot Orca.. I have had no problems with any other launcher, including the Finder. I've never let this problem bother me, but offhand, does anyone know how to tell which bank QD II is using? >-- >David Huang | "I didn't order any >Internet: ifar355@ccwf.cc.utexas.edu | pizzas, especially >America Online: DrWho29 | green ones" ------------------------------------------------------------------------------- >> Tim Meekins <<>> Snail Mail: <<>> Apple II << >> meekins@cis.ohio-state.edu <<>> 8372 Morris Rd. <<>> Forever! << >> timm@pro-tcc.cts.com <<>> Hilliard, OH 43026 <<>> << -------------------------------------------------------------------------------
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (11/27/90)
meekins@CIS.OHIO-STATE.EDU (timothy lee meekins) writes: >I've never let this problem bother me, but offhand, does anyone know how to >tell which bank QD II is using? In an early issue of 8/16, there was an animation article in which QD was started up and then the LocInfo record of the current grafport (i.e. the whole screen) was examined to determine the address. Methods like this are very advisable because they can't crash the system in the future. Todd Whitesel toddpw @ tybalt.caltech.edu
jb10320@uxa.cso.uiuc.edu (Desdinova) (11/27/90)
In article <9011261818.AA06121@inch.cis.ohio-state.edu> meekins@CIS.OHIO-STATE.EDU (timothy lee meekins) writes: > [...] >this memory, Orca hogs. In my Software Experience demo awhile back, I did >direct page 1 writes w/o checking, so about 50% of the time I had to reboot >Orca.. I have had no problems with any other launcher, including the Finder. > >I've never let this problem bother me, but offhand, does anyone know how to >tell which bank QD II is using? Yeah. There's an address in the grafport structure. It should be the address of the bit map, which would be one hires area or the other. -- Jawaid Bazyar | Blondes in big black cars look better wearing Senior/Computer Engineering | their dark sunglasses at night. (unk. wierdo) jb10320@uxa.cso.uiuc.edu | The gin, the gin, glows in the Dark! Apple II Forever! | (B O'Cult) Comp.Sys.Apple2- Home of the Unofficial Apple II Developer Support Team (DST)
taob@pnet91.cts.com (Brian Tao) (11/27/90)
> Correct me if I'm wrong, but I think the Shadow.Setup was supposed to > take the menu boxes and draw them so that they have those cute little > offset shadows that one sees on the Mackensteins which make the menu > boxes look raised above the desktop background like so many glorious > cabinet drawers. But all menus since GS/OS 1.0 came out had the little shadow on the menus. We just don't have the shadow for the windows yet (which the Mac does). Big deal... \/\/\/\/\/\/\/\/\/ | Brian T. Tao | UUCP: torag!pnet91!taob | / \ | University of Toronto | INET: taob@pnet91.cts.com | \ The Apple II / | Scarberia, ON | taob@pro-micol.cts.com | / Lives On!! \ |:::::::::::::::::::::::::::::::::::::::::::::::::::::::| \ / | "Computer guru? Someone who got their computer a | /\/\/\/\/\/\/\/\/\ | couple of weeks before you did." (Alvin Toffler) |
MQUINN%UTCVM@PUCC.PRINCETON.EDU (11/28/90)
On Mon, 26 Nov 90 22:14:27 GMT Todd P. Whitesel said: >meekins@CIS.OHIO-STATE.EDU (timothy lee meekins) writes: > >>I've never let this problem bother me, but offhand, does anyone know how to >>tell which bank QD II is using? > >In an early issue of 8/16, there was an animation article in which QD was >started up and then the LocInfo record of the current grafport (i.e. the >whole screen) was examined to determine the address. Methods like this are >very advisable because they can't crash the system in the future. This is exactly what I've been looking for. Could someone post some sample source code to demonstrate getting that address? (preferably in assembly?) Thanks > >Todd Whitesel >toddpw @ tybalt.caltech.edu ---------------------------------------- Michael J. Quinn University of Tennessee at Chattanooga BITNET-- mquinn@utcvm pro-line-- mquinn@pro-gsplus.cts.com