home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!caen!zaphod.mps.ohio-state.edu!osustat.mps.ohio-state.edu!dsb
- From: dsb@osustat.mps.ohio-state.edu (David S. Blumenthal)
- Newsgroups: comp.sys.mac.programmer
- Subject: Re: Super-Floating Windows
- Date: 10 Nov 1992 21:08:06 GMT
- Organization: OSU Statistical Computing Laboratory
- Lines: 28
- Distribution: world
- Message-ID: <1dp8bmINN1av@zaphod.mps.ohio-state.edu>
- NNTP-Posting-Host: osustat.mps.ohio-state.edu
-
- Thanks to all who have contributed to this thread so far. It has helped me
- out immensely.
-
- I've done some testing with the "hole in GrayRgn" approach, and it works
- sufficiently. I think that as long as the part of GrayRgn that the window
- removes does not stop corresponding to a piece of a monitor, there shouldn't
- be any foreseeable problems. If it does, however, any window in that area
- will be affected.
-
- As pointed out, menus function correctly over the affected region. However,
- the window manager does not ignore GrayRgn - update events are not generated
- for my window. Does anyone have any good ideas on how to determine when part
- of my window must be redrawn? Do InvalRect and InvalRgn check for intersection
- with GrayRgn? If not, could I check for intersection between my holeRgn and
- the window port's updateRgn? When would I do this?
-
- The only other events I am interested in are mouseDown and mouseUp. These get
- to the window without regard to GrayRgn. In order to catch all clicks over my
- window, regardless of what would normally overlap, and of what application is
- frontmost, I will patch SystemEvent and check theEvent.where (as suggested by
- the UseNet Mac Programming Guide).
-
- I really appreciate your comments.
-
- -----------------------------------------------------------------------
- | Dave Blumenthal | The Ohio State University |
- | dsb@osustat.mps.ohio-state.edu | Statistical Computing Laboratory |
- ------ There is a fine difference between insight and insanity. -------
-