Mouse & Group Interaction

[dglass]

Mouse interaction when working with Groups seems weird to me.

It appears that even though a set of controls is grouped, the mouse events (enter, leave, scrollwheel (rawkeykeydown)) only fire when the mouse location intersects one of the controls in the group, rather than with the group's 'area'.

This seems especially odd when the group's size is locked and scrollbars are used, since visually there's a an area of 'control' that is unresponsive.

So, given a set of controls that has been grouped, will need to be scrolled, and has a moderate amount of empty space between and around the controls, what can I do to make the group 'area' respond to the mouse (especially the scroll functionality)?

I found this old thread, but couldn't glean the solution from it.

[BarrySumpter]

Check the grouping.
There may be more than one.
Two groups - grouped together - to make a third.
One group embeded within another.
One group layered on top of another.

I had an error in the script in one of the controls within the group
drove me mad until I found it.


Try placing the group into a container.
And writing code for the container.
I havn't tried this yet.

Don't forget the
Pass MouseMove - I still need to research to be sure what this is for

hth

[SparkOut]

I was going to reply before reading the old thread you linked, saying you need to put (say) an image into the group to act as a catcher for mouse events. Having read the old thread, my answer is the same but I'll try and explain a little more.

To react to a mouse event, there needs to be something to receive the mouse event at its current location. Controls that do not have any "physical presence" - ie, the space between your other buttons and controls in the group - (or, I believe, disabled controls) do not receive events. This is desirable on the whole, since the "rect" of a control may wildly vary from what you apparently believe its area to be from the visual display. You might otherwise get many objects being unclickable as the "transparent" area of a control on a higher layer would cover them.
In order to force a group area to react to mouse events over its whole area there needs to be something "physically" in its whole area, whether or not you can see it. Try making a plain white image (or for ease, an opaque rectangle graphic) and inserting that into the group and resize it to be the same as the group's rect. Then make sure that you give it the lowest layer of any group member, and that layer will receive any mouse events if the pointer is between any of the "properly" visible controls in the group area, and trigger the mouse event handlers held in the group script.
Now, to get the image/graphic out of sight so that it still "looks" transparent but will receive the events to be handled by the group script is the trick. If you set the blendLevel of the graphic to 100 then it will become "transparent" to the eye. The control will still be there though. * Now... apparently this is different from my recollection because I just tried (on Windows) and even though it "looks" *completely* transparent at blendLevel 100, it is still "there" and "visible" to mouse events.
*My previous experience (unless I'm wildly hallucinating, which is possible) is that you needed to set the blendLevel to 99 in order to have the control go "almost entirely transparent" so the eye could not see it, with the 1% left being enough for the mouse to believe it is "still there". I'm almost certain that it used to be the case that if you set the blendLevel to 100 then it becomes fully transparent and "is not there" - neither to eye nor mouse events.

[Dixie]

Sparkout...

You don't need to alter the blendLevel, just set the ink of a graphic to 'noop'... you don't see it, but it will then catch messages
be well

Dixie

[SparkOut]

Mmmm yeah. So I see. Admittedly it was about 4000 years ago I last played with a group control message catcher quite like this but...

[bn]

Hi dglass

here is a little example stack with a group that uses a graphic as "background" control.

check the groups script for the scrolling of the group. Also the target of a mouseDown is indicated. This does not work for the editable field since they don't get the message.

This work for scrolling with the magic mouse on a Mac, should work for other scrolling devices also. If the rawKey is different it might not work, just click into the editable field and move the scrollwhell of your mouse. The field at the right will indicate the rawKey number.

Kind regards

Bernd

[BarrySumpter]

Getting late here ...
After a very long day of study and researching.

I was just reading something about mouseMove
and retrieving what control was under the mouse pointer
using the mouseChunk or mouseStack(? or something similar).

Use the mouseStack function to determine which window the mouse is over, or, in conjunction with the mouseControl, mouseLine, or mouseChunk, to determine which field the mouse is over.

[Dixie]

Getting late here ...
After a very long day of study and researching.

I was just reading something about mouseMove
and retrieving what control was under the mouse pointer
using the mouseChunk or mouseStack(? or something similar).

Use the mouseStack function to determine which window the mouse is over, or, in conjunction with the mouseControl, mouseLine, or mouseChunk, to determine which field the mouse is over.

And your point is ?

[dglass]

Thanks everybody!

Mostly working now, just have to figure out the remaining issues.

[dglass]

OK, so 'remaining issues'....

The number of graphic elements and their positions in my group will be arbitrary so I need to be able to resize the 'controller' rectangle to encompass them all.

I have the resizing part handled, I think, but for some reason my graphic elements get moved around in ways that I'm not (as far as I can tell) moving them.

The attached stack starts with a single colored balloon and the controller rectangle in the group. Pressing the button creates 3 more balloons and positions them. Then it is supposed to resize the controller rectangle so it surrounds the balloons, and while it does resize, and the size is right to surround the balloons, all the balloons are shifted down and to the right of where they should be, so some are outside of the rectangle.

I'm not understanding why the Top property of the balloons is being adjusted. It's almost like the controller rectangle is growing along its top and left edges (so up and left) rather than at the bottom.

[bn]

Hi David,

I see Chris has made a stack for you.

I changed your stack a bit. What bit you is that Livecode changes size from the center. I.e. If you change the width of an object you also change the left and the right of an object.
Likewise if you change the height of an object you change the top and bottom at the same time. Lets say you increase the height by 20 then the top will be 10 less than before and the bottom 10 more than before.

You can prevent this if you get the top before changing the height for example and set the top to its old value after the change. Now your bottom will be + 20.

Kind regards

Bernd

[dglass]

What bit you is that Livecode changes size from the center. I.e. If you change the width of an object you also change the left and the right of an object.
Likewise if you change the height of an object you change the top and bottom at the same time. Lets say you increase the height by 20 then the top will be 10 less than before and the bottom 10 more than before.

You can prevent this if you get the top before changing the height for example and set the top to its old value after the change. Now your bottom will be + 20.

Ahah.

Thanks!

[bn]

David,

you might also want to download the revised version of your stack that I attached to my previous post.

Kind regards

Bernd