mouseMove & backgoundBehavior

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

mouseMove & backgoundBehavior

Mike Kerner via use-livecode
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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: mouseMove & backgoundBehavior

dunbarx
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
Reply | Threaded
Open this post in threaded view
|

Re: mouseMove & backgoundBehavior

Mike Kerner via use-livecode
In reply to this post by Mike Kerner via use-livecode
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 &cr 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 \
      &cr 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
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: mouseMove & backgoundBehavior

dunbarx
This post was updated on .
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 panoply of controls in your example is at the very least conceptually in conflict with the constraint in the above handler. The group does not "take over" the whole card in the sense that you imply, unless (not impossible at all) I misunderstand you.

Craig
Reply | Threaded
Open this post in threaded view
|

Re: mouseMove & backgoundBehavior

Mike Kerner via use-livecode
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
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: mouseMove & backgoundBehavior

Mike Kerner via use-livecode
In reply to this post by Mike Kerner via use-livecode
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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode