Re: Polling the mouse

[Scott Raney]

On Thu, 21 Feb 2002 Curry <[EMAIL PROTECTED]> wrote:
> 
> Scott Raney 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
> > ", which will condemn you to the fires of eternal damnation
> > in multiuser hell ;-)

I noticed you CCed the MetaCard list, which is a good thing, I guess,
though they're getting dumped into the middle of the discussion.
Here's the key part of my previous message, just to bring them up to
speed:

  The long answer, and probably much more than you want to know, is
  that "the mouseClick" is really the problem here, not "the mouse".
  "the mouse" could in theory be done asynchronously.  If this were
  changed you'd still have the performance issue to deal with (i.e.,
  "repeat until" would never be as smooth as using mouseMove messages
  and would eventually cause the OS to start penalizing your app), but
  reliability wouldn't because this information can be queried
  directly from the OS on all platforms.  You'd also be subject to the
  normal behavior of async functions (e.g., in HC, "the mouse" returns
  "down" if the user clicked down anytime between when the handler
  started running and when the function is called, whereas an async
  implementation would only return "down" if it was actually down when
  you made the call).

  The problem with "the mouseClick" is that of state management and
  event order: it has to wait for the mouse to go down and then back
  up.  Worse, at least for HC compatibility, is that if you do
  something in a script that takes a few seconds and click twice in
  that interval, "the mouseClick" will return true *twice*.  This
  means that it's necessary to maintain a queue of these mouse events
  and check the whole queue each time the function is called to see if
  there is both a mouseDown and a mouseUp message in it, and pull them
  out as a pair if so.  And of course you can't just leave the rest of
  the events in the queue either, because some of them (like socket
  events and redraws) need to be handled independently of what the
  currently running handler is doing.  Doing this cross-platform is
  horrendously complicated, and results in compromized reliability for
  *everything*, not just the mouseClick function.  Which is why we
  want to (and plan to) remove this functionality, or at least
  substantially modify it to remove this queueing aspect (e.g., the
  mouseClick would return true only if you clicked down and up any
  time between the start of the handler and when you made the call,
  and once it returned true *all* state information would be tossed
  out so it wouldn't return true again until the user clicked again
  after the function returned true, even if they clicked multiple
  times before the first call).

It'd also be good to discuss the topic of sync/async polling on the HC
and SC mailing lists to get a sense of how aware people are of this
issue (I just responded to one poster on the use-revolution list who
wasn't aware of this behavior of the mouse function, though lord knows
we got enough bug reports about this back when MetaCard did a simple
async report).

> Scott, I understand the problems of the OS penalty due to hogging the
> computer with polling of mouse functions during a repeat, but there are
> different kinds of software; in some cases, we may want to make software
> that is supposed to be the only main application running on a computer, for
> example, a game, a presentation, or an educational application with a lot of
> animation.
> 
> Often, the documentation may even advise users of these types of programs to
> not run other applications unnecessarily at the same time for better
> performance. With these types of applications, often you would be
> ill-advised to run other major software at the same time anyway, not just
> because of its effect on the other software, but also because of other
> software's effect on it.

Understood, and that's why we added the keysDown function, which is a
much better way to do this kind of thing than using keyDown messages
and the optionKey/commandKey/shiftKey functions.  I guess all that
remains is a async mouse polling function, but we never considered
this necessary because using message is always possible (and always
preferred) in this case.

> For example, in one game project, I started off with the mouseMove message,
> and then had to switch to send..in plus the mouseLoc (once per handler),
> because mouseMove was not nearly responsive enough. (The object was always
> moving toward the mouse, but at its own speed, not directly tied to the
> mouse.) This was much more responsive.

I can't see why this would be the case unless you're running on a very
slow system, moving very large objects or a large number of objects,
or maybe doi

Re: Polling the mouse

[Curry]

Scott Raney 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
> ", which will condemn you to the fires of eternal damnation
> in multiuser hell ;-)

Scott, I understand the problems of the OS penalty due to hogging the
computer with polling of mouse functions during a repeat, but there are
different kinds of software; in some cases, we may want to make software
that is supposed to be the only main application running on a computer, for
example, a game, a presentation, or an educational application with a lot of
animation.

Often, the documentation may even advise users of these types of programs to
not run other applications unnecessarily at the same time for better
performance. With these types of applications, often you would be
ill-advised to run other major software at the same time anyway, not just
because of its effect on the other software, but also because of other
software's effect on it.

For example, in one game project, I started off with the mouseMove message,
and then had to switch to send..in plus the mouseLoc (once per handler),
because mouseMove was not nearly responsive enough. (The object was always
moving toward the mouse, but at its own speed, not directly tied to the
mouse.) This was much more responsive.

There are comparable situations with the other functions. I have no problem
with the mouseClick going out. It's an obvious case. But I think it would be
terrible to remove the others functions which were mentioned. As Scott said,
it's using them with repeats that causes the problems.

So, first, can we be assured that these functions will still remain, at
least asynchronously, in the future? Otherwise, if the corresponding
messages don't work well enough for a certain task, we will be in a jam
someday.

Secondly, using these functions synchronously allows much more convenient
scripting for testing, personal projects, students (as someone mentioned),
etc. Why not keep the functions synchronous, with the exception of
mouseClick which could be turned asynchronous or simply trashed, and leave
the responsibility of using them correctly up to the scripter?

If a function is only called once per handler, it still won't hurt the
system if called synchronously. For those making utilities and well-behaved
games or educational apps that aren't full-screen or intensive, that would
allow them to have a way to check once or twice within a handler and be
assured of an accurate result.

For those making full-screen or intensive apps, or testing or making
projects for personal use, they could choose to poll these functions and
take the consequences. If used wrongly, like anything else if life, they
could cause problems, but that's what life is all about--using things the
right way according to the situation. Any professional developer would avoid
them where necessary. I think that avoiding these functions shouldn't have
to be forced on all users in all situations just because it would be unwise
some users in some situations.

Ever since switching to Revolution, I've marvelled at how it is really such
"an easier way to do that". I love everything about it. But I hope you will
listen to all the users about this type of feature, since all of us are
paying the subscription price, not just those who will definitely not miss
these features because of the type of projects they do. Since it isn't
absolutely necessary to remove all the features (the mouseClick is the main
problem) and it isn't absolutely necessary to make the functions
asynchronous as long as the scripter can be trusted to use them correctly
according to the situation, I suggest that these changes not be forced on
everyone.

People really *can* choose to do the right thing. And any professional
developers, or users in the appropriate situations, *will*. So on behalf of
all those who want to make scripting choices, please keep the old power in
there--we only need an FAQ, not a nanny! There's no reason to take away
useful scripting features everyone writing scripts as a student, for
personal use or testing, or making special types of software just because it
can hurt someone else if used incorrectly. We all must be responsible for
ourselves. If someone hogs the wrong CPU and it penalizes them, they may not
care if they are working on a personal project for their own use. If not,
they will fix it.

That's my two cents--maybe it's three cents. I think this is a pretty
important issue. It's not just about sentimentality--although those
functions, used with and without repeat--are a very important part of
scripting up to now in history. Going forward is good, but cutting out old
ways altogether is not always good. It's easy for one group of people to
decide that we must be resolute and the old way should be discarded, but
som