> >Message: 7 >Date: Tue, 19 Feb 2002 11:46:23 +0100 >Subject: Re: Boxes, Grids, & Snap to Objects >From: Klaus Major <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Reply-To: [EMAIL PROTECTED] > >Hi Ian, > >> I don't like the grab command, it seems to me program flow doesn't >> stop, >> i.e. >> >> Grab me >> Beep >> >> Will beep immediately even though you're still dragging the thing >> around the >> screen. This means you'll need to use a mouseup handler to do the new >> location stuff instead. >> >> I find it much better to hide the cursor, and set loc of the object >> needing >> dragging to the mouseloc, this is done in a "repeat while the mouse is >> down" loop and lets me do clever things, I can check if the mouseloc is >> within the bounds of another object, and if so hilite that object, etc. >> It's much more flexible. >> ... > >maybe you missed some of the previous posts, where experts (!) are >advising to >not poll the mouse-state. > >It is far more efficient to use the mousemove function.
This issue of polling the mouse state continues to crop up. I have had to avoid the use of the old HyperCard standby: "repeat while the mouse is down" not so much because I worry about burdening the CPU but more importantly because there is a bug in the MC engine which causes it to fail quite regularly. (Very often the MC engine fails to recognize when the mouse the mouse state changes to up.) And Scott says that fixing this bug is not high on the priority list. I regularly use "repeat until the mouseClick" without the same problems I experience with the mouse function. My question is: Does the advice to stay away from polling the mouse extend to the mouseClick function as well? Scott has warned that the mouse() function may/will be discontinued. How about mouseClick()? Is it also in jeopardy? -- Jim Hurley _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
