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 _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
