Polling the mouse

[Jim Hurley]

Jim Hurley wrote:

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


Scott Rainey wrote:

>Yes.  The full list of functions to avoid because they are deprecated is:
>the mouse
>the mouseClick
>the mouseH
>the mouseV
>the mouseLoc
>the optionKey
>the commandKey
>the controlKey
>
>And the very worst thing to do with any of these is "repeat until
><function>", which will condemn you to the fires of eternal damnation
>in multiuser hell ;-)
>
>The last 3 can be safely acquired with "the keysDown", but be careful
>to not sit in a repeat loop calling that or you may hang your app or
>at the very least have the gods of multiuser development strike you
>down.
>
>And while we're on the subject of bad technique that will cause you
>grief at some point, also avoid using the following messages:
>mouseStillDown
>mouseWithin
>idle
>
>That's it.  Not a long list, and in all cases it's very easy (I would
>even in most cases say trivial) to do it the right way.  A small price
>to pay for shrugging off the last of the circa 1984 single-user
>single-tasking design of MacOS and HyperCard.
>   Regards,
>     Scott

After 35 years as a professor of physics, it has been my experience 
that trivial is in the mind of the beholder.

Scott is quite right is pressing *developers* not to anger the "gods 
of multi-user development." But there is also another class of user, 
one to which Run Rev is trying to appeal, and that is the *student* 
who is using HyperTalk as a computer language--perhaps as young as 
eighth grade. And this user would be programming in the development 
environment and would be unconcerned with tying up the CPU.

For some time I have been using HC, MC and/or RR to build Turtle 
Graphics into HyperTalk and allow grade school students to use the 
package to program their own solutions to problems in mathematics and 
physics. There are two areas in this work in which HyperCard is quite 
superior to MC or RR. (And there are many others, of course, in which 
MC and RR are infinitely superior to HC.) The most serious problem is 
the glacial speed with which MC draws images (in many cases this 
problem is lethal) and the second, and much less important, is the 
problems students have in polling the mouse.

There appears to be no remedy in the offing to the speed problem. 
However, regarding mouse-polling, my earlier question dealt with the 
reliability and continued viability of the mouseClick function.

As an example, students create a button which, when clicked, sends a 
satellite on its way into orbit around the earth--leaving a line in 
its wake to show the trajectory. (The student has programmed the 
turtle to obey the laws of Newtonian gravity.) When the student is 
satisfied with the length of the trajectory, he or she clicks again 
(anywhere on the screen) to stop the process. This is accomplished 
with a "repeat until the mouseClick" or "if the mouseClick then exit 
repeat."

So my question is three-fold:

1. Is this a reliable operation given the current state of the MC 
engine? That is, is there a bug similar to that in "repeat until the 
mouse is down?"
2. We know that we may lose the mouse() function in the future. Is 
mouseClick vulnerable as well?
3. If mouseClick will not be an option, what is the work-around so 
that the student may click anywhere on the screen to exit a repeat 
loop, and hopefully one which is simple enough for an eighth grader 
to discover? (Since the student clicked the button to start the 
process, it is more natural to click again to stop the process. It 
would be awkward to have to move to the keyboard.)

Jim Hurley
-- 
Jim Hurley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.runrev.com/pipermail/use-livecode/attachments/20020221/8c417bdb/attachment.html>