That would make a good LiveCode article. Bob
On Jun 24, 2011, at 10:39 AM, Richard Gaskin wrote: > Nicolas Cueto wrote: > >> mouseStillDown, for example. When part of a script set as a behavior, >> mouseStillDown would not work. But that same script with the same >> mouseStillDown handler, when actually stored as a button's script, >> worked as expected. > > In a way that's kinda good news, as mouseStillDown is an anomaly among mouse > messages. I think you'll find the other mouse messages quite reliable in > behavior scripts, but mouseStillDown is an oddity as noted in the Dictionary: > > Usually, it is easier and more efficient to use the mouseMove > message to track the movement of the mouse while the button > is being held down. > > Note: If there is no mouseStillDown handler in the target > object's script, no mouseStillDown message is sent, even if > there is a mouseStillDown handler in an object that's > further along the message path. > > Your behavior script should work if you add this to the target object: > > on mouseStillDown > pass mouseStillDown > end mouseStillDown > > Why is mouseStillDown so different from other mouse messages? > > Because it's uniquely inefficient, and the mouseMove message was provided to > provide an alternative that's far more flexible and takes fewer system > resources for many similar needs. > > Most OSes provide a message when the mouse first goes down, but not all of > them provide a second message sent continuously while the mouse is being held > down. So to provide mouseStillDown for us the engine needs to continually > poll the OS for the state of the mouse button. It does this with a > frequency defined in the idleRate, which is far less frequent than checking > "if the mouse is down" in a repeat loop, but still not optimal. > > If the message was always sent into the message path whether or not it's > needed, anytime the user holds the mouse down it would trigger a lot of > messaging overhead that's never used. > > But what if you need it? > > Like the idle message (HyperCard's message-clogging workaround for not having > timers), all you need to do is include a mouseStillDown handler in any target > you want it to be sent to, and the engine will then know to trigger that > seldom-used message. > > "Seldom-used?" Yes: > > Historically, mouseStillDown was most often used for dragging or other > operations in which things need to be updated while the mouse is moving. In > such cases, the developer probably doesn't need to update anything until the > location of the mouse changes, but mouseStillDown is continually being sent > anyway, requiring a lot of redundant processing for things which have no > visible effect. > > So the mouseMove message was added, providing a way to update things only > when the mouse is moved. > > MouseMove also works when the mouse is up, which can be useful for update > mouse position indicators in a drawing program's rulers, for example. > > This additional flexibility requires us to use a few other handlers to > substitute for mouseStillDown, but it well worth the few seconds it takes to > set up. You'll need a mouseDown to set a flag so the mouseMove can know that > the mouse is down without having to poll the OS (you can also use this flag > for other useful info, as shown below), and you'll need mouseUp and > mouseRelease messages to clear the flag. > > This example is for a splitter control that adjusts the groups on either side > of it: > > local sXOffset > > on mouseDown > -- Provide the info mouseMove will need later: > put the mouseH - the left of me into sXOffset > end mouseDown > > on mouseMove > -- Is the flag still set? > if sXOffset is not empty then > -- If so, handle the splitter drag here: > set the rect of grp "LeftGroup" to \ > 0,0,the left of me, the height of this cd > set the rect of grp "RightGroup" to \ > the right of me, 0, the width of this cd, > the height of this cd > end if > end mouseMove > > -- Clear the flag when the mouse is released over the control: > on mouseUp > put empty into sXOffset > end mouseUp > > -- Clear the flag when the mouse is release when not over the control: > on mouseRelease > put empty into sXOffset > end mouseRelease > > > In addition to handling simple drags like a splitter, drag-and-drop > operations can be handled using the messages provided for those (dragStart, > dragMove, dragDrop, dragEnd) far more simply than emulating drag-and-drop > behaviors with mouseStillDown. > > So once we use mouseMove for movement-related things and the drag-and-drop > messages for those types of actions, the remaining subset of cases where > mouseStillDown can be useful are relatively few. And for those, you can > still use it so long as you provide a handler for it in the target object. > > >> One other thing I noticed during development and had thought due to my >> uncertain knowledge about the various mouse-related handlers, was that >> I couldn't rely on "me" but had to be more specific. Something like >> "put the short name of the owner of me into tGroup; if the flag of >> button "theButton" of group tGroup is...", rather than simply "if the >> flag of me is...". > > More good news: the uncertainty you subjectively felt is well addressed by > the implementation. If you experiment a bit you'll find that "me" in a > behavior script will always refer to the target object. > > Once you've experimented to verify this, you'll become confident with their > use and will want to use them every day. And every night. And on the > weekends. Highly addictive. :) Behaviors are one of the most powerful > additions to the language since arrays. > > >> Anyway. I doubt I will ever rely on behaviors again. And I don't feel >> confident enough with my programming skills to present this to LC as >> something like a bug. Cause I have been known to be wrong -- though >> not about mouseStillDown working now when it wasn't before. > > Having addressed the unique anomaly that is the mouseStillDown message, I > hope you're inspired to give behaviors a fresh try. > > While your own confidence may not be as strong as the moment, I'm completely > confident with with just an hour or two's experimentation to verify how > behaviors work, you'll enjoy using them going forward and have simpler and > more robust code in the process. > > > Hope all is well with you and yours in Tokyo - > > -- > Richard Gaskin > Fourth World > LiveCode training and consulting: http://www.fourthworld.com > Webzine for LiveCode developers: http://www.LiveCodeJournal.com > LiveCode Journal blog: http://LiveCodejournal.com/blog.irv > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
