RE: [flexcoders] Re: Mouse Event Filtering
Hi Matt, Yeah, I mention below that I tried this and got a partial solution to my problem. The issue is that once I do that, ALL the events are blocked and I don't know the correct way to ensure that the toolbar buttons themselves get passed mouse clicks But if the solution lies in pursuing this direction, then thanks for the tip. -Tony tony pujals| senior engineer | Yahoo! SiteBuilder Express p. 408.349.6284 | e. tonyp * yahoo-inc . com | y!id tonypujals From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Matt Chotin Sent: Wednesday, February 15, 2006 10:57 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Mouse Event Filtering Can you try assigning onPress to the component, I think that's how we've gotten our blockers to work in the past. Matt -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Tony Pujals Sent: Wednesday, February 15, 2006 3:33 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Mouse Event Filtering Yes, that's exactly the similarity -- but an obscured component should not even have to be aware of a toolbar component above it. It should not receive a mouseDown event if the component above is handling it. It's only my toolbar canvas that seems to allow events to pass through to the TextArea below it -- the toolbar buttons don't. As far as code, I'll create a streamlined example that should make it a little easier to see what I'm talking about Thanks again, Doug. tony pujals| senior engineer | Yahoo! SiteBuilder Express p. 408.349.6284 | e. tonyp * yahoo-inc . com | y!id tonypujals From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Doug Lowder Sent: Wednesday, February 15, 2006 3:13 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Mouse Event Filtering Yeah, it's possible this is something entirely different from my situation, but I think there is still the similarity that an obscured ocmponent is acting as if it's not obscured. Can you post some code? --- In flexcoders@yahoogroups.com, Tony Pujals [EMAIL PROTECTED] wrote: Hey Doug - thanks for the input. This is a link to a screenshot that may help clear up the issue: http://www.geocities.com/tonypujals/eventcapture.jpg What the screenshot shows is that I dragged the toolbar over the TextArea component. Then, I dragged the toolbar just a little bit again ... which resulted in the highlighted text that you see displayed. In other words, the toolbar isn't handling events from other components when it shouldn't - the opposite is happening: other components are receiving events I don't want them to. When I mouse down and drag the toolbar, I want it to move without events propagating to components below it. I want the toolbar events to be consumed when they act upon the toolbar. Also, what the picture doesn't show since Windows doesn't capture it in screenshots is that the mouse cursor over the toolbar is an i- beam cursor - which is what it should be when over text, but not over the toolbar. It is only an i-beam when it is not specifically over one of the toolbar buttons, just the toolbar gradient background Canvas. Rather than using mouse handlers for the toolbar, I tried overriding the onMouseXXX methods of MovieClip in the hope perhaps that this would prevent some superclass behavior which forwards the mouse events to further processing, but it didn't help Argh... tony pujals| senior engineer | Yahoo! SiteBuilder Express p. 408.349.6284 | e. tonyp * yahoo-inc . com | y!id tonypujals From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Doug Lowder Sent: Wednesday, February 15, 2006 12:41 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Mouse Event Filtering I should have pointed out I was talking specifically about the custom floating toolbar you mentioned in point 2 of your original post. It seems to me your toolbar is handling events from other components when it shouldn't. Try putting the event.target test into your toolbar code; no need to put it into any other components. Doug --- In flexcoders@yahoogroups.com, Tony Pujals tonyp@ wrote: Thanks for the tip, Doug ... the only problem is that I want the toolbar to be a generic component that doesn't require any specially awareness from other components in the form. I don't want to mandate that other programmers have to modify their event-handling code just to accommodate my toolbar weirdness I'm a little surprised this has turned out to be so challenging. Since I know various components provided by Macromedia (such as Button) do behave correctly, I guess that there is a 'standardized' way to implement this tony pujals| senior engineer | Yahoo! SiteBuilder
[flexcoders] Re: Mouse Event Filtering
Tony, I had a similar problem in Flex 1.5 with a custom TitleWindow
component that was receiving events from objects underneath it.
Never did find out exactly why that was happening; non-100% alpha
value, perhaps? Anyway, I solved it by wrapping a simple check
around the event handler that makes sure the target property of the
event is the current object:
if (event.target == this) { // handle the event... }
It might be worth trying that somewhere, like in a delegate for the
mouseMove event or in handleEvent().
Hope that's of some help.
Doug
--- In flexcoders@yahoogroups.com, Tony Pujals [EMAIL PROTECTED] wrote:
Well, the Flash asdocs really don't make this clear, but I
initially had a suspicion that overriding a handler instead of
registering a listener might be the answer. I didn't pursue that
direction right away because the method signatures don't return a
Boolean or some other value to indicate that an event was handled
and no further processing is wanted.
In any case, I was able to achieve the glass pane effect that I
wanted this morning with the following code:
options = { width: 100%, height: 100%};
Canvas(createChild(Canvas, _glassPane, options));
_glassPane.setStyle(backgroundColor, #FF00FF);
_glassPane.alpha = 0;
_glassPane.visible = false;
MovieClip(_glassPane).onPress = function() {}
All of the above was required: without a backgroundColor being
set, events weren't captured at all; The alpha, of course, was to
make the glass pane actually invisible (there maybe other properties
beside backgroundColor that also work for causing events to get
caught, but I haven't experimented). The visible property -- once a
backgroundColor property is set -- is what enables and disables the
event capturing.
However, for the toolbar that I also wanted to capture events so
the text component below doesn't receive them, this is not yet a
complete solution because it also prevents the child components (the
toolbar buttons) from getting any events either. I've written some
code to iterate the child components, but I don't know what to pass
to them -- it seems intrinsically wrong that the toolbar needs to
become an event manager from its onPress handler:
// doesn't work -- onPress doesn't have event parameter anyway...
MovieClip(this).onPress = mx.utils.Delegate.create(this, function
(event) {
var comp : UIObject = null;
for (var i : Number = 0; i childDescriptors.length; i++) {
comp = getChildAt(i);
if (hitTest(comp)) {
comp.handleEvent(event);
}
}
});
(Incidentally, if there is some other more appropriate way for
iterating child components, I'd appreciate hearing about it).
So Flash/Flex gurus ... what am I missing here...? Thanks!
Tony
tony pujals| senior engineer | Yahoo! SiteBuilder Express
p. 408.349.6284 | e. tonyp * yahoo-inc . com | y!id tonypujals
From: Tony Pujals
Sent: Wednesday, February 15, 2006 7:43 AM
To: 'flexcoders@yahoogroups.com'
Subject: RE: [flexcoders] Mouse Event Filtering
Sorry, I don't know if this works in the Flex 2 beta, but I should
have specified that we're working with Flex 1.5 at Yahoo.
Unfortunately, EventDispatcher states:
function addEventListener(eventType:String,
eventListener):Void
{
// Note: In the future, we may add
a third parameter,
// useCapture:Boolean, to be
compliant with the
// DOM Level 3 Events spec,
// http://www.w3.org/TR/DOM-Level-
3-Events/events.html.
.
.
.
This would have been very convenient if it were implemented.
Nevertheless, Button and other components do seem able to capture
the event. Is this a question for one of the Flash lists (any
recommendation to which list I should post this question)?
Thanks, Matt - if you or anyone else has any other ideas, I'd
really love to hear them
-Tony
tony pujals| senior engineer | Yahoo! SiteBuilder Express
p. 408.349.6284 | e. tonyp * yahoo-inc . com | y!id tonypujals
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Matt Chotin
Sent: Tuesday, February 14, 2006 9:45 PM
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] Mouse Event Filtering
you want to add your mouse event listener with useCapture set to
true
and then call stopPropagation on the event in your handler (I
think). I
believe that will prevent it from moving further down the
hierarchy.
-Original Message-
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On
Behalf Of Tony Pujals
Sent: Tuesday, February 14, 2006 5:27 PM
To: flexcoders@yahoogroups.com
Subject:
RE: [flexcoders] Re: Mouse Event Filtering
Thanks for the tip, Doug ... the only problem is that I want the toolbar to be
a generic component that doesn't require any specially awareness from other
components in the form. I don't want to mandate that other programmers have to
modify their event-handling code just to accommodate my toolbar weirdness
I'm a little surprised this has turned out to be so challenging. Since I know
various components provided by Macromedia (such as Button) do behave correctly,
I guess that there is a 'standardized' way to implement this
tony pujals| senior engineer | Yahoo! SiteBuilder Express
p. 408.349.6284 | e. tonyp * yahoo-inc . com | y!id tonypujals
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Doug
Lowder
Sent: Wednesday, February 15, 2006 11:02 AM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Mouse Event Filtering
Tony, I had a similar problem in Flex 1.5 with a custom TitleWindow
component that was receiving events from objects underneath it.
Never did find out exactly why that was happening; non-100% alpha
value, perhaps? Anyway, I solved it by wrapping a simple check
around the event handler that makes sure the target property of the
event is the current object:
if (event.target == this) { // handle the event... }
It might be worth trying that somewhere, like in a delegate for the
mouseMove event or in handleEvent().
Hope that's of some help.
Doug
--- In flexcoders@yahoogroups.com, Tony Pujals [EMAIL PROTECTED] wrote:
Well, the Flash asdocs really don't make this clear, but I
initially had a suspicion that overriding a handler instead of
registering a listener might be the answer. I didn't pursue that
direction right away because the method signatures don't return a
Boolean or some other value to indicate that an event was handled
and no further processing is wanted.
In any case, I was able to achieve the glass pane effect that I
wanted this morning with the following code:
options = { width: 100%, height: 100%};
Canvas(createChild(Canvas, _glassPane, options));
_glassPane.setStyle(backgroundColor, #FF00FF);
_glassPane.alpha = 0;
_glassPane.visible = false;
MovieClip(_glassPane).onPress = function() {}
All of the above was required: without a backgroundColor being
set, events weren't captured at all; The alpha, of course, was to
make the glass pane actually invisible (there maybe other properties
beside backgroundColor that also work for causing events to get
caught, but I haven't experimented). The visible property -- once a
backgroundColor property is set -- is what enables and disables the
event capturing.
However, for the toolbar that I also wanted to capture events so
the text component below doesn't receive them, this is not yet a
complete solution because it also prevents the child components (the
toolbar buttons) from getting any events either. I've written some
code to iterate the child components, but I don't know what to pass
to them -- it seems intrinsically wrong that the toolbar needs to
become an event manager from its onPress handler:
// doesn't work -- onPress doesn't have event parameter anyway...
MovieClip(this).onPress = mx.utils.Delegate.create(this, function
(event) {
var comp : UIObject = null;
for (var i : Number = 0; i childDescriptors.length; i++) {
comp = getChildAt(i);
if (hitTest(comp)) {
comp.handleEvent(event);
}
}
});
(Incidentally, if there is some other more appropriate way for
iterating child components, I'd appreciate hearing about it).
So Flash/Flex gurus ... what am I missing here...? Thanks!
Tony
tony pujals| senior engineer | Yahoo! SiteBuilder Express
p. 408.349.6284 | e. tonyp * yahoo-inc . com | y!id tonypujals
From: Tony Pujals
Sent: Wednesday, February 15, 2006 7:43 AM
To: 'flexcoders@yahoogroups.com'
Subject: RE: [flexcoders] Mouse Event Filtering
Sorry, I don't know if this works in the Flex 2 beta, but I should
have specified that we're working with Flex 1.5 at Yahoo.
Unfortunately, EventDispatcher states:
function addEventListener(eventType:String,
eventListener):Void
{
// Note: In the future, we may add
a third parameter,
// useCapture:Boolean, to be
compliant with the
// DOM Level 3 Events spec,
// http://www.w3.org/TR/DOM-Level-
3-Events/events.html.
.
.
.
This would have been very convenient if it were implemented.
Nevertheless, Button and other components do seem able to capture
the event. Is this a question for one of the Flash lists (any
recommendation to which list I should post
[flexcoders] Re: Mouse Event Filtering
I should have pointed out I was talking specifically about the
custom floating toolbar you mentioned in point 2 of your original
post. It seems to me your toolbar is handling events from other
components when it shouldn't. Try putting the event.target test
into your toolbar code; no need to put it into any other components.
Doug
--- In flexcoders@yahoogroups.com, Tony Pujals [EMAIL PROTECTED] wrote:
Thanks for the tip, Doug ... the only problem is that I want the
toolbar to be a generic component that doesn't require any specially
awareness from other components in the form. I don't want to mandate
that other programmers have to modify their event-handling code just
to accommodate my toolbar weirdness I'm a little surprised this
has turned out to be so challenging. Since I know various components
provided by Macromedia (such as Button) do behave correctly, I guess
that there is a 'standardized' way to implement this
tony pujals| senior engineer | Yahoo! SiteBuilder Express
p. 408.349.6284 | e. tonyp * yahoo-inc . com | y!id tonypujals
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Doug Lowder
Sent: Wednesday, February 15, 2006 11:02 AM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Mouse Event Filtering
Tony, I had a similar problem in Flex 1.5 with a custom
TitleWindow
component that was receiving events from objects underneath it.
Never did find out exactly why that was happening; non-100% alpha
value, perhaps? Anyway, I solved it by wrapping a simple check
around the event handler that makes sure the target property of
the
event is the current object:
if (event.target == this) { // handle the event... }
It might be worth trying that somewhere, like in a delegate for
the
mouseMove event or in handleEvent().
Hope that's of some help.
Doug
--- In flexcoders@yahoogroups.com, Tony Pujals tonyp@ wrote:
Well, the Flash asdocs really don't make this clear, but I
initially had a suspicion that overriding a handler instead of
registering a listener might be the answer. I didn't pursue that
direction right away because the method signatures don't return a
Boolean or some other value to indicate that an event was handled
and no further processing is wanted.
In any case, I was able to achieve the glass pane effect that I
wanted this morning with the following code:
options = { width: 100%, height: 100%};
Canvas(createChild(Canvas, _glassPane, options));
_glassPane.setStyle(backgroundColor, #FF00FF);
_glassPane.alpha = 0;
_glassPane.visible = false;
MovieClip(_glassPane).onPress = function() {}
All of the above was required: without a backgroundColor being
set, events weren't captured at all; The alpha, of course, was to
make the glass pane actually invisible (there maybe other
properties
beside backgroundColor that also work for causing events to get
caught, but I haven't experimented). The visible property -- once
a
backgroundColor property is set -- is what enables and disables
the
event capturing.
However, for the toolbar that I also wanted to capture events so
the text component below doesn't receive them, this is not yet a
complete solution because it also prevents the child components
(the
toolbar buttons) from getting any events either. I've written some
code to iterate the child components, but I don't know what to
pass
to them -- it seems intrinsically wrong that the toolbar needs to
become an event manager from its onPress handler:
// doesn't work -- onPress doesn't have event parameter anyway...
MovieClip(this).onPress = mx.utils.Delegate.create(this, function
(event) {
var comp : UIObject = null;
for (var i : Number = 0; i childDescriptors.length; i++) {
comp = getChildAt(i);
if (hitTest(comp)) {
comp.handleEvent(event);
}
}
});
(Incidentally, if there is some other more appropriate way for
iterating child components, I'd appreciate hearing about it).
So Flash/Flex gurus ... what am I missing here...? Thanks!
Tony
tony pujals| senior engineer | Yahoo! SiteBuilder Express
p. 408.349.6284 | e. tonyp * yahoo-inc . com | y!id tonypujals
From: Tony Pujals
Sent: Wednesday, February 15, 2006 7:43 AM
To: 'flexcoders@yahoogroups.com'
Subject: RE: [flexcoders] Mouse Event Filtering
Sorry, I don't know if this works in the Flex 2 beta, but I
should
have specified that we're working with Flex 1.5 at Yahoo.
Unfortunately, EventDispatcher states:
function addEventListener(eventType:String,
eventListener):Void
{
// Note: In the future, we may
add
a third parameter,
// useCapture:Boolean
RE: [flexcoders] Re: Mouse Event Filtering
Hey Doug - thanks for the input. This is a link to a screenshot that may help
clear up the issue:
http://www.geocities.com/tonypujals/eventcapture.jpg
What the screenshot shows is that I dragged the toolbar over the TextArea
component. Then, I dragged the toolbar just a little bit again ... which
resulted in the highlighted text that you see displayed. In other words, the
toolbar isn't handling events from other components when it shouldn't - the
opposite is happening: other components are receiving events I don't want them
to. When I mouse down and drag the toolbar, I want it to move without events
propagating to components below it. I want the toolbar events to be consumed
when they act upon the toolbar.
Also, what the picture doesn't show since Windows doesn't capture it in
screenshots is that the mouse cursor over the toolbar is an i-beam cursor -
which is what it should be when over text, but not over the toolbar. It is only
an i-beam when it is not specifically over one of the toolbar buttons, just the
toolbar gradient background Canvas.
Rather than using mouse handlers for the toolbar, I tried overriding the
onMouseXXX methods of MovieClip in the hope perhaps that this would prevent
some superclass behavior which forwards the mouse events to further processing,
but it didn't help
Argh...
tony pujals| senior engineer | Yahoo! SiteBuilder Express
p. 408.349.6284 | e. tonyp * yahoo-inc . com | y!id tonypujals
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Doug
Lowder
Sent: Wednesday, February 15, 2006 12:41 PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Mouse Event Filtering
I should have pointed out I was talking specifically about the
custom floating toolbar you mentioned in point 2 of your original
post. It seems to me your toolbar is handling events from other
components when it shouldn't. Try putting the event.target test
into your toolbar code; no need to put it into any other components.
Doug
--- In flexcoders@yahoogroups.com, Tony Pujals [EMAIL PROTECTED] wrote:
Thanks for the tip, Doug ... the only problem is that I want the
toolbar to be a generic component that doesn't require any specially
awareness from other components in the form. I don't want to mandate
that other programmers have to modify their event-handling code just
to accommodate my toolbar weirdness I'm a little surprised this
has turned out to be so challenging. Since I know various components
provided by Macromedia (such as Button) do behave correctly, I guess
that there is a 'standardized' way to implement this
tony pujals| senior engineer | Yahoo! SiteBuilder Express
p. 408.349.6284 | e. tonyp * yahoo-inc . com | y!id tonypujals
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Doug Lowder
Sent: Wednesday, February 15, 2006 11:02 AM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Mouse Event Filtering
Tony, I had a similar problem in Flex 1.5 with a custom
TitleWindow
component that was receiving events from objects underneath it.
Never did find out exactly why that was happening; non-100% alpha
value, perhaps? Anyway, I solved it by wrapping a simple check
around the event handler that makes sure the target property of
the
event is the current object:
if (event.target == this) { // handle the event... }
It might be worth trying that somewhere, like in a delegate for
the
mouseMove event or in handleEvent().
Hope that's of some help.
Doug
--- In flexcoders@yahoogroups.com, Tony Pujals tonyp@ wrote:
Well, the Flash asdocs really don't make this clear, but I
initially had a suspicion that overriding a handler instead of
registering a listener might be the answer. I didn't pursue that
direction right away because the method signatures don't return a
Boolean or some other value to indicate that an event was handled
and no further processing is wanted.
In any case, I was able to achieve the glass pane effect that I
wanted this morning with the following code:
options = { width: 100%, height: 100%};
Canvas(createChild(Canvas, _glassPane, options));
_glassPane.setStyle(backgroundColor, #FF00FF);
_glassPane.alpha = 0;
_glassPane.visible = false;
MovieClip(_glassPane).onPress = function() {}
All of the above was required: without a backgroundColor being
set, events weren't captured at all; The alpha, of course, was to
make the glass pane actually invisible (there maybe other
properties
beside backgroundColor that also work for causing events to get
caught, but I haven't experimented). The visible property -- once
a
backgroundColor property is set -- is what enables and disables
the
event capturing.
However, for the toolbar that I also wanted to capture events so
[flexcoders] Re: Mouse Event Filtering
Yeah, it's possible this is something entirely different from my
situation, but I think there is still the similarity that an
obscured ocmponent is acting as if it's not obscured.
Can you post some code?
--- In flexcoders@yahoogroups.com, Tony Pujals [EMAIL PROTECTED] wrote:
Hey Doug - thanks for the input. This is a link to a screenshot
that may help clear up the issue:
http://www.geocities.com/tonypujals/eventcapture.jpg
What the screenshot shows is that I dragged the toolbar over the
TextArea component. Then, I dragged the toolbar just a little bit
again ... which resulted in the highlighted text that you see
displayed. In other words, the toolbar isn't handling events from
other components when it shouldn't - the opposite is happening:
other components are receiving events I don't want them to. When I
mouse down and drag the toolbar, I want it to move without events
propagating to components below it. I want the toolbar events to be
consumed when they act upon the toolbar.
Also, what the picture doesn't show since Windows doesn't capture
it in screenshots is that the mouse cursor over the toolbar is an i-
beam cursor - which is what it should be when over text, but not
over the toolbar. It is only an i-beam when it is not specifically
over one of the toolbar buttons, just the toolbar gradient
background Canvas.
Rather than using mouse handlers for the toolbar, I tried
overriding the onMouseXXX methods of MovieClip in the hope perhaps
that this would prevent some superclass behavior which forwards the
mouse events to further processing, but it didn't help
Argh...
tony pujals| senior engineer | Yahoo! SiteBuilder Express
p. 408.349.6284 | e. tonyp * yahoo-inc . com | y!id tonypujals
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Doug Lowder
Sent: Wednesday, February 15, 2006 12:41 PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Mouse Event Filtering
I should have pointed out I was talking specifically about the
custom floating toolbar you mentioned in point 2 of your original
post. It seems to me your toolbar is handling events from other
components when it shouldn't. Try putting the event.target test
into your toolbar code; no need to put it into any other
components.
Doug
--- In flexcoders@yahoogroups.com, Tony Pujals tonyp@ wrote:
Thanks for the tip, Doug ... the only problem is that I want the
toolbar to be a generic component that doesn't require any
specially
awareness from other components in the form. I don't want to
mandate
that other programmers have to modify their event-handling code
just
to accommodate my toolbar weirdness I'm a little surprised
this
has turned out to be so challenging. Since I know various
components
provided by Macromedia (such as Button) do behave correctly, I
guess
that there is a 'standardized' way to implement this
tony pujals| senior engineer | Yahoo! SiteBuilder Express
p. 408.349.6284 | e. tonyp * yahoo-inc . com | y!id tonypujals
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Doug Lowder
Sent: Wednesday, February 15, 2006 11:02 AM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Mouse Event Filtering
Tony, I had a similar problem in Flex 1.5 with a custom
TitleWindow
component that was receiving events from objects underneath it.
Never did find out exactly why that was happening; non-100%
alpha
value, perhaps? Anyway, I solved it by wrapping a simple check
around the event handler that makes sure the target property of
the
event is the current object:
if (event.target == this) { // handle the event... }
It might be worth trying that somewhere, like in a delegate for
the
mouseMove event or in handleEvent().
Hope that's of some help.
Doug
--- In flexcoders@yahoogroups.com, Tony Pujals tonyp@ wrote:
Well, the Flash asdocs really don't make this clear, but I
initially had a suspicion that overriding a handler instead of
registering a listener might be the answer. I didn't pursue that
direction right away because the method signatures don't return
a
Boolean or some other value to indicate that an event was
handled
and no further processing is wanted.
In any case, I was able to achieve the glass pane effect that
I
wanted this morning with the following code:
options = { width: 100%, height: 100%};
Canvas(createChild(Canvas, _glassPane, options));
_glassPane.setStyle(backgroundColor, #FF00FF);
_glassPane.alpha = 0;
_glassPane.visible = false;
MovieClip(_glassPane).onPress = function() {}
All of the above was required: without a backgroundColor being
set, events weren't captured at all; The alpha, of course
RE: [flexcoders] Re: Mouse Event Filtering
Yes, that's exactly the similarity -- but an obscured component should not even
have to be aware of a toolbar component above it. It should not receive a
mouseDown event if the component above is handling it. It's only my toolbar
canvas that seems to allow events to pass through to the TextArea below it --
the toolbar buttons don't.
As far as code, I'll create a streamlined example that should make it a little
easier to see what I'm talking about Thanks again, Doug.
tony pujals| senior engineer | Yahoo! SiteBuilder Express
p. 408.349.6284 | e. tonyp * yahoo-inc . com | y!id tonypujals
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Doug
Lowder
Sent: Wednesday, February 15, 2006 3:13 PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Mouse Event Filtering
Yeah, it's possible this is something entirely different from my
situation, but I think there is still the similarity that an
obscured ocmponent is acting as if it's not obscured.
Can you post some code?
--- In flexcoders@yahoogroups.com, Tony Pujals [EMAIL PROTECTED] wrote:
Hey Doug - thanks for the input. This is a link to a screenshot
that may help clear up the issue:
http://www.geocities.com/tonypujals/eventcapture.jpg
What the screenshot shows is that I dragged the toolbar over the
TextArea component. Then, I dragged the toolbar just a little bit
again ... which resulted in the highlighted text that you see
displayed. In other words, the toolbar isn't handling events from
other components when it shouldn't - the opposite is happening:
other components are receiving events I don't want them to. When I
mouse down and drag the toolbar, I want it to move without events
propagating to components below it. I want the toolbar events to be
consumed when they act upon the toolbar.
Also, what the picture doesn't show since Windows doesn't capture
it in screenshots is that the mouse cursor over the toolbar is an i-
beam cursor - which is what it should be when over text, but not
over the toolbar. It is only an i-beam when it is not specifically
over one of the toolbar buttons, just the toolbar gradient
background Canvas.
Rather than using mouse handlers for the toolbar, I tried
overriding the onMouseXXX methods of MovieClip in the hope perhaps
that this would prevent some superclass behavior which forwards the
mouse events to further processing, but it didn't help
Argh...
tony pujals| senior engineer | Yahoo! SiteBuilder Express
p. 408.349.6284 | e. tonyp * yahoo-inc . com | y!id tonypujals
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Doug Lowder
Sent: Wednesday, February 15, 2006 12:41 PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Mouse Event Filtering
I should have pointed out I was talking specifically about the
custom floating toolbar you mentioned in point 2 of your original
post. It seems to me your toolbar is handling events from other
components when it shouldn't. Try putting the event.target test
into your toolbar code; no need to put it into any other
components.
Doug
--- In flexcoders@yahoogroups.com, Tony Pujals tonyp@ wrote:
Thanks for the tip, Doug ... the only problem is that I want the
toolbar to be a generic component that doesn't require any
specially
awareness from other components in the form. I don't want to
mandate
that other programmers have to modify their event-handling code
just
to accommodate my toolbar weirdness I'm a little surprised
this
has turned out to be so challenging. Since I know various
components
provided by Macromedia (such as Button) do behave correctly, I
guess
that there is a 'standardized' way to implement this
tony pujals| senior engineer | Yahoo! SiteBuilder Express
p. 408.349.6284 | e. tonyp * yahoo-inc . com | y!id tonypujals
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Doug Lowder
Sent: Wednesday, February 15, 2006 11:02 AM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Mouse Event Filtering
Tony, I had a similar problem in Flex 1.5 with a custom
TitleWindow
component that was receiving events from objects underneath it.
Never did find out exactly why that was happening; non-100%
alpha
value, perhaps? Anyway, I solved it by wrapping a simple check
around the event handler that makes sure the target property of
the
event is the current object:
if (event.target == this) { // handle the event... }
It might be worth trying that somewhere, like in a delegate for
the
mouseMove event or in handleEvent().
Hope that's of some help.
Doug
--- In flexcoders@yahoogroups.com, Tony Pujals tonyp@ wrote:
Well, the Flash asdocs really don't make this clear, but I
initially had
RE: [flexcoders] Re: Mouse Event Filtering
Can you try assigning onPress to the component, I think that's how we've gotten our blockers to work in the past. Matt -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Tony Pujals Sent: Wednesday, February 15, 2006 3:33 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Mouse Event Filtering Yes, that's exactly the similarity -- but an obscured component should not even have to be aware of a toolbar component above it. It should not receive a mouseDown event if the component above is handling it. It's only my toolbar canvas that seems to allow events to pass through to the TextArea below it -- the toolbar buttons don't. As far as code, I'll create a streamlined example that should make it a little easier to see what I'm talking about Thanks again, Doug. tony pujals| senior engineer | Yahoo! SiteBuilder Express p. 408.349.6284 | e. tonyp * yahoo-inc . com | y!id tonypujals From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Doug Lowder Sent: Wednesday, February 15, 2006 3:13 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Mouse Event Filtering Yeah, it's possible this is something entirely different from my situation, but I think there is still the similarity that an obscured ocmponent is acting as if it's not obscured. Can you post some code? --- In flexcoders@yahoogroups.com, Tony Pujals [EMAIL PROTECTED] wrote: Hey Doug - thanks for the input. This is a link to a screenshot that may help clear up the issue: http://www.geocities.com/tonypujals/eventcapture.jpg What the screenshot shows is that I dragged the toolbar over the TextArea component. Then, I dragged the toolbar just a little bit again ... which resulted in the highlighted text that you see displayed. In other words, the toolbar isn't handling events from other components when it shouldn't - the opposite is happening: other components are receiving events I don't want them to. When I mouse down and drag the toolbar, I want it to move without events propagating to components below it. I want the toolbar events to be consumed when they act upon the toolbar. Also, what the picture doesn't show since Windows doesn't capture it in screenshots is that the mouse cursor over the toolbar is an i- beam cursor - which is what it should be when over text, but not over the toolbar. It is only an i-beam when it is not specifically over one of the toolbar buttons, just the toolbar gradient background Canvas. Rather than using mouse handlers for the toolbar, I tried overriding the onMouseXXX methods of MovieClip in the hope perhaps that this would prevent some superclass behavior which forwards the mouse events to further processing, but it didn't help Argh... tony pujals| senior engineer | Yahoo! SiteBuilder Express p. 408.349.6284 | e. tonyp * yahoo-inc . com | y!id tonypujals From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Doug Lowder Sent: Wednesday, February 15, 2006 12:41 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Mouse Event Filtering I should have pointed out I was talking specifically about the custom floating toolbar you mentioned in point 2 of your original post. It seems to me your toolbar is handling events from other components when it shouldn't. Try putting the event.target test into your toolbar code; no need to put it into any other components. Doug --- In flexcoders@yahoogroups.com, Tony Pujals tonyp@ wrote: Thanks for the tip, Doug ... the only problem is that I want the toolbar to be a generic component that doesn't require any specially awareness from other components in the form. I don't want to mandate that other programmers have to modify their event-handling code just to accommodate my toolbar weirdness I'm a little surprised this has turned out to be so challenging. Since I know various components provided by Macromedia (such as Button) do behave correctly, I guess that there is a 'standardized' way to implement this tony pujals| senior engineer | Yahoo! SiteBuilder Express p. 408.349.6284 | e. tonyp * yahoo-inc . com | y!id tonypujals From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Doug Lowder Sent: Wednesday, February 15, 2006 11:02 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Mouse Event Filtering Tony, I had a similar problem in Flex 1.5 with a custom TitleWindow component that was receiving events from objects underneath it. Never did find out exactly why that was happening; non-100% alpha value, perhaps? Anyway, I solved it by wrapping a simple check around the event handler that makes sure the target property of the event is the current object
