Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ut-sally.UUCP
Path: utzoo!linus!decvax!ucbvax!ucdavis!lll-crg!seismo!ut-sally!robdye
From: robdye@ut-sally.UUCP (Rob Dye)
Newsgroups: net.micro.mac
Subject: Re: Palettes: suggestions on how to do them
Message-ID: <3128@ut-sally.UUCP>
Date: Tue, 8-Oct-85 16:10:52 EDT
Article-I.D.: ut-sally.3128
Posted: Tue Oct  8 16:10:52 1985
Date-Received: Fri, 11-Oct-85 07:27:32 EDT
References: <194@mmm.UUCP>
Reply-To: robdye@sally.UUCP (Rob Dye)
Distribution: net
Organization: U. Texas CS Dept., Austin, Texas
Lines: 61

In article <194@mmm.UUCP> schley@mmm.UUCP (Steve Schley) writes:
>A few months back, I solicited suggestions on how to put palettes (like
>MacPaint has) in my application.  I stated that I would summarize the
>responses to the net.
...
>--> Dialog and Control Mgrs are overkill.  Draw palette with QuickDraw,
>calculate MouseDown relative to palette buttons, and do highlighting
>using QuickDraw.  In other words, do all the work yourself.
...
>Finally, I've seen that PageMaker from Aldus uses a very interesting
>mini-palette.  It takes the form of a small, movable window (they call
>it the "toolbox") that is always active and always in front of all
>other windows!  It has eight control areas in it, and it's very handy
>to be able to "float" it around the page -- it's always handy, and
>never in the way of the document.  How do they do it?
>	Steve Schley
>	ihnp4!mmm!schley

	Well, I haven't seen PageMaker, but I just recently hacked together
something which sounds similar.  My palette is a small (four tools the size 
of MacPaint's tools, arranged vertically), drag-able (it has a cute little
drag bar at the top) pseudo-window which is always active and always in 
front (this turns out to be a little disconcerting under some circumstances,
as I will describe later).

	I went about it by "doing all the work myself", i.e., I used QD and 
calculated mouseDowns to see if they were in the palette.  The trick was in
using a relatively undocumented toolbox global called grayRgn (look in the 
WindowMgr chapter of IM under InitWindows, I think).  This is the
desktop region with rounded corners minus the menu bar.  The WindowMgr 
will draw windows clipped to this region (as well as all other appropriate
regions), which is what you would expect since it always avoids drawing on
top of the menu bar. 

	When showing the palette (showing/hiding are controlled
from a menu item), I made use of this fact by subtracting the region
containing my palette from the grayRgn, drawing the palette in the WMgrPort,
then calling CalcVisBehind(FrontWindow(), paletteRgn) (I think that's the 
calling convention) to tell the WindowMgr to recalculate the visRgns of all 
windows intersecting with paletteRgn.  These visRgns will have my paletteRgn
subtracted from them, preventing the window from drawing on my palette
even if the palette is on top of the FrontWindow.

	Note that since the palette is not a window in the WindowMgr sense,
I never *really* have more than one active window.

	The disconcerting aspect of this approach is that the palette literally
shows through everything! When it shows up on top of the OK button of a 
dialog box, it definitely looks like a bug, not a feature!  DAs are no 
exception either.  And since the code for dragging the palette is encountered
in the main loop of the program (and NOT in the event loop for the modal
dialog), you can't drag it out of the way!  Fortunately, clicks on the palette
at this point "pass through" the palette and are received by the dialog box,
but this is obviously not the way things should work.  I'm still trying to 
find the right way to handle this problem.  Suggestions are welcome.

	Right now I'm considering using another relatively undocumented
toolbox global called ghostWindow, and actually implementing the palette
as a WindowMgr window.  So far this has been nothing but a pain in the ass.

	So it goes...