For the mouse() function, with direct polling, you'd never be stuck but you might miss something. With event-driven (as it is now), you may get the wrong answer, or even get stuck sometimes because of the limitations.
I was informed off-list that in some newer OS's, direct calls for the mouse state are not even supported or recommended by the OS. So, how about a way to accomodate both desired behaviors: The engine keeps track of all the mouseup and mousedown events that happen since the handler starts, not just to the very limited extent as with the current behavior. Then have a global preference of simulating direct polling behavior or getting events in order with each call. If direct polling was simulated, the time of the call could be compared to the time of the events, and the most recent state according to the events would be returned. But without the current limitations, it would never return the incorrect state or get stuck like it does now. For the buffered event behavior, you could get the next event after the last one your script had seen, no matter how many events had happened since. The other advantage would be that it would work well with the newer OS's and not make direct calls. I'm not a techie and don't know how easy or difficult it would be to implement, but if it would work, it would seem to solve a lot of the problems. Possible? (I would like to add that I agree to a certain extent with the other side of the argument, that people should avoid overusing the mouse function and using it in the wrong situations. I think it's especially good for students and convenience in roughing something out quickly for testing, but also in some special situations in serious scripts. Still, it would be good to have a reliable behavior that met a wider range of needs and returned a more reliable value, for when the function is used, whether out of necessity or preference or whatever. It would be nice for it to never lock up.) Curry Kenworthy _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
