Path: utzoo!attcan!sobmips!uunet!cs.utexas.edu!mailrus!iuvax!purdue!bu-cs!dartvax!eleazar.dartmouth.edu!earleh
From: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Updating a non-window area
Message-ID: <16976@dartvax.Dartmouth.EDU>
Date: 15 Nov 89 06:33:19 GMT
References: <5364@ncrcae.Columbia.NCR.COM>
Sender: news@dartvax.Dartmouth.EDU
Reply-To: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Organization: Thayer School of Engineering
Lines: 49

In article <5364@ncrcae.Columbia.NCR.COM> dcbii@ncrcae.Columbia.NCR.COM
	() writes:
>I am fairly new to mac programming, and I have a question that I'm sure some
>of you can answer or at least, provide a workaround.
>
>My application does drawing directly to the desktop area.  The drawing is done
>offscreen and then CopyBits'd to the screen.  That part is no problem.
>
>My problem is that I don't know when to update the area after a DA or another
>window has drawn over the area.  I have searched the Inside Mac volumes and
>Macintosh Revealed, but I can't seem to find a way to get a pseudo update
>event for a non-window area.  Does anyone know how this can be done?  I don't
>want to use a window, because I don't want any frame.  Of course, if I can
>make a window look like the desktop area, maybe that will work, too.
>
>Also, how can I get a mouse-click event in the desktop area...?

     If you put a procedure pointer in the low memory variable
DeskHook ($0A6C), then the pointed-to procedure will be called

  (a) With a 0 in register D0 to update the desktop as needed by filling in
      thePort^.clipRgn.
  (b) With a -1 in D0 when the mouse button is pressed in the DeskTop.
      A0 contains a pointer to the event record for the mouse down event.

     Unfortunately, this method does not work too well under
MultiFinder, because the Finder and MultiFinder conspire together to
manage the desktop themselves.  Technical Note #194: "WMgrPortability"
describes some of the problems that arise if you draw directly on the
desktop.  It also describes how you can draw some kinds of things
outside of windows safely.

     If the thing which you are trying to draw has a shape which may
be expressed as a region, then you can implement it as a window.  If
you use your own window definition procedure, then your window need
not have a frame, be rectangular, or even look like a window at all.
If you use this method, then getting mouse down events in your
"window" is easy.  The only drawback is that if you are operating
under MultiFinder, then your window-objects that you want to be on the
desktop will actually follow your layer, possibly obscuring other
application's windows or the junk that the Finder draws on the
desktop.

     Do not be deceived by the fact that the Finder draws things on
the desktop into thinking that other applications may do so in like
fashion.  At present there is no means of arbitration among processes
which wish to use the WMgrPort, and so only the Finder gets to do so.

Earle R. Horton