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