Jacque, I'm treading very carefully here because I'm a mere peasant in the shadow of a Master, but is it really the case that you can move the mouse fast, but stop it in an object and not have the mouseEnter message sent? Whilst I accept that it 'may'* be possible to move the mouse completely across an object so fast that the mouseEnter message isn't sent, in the case of toolTips, or contextual Help, this isn't a concern, in fact it's a good thing that you don't get a dozen scripts activated and Help messages popping up when really all you want is the Help for the object under the final resting place of the mouse.
*As a quick test I created a new stack with a large field in the middle and entered the following scripts: on mouseEnter put "MouseEnter" into Msg end mouseEnter on mouseMove put cr & "MouseMove" after Msg end mouseMove on mouseLeave put cr & "MouseLeave" after msg end mouseLeave Whilst running the mouse as quickly as possible across the field I could easily end up with no text in the Msg box, indicating no messages were sent at all, not even mouseMove. Slowing down a bit I always got all 3 messages. Every time I came to a halt in the field I always had the MouseEnter text. I've extensively used mouseEnter for pop-up text activation and have never noticed it didn't work. Isn't this what the Engine uses for ToolTips? Obviously this isn't extensive testing, but if people are experiencing mouseEnter messages not being sent, isn't this an Engine problem that should be sent the QCC? I appreciate the problem with overlapping objects, but this is covered in the Dictionary. I await thy wisdom :-) On Fri, Feb 12, 2010 at 7:22 AM, J. Landman Gay <[email protected]> wrote: > Kay C Lan wrote: > >> Lastly, I'd probably use mouseEnter rather than mouseMove. Over a >> large field, mouseMove could be sent multiple times, causing your >> script to be triggered unnecessarily. MouseEnter will only be sent >> once. > > I thought about that, and in fact the field doesn't even have to be very > large for it to trigger multiple times, but that's an advantage. Sometimes > mouseEnter doesn't trigger. MouseMove almost always does. If the user is > moving very fast or there is an overlapping control, you don't always get a > mouseEnter, and you only have one shot at it. Then you also have to catch > mouseLeave too, in order to empty the help field text. So I think I'd still > use mousemove here. > > I used mousemove in my Klondike game, where each iteration executed a very > long handler, and there was no noticeable slowdown. That was about 10 years > ago now, when machines were slower. So now I don't worry about it any more. > > -- > Jacqueline Landman Gay | [email protected] > HyperActive Software | http://www.hyperactivesw.com > _______________________________________________ > use-revolution mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution > _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
