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
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 this
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 the
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 a
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