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 > > <function>", 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 doing a lot of other stuff in the background (like running movies or animated GIFs). Polling with send .. in and the mouseLoc is one way around the problem, but in general this approach (let alone using "repeat until ...") will result in a *less* responsive application because a lot of extra work is being done compared with the optimal solution of just using the mouseMove messages. > 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. And the fact that they're synchronous now, though this is actually "fixed" for the optionKey/commandKey/shiftKey functions in 2.4.2, was fixed for the mouseLoc awhile back, and could easily be fixed for the mouse function. It is just the mouseClick that is hard to solve any other way. > 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? Sounds reasonable to me, but given the number of bug reports we've received on this issue, you and I may be in the minority. Regards, Scott > Curry Kenworthy ******************************************************** Scott Raney [EMAIL PROTECTED] http://www.metacard.com MetaCard: You know, there's an easier way to do that... _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution