dcbii@ncrcae.Columbia.NCR.COM (dcbii) (11/14/89)
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 before DaMenuz does? (Without turning off the hierarchical menu-bar option?) Is this even possible? Thanks in advance for any possible help, Dave Barnhart NCR Corp. Engineering & Manufacturing West Columbia, SC 29169
mnkonar@gorby.SRC.Honeywell.COM (Murat N. Konar) (11/15/89)
In article <5364@ncrcae.Columbia.NCR.COM> dcbii@ncrcae.Columbia.NCR.COM () writes: >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. Apple explicitly states that you are not to draw in the desktop unless it is a temporary effect (like window zooming in the Finder). You're trying to get a job at Microsoft, right? :) ____________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)
earleh@eleazar.dartmouth.edu (Earle R. Horton) (11/15/89)
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
tim@hoptoad.uucp (Tim Maroney) (11/16/89)
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