Scott Saults wrote: > My 2�? Revolution should drop "the mouse" function, unless it can be made > to work in a reliable, predictable way, as documented. I can live without it.
Why not take the second option? I say make it work in a reliable way--let it just indicate the real-time mouse button position with a direct call. Drop the HyperCard compatibility rather than dropping the function. (After all, you'd lose a lot more compatibility by removing the whole thing than by altering the behavior to be more straightforward and logical.) I would rather have the mouse give the real position of the mouse--all these buffered behaviors make no sense! As it has been pointed out, most of us don't know the complex behaviors anyway and just expect it to give the mouse value as it is at the time of being called. Surely no one would mind if the behavior is changed, since the alternative considered is to get rid of the whole thing! I already told myself I'd shut up already on this issue after the last post, but sometimes I muddle through a few posts without explaining my intended point as clearly as I tried to, so here goes one more final shot at it. These poor under-appreciated functions are part of the heart and soul of xTalk, allowing us to handle the most common types of interactions in a very intuitive fashion that's easy to learn and convenient to use--without umpteen separate handlers for ups, downs, moves, etc. Come on, people, you'd really rather do that than just say "until the mouse is up" or "if the mouse is down" or "get the mouseH"? Are you really looking at how much you'll be losing? Just because HyperCard made the implementation imperfect and a pain to continue to support compatibly doesn't mean that the concept, syntax, and functionality isn't perfect; it is. Rather than dropping these functions and statements that use these functions, I suggest that MetaCard alter the inner workings and behavior to match what MetaCard needs, and forget about the complex HC behavior. I would prefer simple, direct polling that showed the true state, but something else close to that would also be fine--whatever works for MetaCard, as close to true polling as possible. Then, as far as I could tell, everyone could be happy--people who like separate handlers for OS-friendliness or personal style could use them to their heart's content and pretend the functions no longer exist; people who appreciate the stylish and convenient power of the traditional statements could enjoy them and make good use of them; and hopefully the MetaCard team would have a straightforward way of implementing them that would be a lot easier to support and remove the current problems. I'm a big believer in these functions. They are a familiar and IMHO necessary part of scripting, and other competitive languages for the non-C++ audience, like BASIC, have similar functions. Having two ways to handle these types of interaction--in separate specific handlers and with functions inside other handlers--is the norm. So we need to have both ways too. If the tiny details of the traditional implementation cause problems, it's the tiny details that need to go, but the functions really need to stay. Well, that's it, I'm zipping it! I hope I've made a good case for the survival of these "endangered species" of precious keywords. Thanks, Curry Kenworthy _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
