Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcvax!uvabick!thomas
From: thomas@uvabick.UUCP (Thomas Fruin)
Newsgroups: comp.sys.mac
Subject: Re: Window Manager problem (perhaps even a bug)
Message-ID: <226@uvabick.UUCP>
Date: Fri, 17-Jul-87 13:17:05 EDT
Article-I.D.: uvabick.226
Posted: Fri Jul 17 13:17:05 1987
Date-Received: Sat, 18-Jul-87 19:22:14 EDT
Organization: uvabick
Lines: 73


There have been several replies and suggestions after my Window Manager
query.  Thanks to everyone.  However, the question still stands.

Let me first state that I _have_ implemented multiple palette/ghostwindows
in Aztec C.  Everything works fine.  My code supports several palettes that
always lie on top, except when a desk accessory gets opened or clicked.
Then the disk accessory gets put on top.  The "top" document window gets
highlighted and activated normally.  All windows can be dragged in their
own plane, or are brought to the position just behind the last ghostwindow
and then dragged.

Several people suggested using the GhostWindow global.  I've found it to be
quite useless, because 1) its mechanism only supports ONE ghostwindow and
2) it does very little.  Inside Macintosh says that GhostWindow can be made
to point to a window that's not to be considered frontmost even if it is.
Read those words carefully.  It says nothing about what to do when you want
to change the ordering of windows behind it.

MacTutor's article about Palette windows is nice, but doesn't really help in
this situation.  It describes one popup window and only works when the
windows below it don't change while the popup is visible.  Thanks for the
pointer though.

Someone also mentioned that the low-level Window Manager calls I was using
weren't preserving the current port.  Fortunately I never ran into that
problem.

Gregory Stein writes:
> I have implemented a palette with LSC.  I found that keeping the
> window in the BACK rather than the front is painless and avoids
> many of the problems of trying to hide it in the front.  The Toolbox
> has nothing against handling clicks in windows that aren't in the
> front.  Just keep everything the same, but don't do a SelectWindow
> on the palette's window when you click in it.  Also, since you'll
> probably be using a plain dialog box for the palette, you won't have
> worry about any hiliting effects.

We probably have very similar code.  I don't call SelectWindow either to
bring a window to the "front" (just behind my ghostwindows).  This is where
I use SendBehind.  And being a good boy, I called PaintOne and CalcVis after-
wards (see Inside Macintosh, I-286).  This is where I think IM fails.  It
makes a genuine suggestion, but it is wrong here.  Change CalcVis to
CalcVisBehind and and everything works as it should.  So this particular
question remains: I am right in assuming this and is Inside Macintosh wrong?

When I have my code cleaned up and commented, I'll be happy to post it.
For now, see my modified SelectWindow.  For simplicity I'm assuming there
is only one ghostwindow, there are no desk accessories and every window is
visible:

  /* Unhighlight and deactivate the current "front" window */

  HiliteWindow( myGhostWindow->nextWindow, FALSE );
  curDeactive = myGhostWindow->nextWindow );

  /* Bring myWindow to "front", redraw it, recalculate its visible region
     and the regions of the windows behind it, highlight and activate it.*/

  SendBehind   ( myWindow, myGhostWindow );
  PaintOne     ( myWindow, myWindow->strucRgn );
  CalcVisBehind( myWindow, myWindow->strucRgn );
  HiliteWindow ( myWindow, TRUE );
  curActivate = whichWindow;

That's all folks!

-- Thomas Fruin

   fruin@hlerul5.BITNET
   thomas@uvabick.UUCP

   Leiden University, Netherlands