Re: mouseMove & backgoundBehavior
RichardG wrote: > when you set the backgroundBehavior of a group to true... that group's script > then occupies a different > place in the message path, between the card and the stack Ah, yes, the light dawns - the message path. Because LC ‘backgrounds” can be smaller than the card, checking the target or using ‘within’ would be needed to constrain actions taken to the rect of a background group. And since multiple backgrounds are possible, only the script of the topmost background seems to be inserted in between the card and stack in the message path. One must click directly on objects within other, lower background groups to trigger its handlers. Thanks, JimL ___ 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
Re: mouseMove & backgoundBehavior
dunbarx wrote: > I understand the reordering of the layers in the hierarchy. That is > not the issue. If you modify the handler: > > on mousemove newMouseH, newMouseV >if the mouseLoc is within the rect of me then put newMouseH, newMouseV > end mousemove > > Even with backGroundBehavior set to "true", the message now only > fires when the cursor is within the rect. Like it should. It is a > matter of, er, control, not message passing. The constraint to be > within the rect implies that the control is just what it seems to > be, that is, only as large as it seems to be. This regardless of > any change in the hierarchy. > > The group does not "take over" the whole card in the sense that you > imply, unless (not impossible at all) I misunderstand you. It's true that we can introduce a condition that constrains the outcome, but that's about the condition, not the change to the message path that gets introduce when you turn a group into a background. Remember, in LC a group and a background may be the same physical objects, but they serve different roles. HC never had a mouseMove message, so that may be less intuitive. Let's consider another mouse message, mouseUp, instead: If you put a mouseUp at the card or stack level, what happens? Is it what you would expect? Would you expect a background script situated in the message path between the two to act differently? Change mouseUp to mouseMove (and most other messages), and unless I'm even shorter on sleep this morning than I think I am, I believe that appears to be what we're seeing here, no? I think the challenge here is the flexibility of LC's groups. It's possible to have a background that is smaller than the card. And we can even have multiple backgrounds. These are things we didn't have in HC, so when we need to support HC paradigms it can get confusing. If it helps, limit your layout to one background, make it the full size of the card, keep it at layer 1, and voila! you have HyperCard. :) -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: mouseMove & backgoundBehavior
Richard. I understand the reordering of the layers in the hierarchy. That is not the issue. If you modify the handler: on mousemove newMouseH, newMouseV if the mouseLoc is within the rect of me then put newMouseH, newMouseV end mousemove Even with backGroundBehavior set to "true", the message now only fires when the cursor is within the rect. Like it should. It is a matter of, er, control, not message passing. The constraint to be within the rect implies that the control is just what it seems to be, that is, only as large as it seems to be. This regardless of any change in the hierarchy. The group does not "take over" the whole card in the sense that you imply, unless (not impossible at all) I misunderstand you. Craig -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/mouseMove-backgoundBehavior-tp4714294p4714314.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ 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
Re: mouseMove & backgoundBehavior
Jim Lambert wrote: > Make a group that is smaller than your card. > Place this in the group’s script: >on mousemove newMouseH, newMouseV >put newMouseH, newMouseV >end mousemove > > When the cursor moves around within the group the current mouseLoc is > put into the message box. When the cursor moves outside of the group > the mouseloc is no longer placed into the message box. > > Next set the backgroundBehaviour of the group to TRUE. > > Now wherever the cursor is within the CARD the mouseLoc is placed in > the message box regardless of whether the cursor is within or without > the rect of the group. > > The dictionary states, "The mouseMove message is sent to the control > the mouse pointer is over, or to the card if no control is under the > mouse pointer.” > > It is true that a background group is not 'officially' on a card > (rather it’s on the background in HyperCard parlance.) But why would > the mousemove message get passed to the card when the mouse is > outside of the background group containing that handler? > > Is this a bug or expected behavior? You've been working with LiveCode too long, and have forgotten the semantic roots of the ancient mother tongue. :) In HC there was only one background on any given card, it was always present, and it filled the card. All messages passed from the card to the background before moving on to the stack. In LiveCode, groups by default act as controls, and their message handling works as you expect, in visual layer order, responding only to messages that occur in objects contained within the group. But when you set the backgroundBehavior of a group to true, you're telling LC to act like HC: that group's script then occupies a different place in the message path, between the card and the stack, so that it can deliver what a ported HyperCard stack would expect. This becomes clearer if you modify your recipe script: on mousemove newMouseH, newMouseV put the name of the target, newMouseH, newMouseV after message end mousemove With that you can observe behavioral differences between moving the mouse when the group's backgroundBehavior is true and when that's set to false. When the backgroundBehavior is false, of course the only target is the control within the group, and that's the only target identified in the list growing in the Message Box. But when true, you'll see a mix of objects, sometimes the control in the group and sometimes the card, depending on whether the mouse is within the control. This becomes even more evident if you modify the recipe script to include "me", and pass the message, and then copy that to both the card and stack scripts: on mousemove newMouseH, newMouseV put the name of me && the name of the target, newMouseH, newMouseV \ after message pass mouseMove end mousemove TL;DR: Don't go out of your way to use a property designed for HyperCard compatibility and you'll remain in the more flexible and sometimes more predictable LiveCode paradigms. :) -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: mouseMove & backgoundBehavior
Fascinating. I consider this unwanted, unwarranted and just awful behavior. A group is ostensibly "just a control", and that is how it is touted to those old HC'ers like me to make the loss of the HC backGround object layer more palatable. The difference in that aspect of LC, as well as the way menus are created, are the two most significant departures from simply wandering into LC from a HC, er, backGround. But if a group is just a control, then it has just a rect. Rects have insides and outsides. Anyway, I call it a bug, and should be either fixed or LOUDLY warned about. Craig Newman -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/mouseMove-backgoundBehavior-tp4714294p4714298.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ 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
mouseMove & backgoundBehavior
Make a group that is smaller than your card. Place this in the group’s script: on mousemove newMouseH, newMouseV put newMouseH, newMouseV end mousemove When the cursor moves around within the group the current mouseLoc is put into the message box. When the cursor moves outside of the group the mouseloc is no longer placed into the message box. Next set the backgroundBehaviour of the group to TRUE. Now wherever the cursor is within the CARD the mouseLoc is placed in the message box regardless of whether the cursor is within or without the rect of the group. The dictionary states, "The mouseMove message is sent to the control the mouse pointer is over, or to the card if no control is under the mouse pointer.” It is true that a background group is not 'officially' on a card (rather it’s on the background in HyperCard parlance.) But why would the mousemove message get passed to the card when the mouse is outside of the background group containing that handler? Is this a bug or expected behavior? Thanks, Jim Lambert ___ 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
