LiveCode Forums.

The reason Craig did not see what I saw was that I was mistaken.

One of the ways round this is to have a white graphic that is exactly the size of the group on the bottom layer.

Ah. OK.

Then I am going back to my comment that an overlying transparent graphic would indeed work, but causes other kludge-like issues.

Anyway, this is all kludgeable, and there is nothing wrong with kludges.

Craig

On another note, I think there was a discussion about how nice it would be to have a property of a group (like "opaque", eh, Richmond?) that would allow mouse events to be trapped in the voids.

It is just the opposite of a long-time request of mine, a property that allows mouse events to pass through, say, a button, so that an underlying control or card could receive them.

This is much harder to kludge for another control underlying the one of interest. The card will get the message by virtue of the hierarchy. But another control will not unless the overlying control explicitly sends the message to it. I have always thought this would be of use

Craig

I've done it both ways, more commonly with a nearly transparent graphic at the back of the group. That's mostly because I don't want to clutter up the card script, and it keeps the group self-contained. But either way works.

Any transparency less than 100 will catch mouse messages, and a 99% blendlevel is visually transparent.

Thanks all. Fascinating.

Opaquer - Thanks for the card script idea. I can see how that would also work.

Dunbarx
- Thanks for the info about the "solidity" of a group. That certainly matches what I'm seeing.
- Yes - I think that a group property that allowed void mouse clicks to be trapped would be useful (but clearly not very often, or people would have asked for it already).

I asked my original question out of curiosity. Clearly there are at least two possible easy work arounds; but it intuitively seemed to me that the ability for a group to detect mouse-actions within its rectangle, but outside the space of its component objects, MIGHT be a feature that LC already had. It sounds like either it doesn't, or I need to pass to a higher level of membership in the Ancient and Esteemed Order of Livecode Illuminati before I can be told about the On VoidMouse message set

I (unsurprisingly) do what Jacque does, but most of the time I rely on the fact that I can pass mouseclicks through the unpopulated area of a group to the card or stack script beneath it. I do think a group property to control this (defaulting to the current situation) would be useful, but given that there are already workarounds in place that people are using, and that the team is already spread pretty thin working on <other things>, I doubt anything useful would come of suggesting it.

dunbarx wrote: Wed Sep 02, 2020 4:47 pm It is just the opposite of a long-time request of mine, a property that allows mouse events to pass through, say, a button, so that an underlying control or card could receive them.

Have you tried setting the enabled of the button to false? That works on other controls but I don't think I've ever tried it on a button.

jacque wrote: Thu Sep 03, 2020 5:45 pmHave you tried setting the enabled of the button to false? That works on other controls but I don't think I've ever tried it on a button.

Just tested and that does in fact work!

Jacque. Klaus.

jacque wrote: ↑Thu Sep 03, 2020 12:45 pm
Have you tried setting the enabled of the button to false? That works on other controls but I don't think I've ever tried it on a button.
Just tested and that does in fact work!

We have all talked about this before. Disabling a control fools LC into thinking it is not there at all. Richard was miffed at this, I think. But it surely works, because it is, er, not there at all.

But except for groups and images, the control changes its look, and this may not be acceptable.

Not sure how important it all is, as we have seen there are workarounds. Some may be tedious, however, with lots of controls stacked up.

Craig

If you set any appearance properties on the control (background color, text color, etc.) it doesn't change, if I remember correctly. Set the colors to the same values as the active colors.

Jacque.

For "standard" buttons, the foreColor has no effect.

I am the one who said there is nothing wrong with kludges. But they are sometimes a lot of work.

Craig

dunbarx wrote: Thu Sep 03, 2020 7:34 pm For "standard" buttons, the foreColor has no effect.

Right, those come from the OS. So even if we did have the property you want, it might not apply to controls created by the operating system.