tomc@mntgfx.mentor.com (Tom Carstensen) (04/02/88)
Can someone either point me to an appropriate Tech Note, or explain what exactly the 'sleep' parameter and the 'mouseRgn' parameter are used for in WaitNextEvent. Why isn't their a section about these 'Multifinder' things in Inside Mac V (or did the APDA final draft leave them out). :------------------------------------------------------------: : Tom Carstensen Usenet: tomc@mntgfx.MENTOR.COM : : Mentor Graphics Delphi: CARSTENSEN : : GEnie: XPC23637 : : : : . . . AAhh! I see you have a machine that goes PING! : : - Monty Python : :------------------------------------------------------------:
mz@well.UUCP (Michael Zentner) (04/03/88)
The sleep (unsigned long) param to WaitNextEvent is the time (in ticks) to relinquish the processor if no events are pending. The mouse (RgnHandle) param is used to allow non-critical mouse movements. It specifies a region within which you don't care if the mouse moves around, like the cursor doesn't change, etc. If the mouse moves outside this region, the application will get a "moused moved" event, which is a null event with new mouse co-ordinates. I haven't actually used all this yet, I'm just quoting the Release Note of 8-6-87. .
laba-5as@web8f.berkeley.edu (Bob Heiney) (04/05/88)
In article <5587@well.UUCP> mz@well.UUCP (Michael Zentner) writes: > > >The mouse (RgnHandle) param is used to allow non-critical mouse movements. >It specifies a region within which you don't care if the mouse moves around, >like the cursor doesn't change, etc. If the mouse moves outside this region, >the application will get a "moused moved" event, which is a null event with >new mouse co-ordinates. > WaitNextEvent does not send a null event for mouse-moved. Instead, it sends the MultiFinder event (app4Evt) and the high byte of the message longint is $FA. The low 3 bytes are reserved by Apple. Upon receiving this event, an application should figure out what the proper cursor should be and then figure out a new mouse region. The point to this is that your application can give up lots of time to background tasks if it is in the foreground without worrying about the user moving the mouse somewhere where a cursor-change would have to occur. I've used WaitNextEvent in a text-editing application and it works great. If the mouse in in my current window, then the cursor is an I-beam, and the mouse region is just the viewRect of my TextEdit record. Note that this region is in GLOBAL coordinates (see the MultiFinder developer's package for the note on this). When the users moves out of the region, my application wakes up and calls a routine I have, FixCursor, that makes the cursor whatever it should be (usually an arrow), and sets the mouse region to be all of the screen EXCEPT for the viewRect. Those wishing to be Mac II compatible should use GetGrayRgn (or is it GetGreyRgn?) to get the region for the screen, since there can be more than one screen in the system. Here's a sample code fragment: tempRect:=myTextHandle^^.viewRect; LocalToGlobal(tempRect.topLeft); LocalToGlobal(tempRect.botRight); RectRgn(mouseRgn,tempRect); { I believe this is the call, but I'm typing from memory :-) } DiffRgn(GetGrayRgn,mouseRgn,mouseRgn); { now mouseRgn is the entire screen except for a hole where viewRect is } One more thing: Applications that use TextEdit have to wake up every now and then to call TEIdle. A sleep time of 20 ticks seems to be good. ---------------------------------------------------------------------- "... To boldly go where no one has gone before!" Bob Heiney laba-5as@widow.berkeley.edu
cute@sphinx.uchicago.edu (John Robert Cavallino) (04/05/88)
In article <8335@agate.BERKELEY.EDU> laba-5as@widow.berkeley.edu.UUCP (Bob Heiney) writes: (explaination of MultiFinder mouseMoved events deleted) >When the user moves out of the region, my application >wakes up and calls a routine I have, FixCursor, that makes the cursor >whatever it should be (usually an arrow), and sets the mouse region to >be all of the screen EXCEPT for the viewRect. > >Those wishing to be Mac II compatible should use GetGrayRgn (or is it >GetGreyRgn?) to get the region for the screen, since there can be more >than one screen in the system. Following this suggestion introduces a "GOTCHA" in that the GrayRgn includes neither the menu bar nor the tiny areas beyond the rounded corners at the outside corners of the screen (or union of screens). Since the mouse cursor can enter these areas, a more correct way to construct a full-screen(s) region for cursor tracking is the following: a) Use SysEnvirons to check for Color Quickdraw b1) if it isn't present, just RectRgn(cursorRgn,screenBits.bounds) b2) if it is present, construct a region that is the union of the device rects of all ACTIVE gDevices. The fields are all documented in IM.V (which I don't have in front of me). To test if a gDevice is active you should use GetDeviceAttribute. > > tempRect:=myTextHandle^^.viewRect; > LocalToGlobal(tempRect.topLeft); > LocalToGlobal(tempRect.botRight); > RectRgn(mouseRgn,tempRect); { I believe this is the call, > but I'm typing from memory :-) } > DiffRgn(GetGrayRgn,mouseRgn,mouseRgn); > { now mouseRgn is the entire screen except for a hole where > viewRect is } > >Bob Heiney >laba-5as@widow.berkeley.edu l i n e s l i n e s l i n e s -- ...ihnp4!gargoyle!sphinx!cute --John Cavallino The train is the same, only the time is changed. Ecce homo, ergo elk.