i thought we are talking about ignoring the controls owned by the group. They
have real zest appeal.
Craig
--
Sent from:
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html
___
use-livecode mailing list
As I understand it, a group will be the FIRST object to get a mouse message, IF
you click on an actual object in the group. So you can have a mouseUp handler
in the group script that handles clicks in other objects, simpy by using the
target to determine what was clicked.
Bob S
> On Jun 25,
Devin.
"That is what the "target" is for."
"Right, but when you click on an empty space in a group, it is the target,
and if you only want to script the child objects you would have to
specifically exclude the parent group."
The target in this case is the card. Assuming, of course, that no
"I would suggest an enhancement to LiveCode to add a property to Groups
that toggle between: "
Setting the "opaque" of the group ought to be the property that permits
mouse messages.
"If the group did get mouse click messages, it would complicate things in
situations where you want to know
This is a great idea, Paul. I was just thinking that might be a good solution,
especially with the addition of the (relatively) new clipsToRect property of
fields. When that property is true, a group’s boundaries do not automatically
snap to the area defined by its child objects. Instead the
Another easy workaround if you want a group with a transparent background
is to put a group-sized graphic behind other objects as mentioned, but set
the blendlevel of the graphic to 99. Visually it won't be seen but it will
still trap messages.
--
Jacqueline Landman Gay |
There are clearly use cases where it makes sense for a group (such as it
it just being used to contain or enclose a set of other controls) NOT to
received mouse event messages.
There are also use cases where it DOES make sense of a group to received
mouse event messages, such as if you are
Asay
Subject: Re: Groups do not receive mouseEnter messages?
I have always thought of a group as a container object, like a card, but
without a “canvas” that constitutes a part of the object. It’s always made
sense to me that a group doesn’t get mouse messages, except as they are passed
from child
I have always thought of a group as a container object, like a card, but
without a “canvas” that constitutes a part of the object. It’s always made
sense to me that a group doesn’t get mouse messages, except as they are passed
from child objects. If the group did get mouse click messages, it
bob belabored,
>
> You are probably right. But the workaround is so simple, putting an opaque
> green graphic in the group behind all the other objects, that it would be a
> lot of work to implement just so we didn't have to put a graphic in a group.
I actually use that background rectangle
You are probably right. But the workaround is so simple, putting an opaque
green graphic in the group behind all the other objects, that it would be a lot
of work to implement just so we didn't have to put a graphic in a group.
Bob S
> On Jun 25, 2019, at 08:24 , dunbarxx via use-livecode
>
I suppose as long as one knows how it works, it can be dealt with.
But there is an issue here, in that a group is not really a control, despite
what the dictionary says. A group has a rect, and one can tell if the
mouseLoc, say, is within that rect (and not necessarily within the rect of a
child
What would happen if you had a background image set for the group?
Bob S
> On Jun 24, 2019, at 17:24 , dunbarx--- via use-livecode
> wrote:
>
> Confirmed here.
> I have never really tried any of the things you mentioned, but no messages at
> all are sent to the group I just made.
On 6/25/2019 4:11 AM, Mark Waddingham via use-livecode wrote:
The behavior of groups re mouse messages (and the lack there of) has
been the same as long as I can remember (which is back to around
version 2.0).
Warmest Regards,
Mark.
As always Mark, thank you.
I have becomes so use to
On 2019-06-25 03:07, Paul Dupuis via use-livecode wrote:
On 6/24/2019 8:24 PM, dunbarx--- via use-livecode wrote:
Confirmed here.
I have never really tried any of the things you mentioned, but no
messages at all are sent to the group I just made. Interestingly, and
consistent so far, double
Paul:
> 2 opaque groups with show borders [...]
> Neither group seems to receive the mouseEnter messages.
I believe this is consistent with LC 6. Makes good sense for transparent
groups. A good case could be made either way for opaque ones.
(Card mousemove is another way to handle the tool
On 6/24/2019 8:24 PM, dunbarx--- via use-livecode wrote:
Confirmed here.
I have never really tried any of the things you mentioned, but no messages at
all are sent to the group I just made. Interestingly, and consistent so far,
double clicking within the group boundary, but not in any child
t
doesn't seem to be quite there.
Craig
-Original Message-
From: Paul Dupuis via use-livecode
To: How LiveCode
Cc: Paul Dupuis
Sent: Mon, Jun 24, 2019 7:28 pm
Subject: Groups do not receive mouseEnter messages?
In LC9.0.5rc1 under Windows, I have a test stack with 2 opaque groups
Hi Paul - so, you could create a grc object the same size as the group, send it
to the back and set its cantSelect property to true. That should give you the
behaviour you want as well as preventing your user from selecting the
'background' object in the group that switches to the pointer tool.
In LC9.0.5rc1 under Windows, I have a test stack with 2 opaque groups
with show borders - one covering the top half of the card and one
covering the bottom half of the card. In side the top group are a couple
buttons with plenty of white space around them and inside the bottom
group are a
20 matches
Mail list logo
