Tereza Snyder wrote: >>> Scott Raney has told us in the past that "repeat until the mouseClick" is >>> not a good idea because it bolixes up the event handling in the engine. I've >>> found that mouseMove works wonderfully in situations where you'd be tempted >>> to use "repeat until the mouse is up" or similar loops. >> >> While mousemove seems straight forward, how would one go about turning it on >> and off as might be needed in the "XY function"? >> > > something like: (NOT A REAL SCRIPT) > > LOCAL tXY = false > > on XY > put true into tXY > end XY > > on mouseMove mX,mY > if tXY then > if the mouse is down then > put false into tXY > else > -- do XY stuff > end if > end mouseMove > > another way: on XY, insert a script containing the code temporarily into the > front, and remove it on mouseup
The latter is probably a good idea, even if it does seem unnecessarily complicated at first glance. But this lil' ditty opens up a debate about polling events vs. notification events. Scott is quick to remind us, and rightfully so 99.9999% of the time, that messages that rely on polling (MC's event loop making repeating queries of the OS) as opposed to notification (when the OS sends MC a message) are a performance drain on the machine, esp. noticeable in environments with true multitasking like OS X (as opposed to OS 9 and earlier). While this is merely factual and cannot be argued, it can be argued that there are times when it's perfectly acceptable, if not beneficial, to rely o polling. The XY handler is a good example: As normally written in HyperCard (as the first example showed), the xy handler is invoked, runs while it's needed, and stops soon after when the mouse is clicked. Yes, it was eating far more clock cycles than needed while it was running, but using it is inherently modal by nature anyway -- the only thing the user's doing is moving the mouse; as soon as they click it's over. In contrast, the addition of a mouseMove handler to provide the same effect requires that the interpreter evaluate a variable flag everytime the mouse is moved -- potentially several dozen times every second -- whether XY is in use or not. In an average work week you may be running XY only a few times, but that flag will be evaluated every time the mouse moves, all day, every day. I would imagine the aggregate waste of clock cycles, however difficult to notice, would be far greater by the end of the week using "mouseMove" over "repeat until the mouseClick", no? -- Richard Gaskin Fourth World Media Corporation Custom Software and Web Development for All Major Platforms Developer of WebMerge 1.9: Publish your database on the Web ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc _______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
