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
> <function>", 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
sometimes this can be group-think, and others outside the group may have
legitimate reasons for needing the original way, and it may cause
unnecessary difficulties for some of them in their situations.

So, I'm very happy and grateful to where MetaCard is going, and I admire and
respect the great vision of the MetaCard and Revolution teams, but I want to
strongly oppose and speak out clearly against the idea of cutting out these
functions, or even making all of them asynchronous.

I fled from several other developer tools because every aspect of the
development tool was forced on users because of the developer's viewpoint.
The MetaCard experience is just the opposite, allowing much flexibility,
style, and convenience along with its serious power--which is why I think it
would be a very, very big mistake to cut these functions. I don't think it's
at all necessary to do so. I hope other users will speak up if they agree.

Curry Kenworthy


_______________________________________________
metacard mailing list
metacard at lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard