Polling the mouse

[Jim Hurley]

Title: Polling the mouse

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