Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Updating a non-window area
Message-ID: <8994@hoptoad.uucp>
Date: 15 Nov 89 20:25:19 GMT
References: <5364@ncrcae.Columbia.NCR.COM>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 54

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.

Yes, I'm afraid it is.  Your application is expressly forbidden from
drawing into the desktop.  It will create problems under MultiFinder,
and it may even break on future machines (for instance, a graphics
coprocessor might assume your application is well-behaved).

>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?

You can use the DeskHook low-memory global routine pointer (IM I-282),
but I don't recommend it.

>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.

You can do that, but you'd better hide that window on a suspend event.
It's pretty easy to make a window of the right size, with no window
frame visible, but you will have to make sure it does not hang around
when your application is in the background under MultiFinder, and you
may find that it's more difficult to do common window management tasks
like selecting windows by clicking on them -- you have to keep your
pseudo-Desktop window the hindmost window at all times.

>Also, how can I get a mouse-click event in the desktop area before DaMenuz
>does?  (Without turning off the hierarchical menu-bar option?)  Is this even
>possible?

I have no idea what DaMenuz is, but now you're really out of bounds.
How is the user supposed to click on a Desktop area that's obscured by
other windows in MultiFinder?  However, if you use a pseudo-Desktop
window, then this becomes trivial.  If you simply must do it the messy
way, then you can again use DeskHook, this time as documented in IM
I-288.

But I have to say, I don't think you've looked at the problem hard
enough.  You shouldn't have to draw into the dektop, and you definitely
shouldn't have to make the user click there.  Have you really searched
for alternatives?
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"`Truth' never set anyone free.  It is only *doubt* which will bring
 mental emancipation."
        -- Anton LaVey, quoted by Arthur Lyons, SATAN WANTS YOU