In an application that I was creating, I was using the MouseEventArgs.Handled property. After upgrading to RC0, this property was removed and promoted to MouseButtonEventArgs. If one of the main goals of RC0 was to close the gap between WPF and Silverlight,
why was this done? If anything, the Handled property should exist on RoutedEventArgs. In my specific case, because I am trying to target both WPF and Silverlight, this forced me to create wrappers around the MouseEventArgs. This is not desirable. I would ask
that the Handled property be moved either back to MouseEventArgs or to the proper location on RoutedEventArgs.
I just created a class that has all the same methods as the SL version of MouseEventArgs, but also added the Handled property. The class takes a MouseEventArgs in the constructor and forwards all method calls to it. For the Handled property, I used #if's.
If compiling against SL, I use a private field in the wrapper class. If compiling against WPF, I forward the call to its Handled property. I then had to factor the code so that anywhere that depended on MouseEventArgs, now takes my wrapper. This doesn't actually
cancel event bubbling in the same way as it would in WPF. However, in my app, I am manually handling the event chaining, so I can work around it. I admit this probably isn't the best solution, but it works in my case. Hope this helps.
Hello, can you tell me why do you want to set MouseEventArgs.Handled to true, to prevent the event from bubbling? What's your scenario? In Beta 2 timeframe, we heard a lot of feedback that a lot of events are marked as Handled internally. This had caused
a lot of troubles. Generally speaking, you should only mark an event as handled when other event handlers expects you to do so. But it's unlikely that is a requirement, especially for events using MouseEventArgs, such as MouseEnter/Leave/Move. Leave this property
will cause more confusions than the problems it solves. So we decide to remove it from some events, while keep it on the other, when necessary.
By the way, you can always check e.OriginalSource in your parent Control's event handler, to determine if you want to handle the event or not.
shanaolanxing - I'll transfer to the Windows Azure team, and will have limited time to participate in the Silverlight forum. Apologize if I don't answer your questions in time.
Yes, I need to set that property to Handled to stop event bubbling. In my case, I am building a map control. There are times when a consumer of the map control will want to override the default behavior of the map. This is what I was using the Handled property
for. I totally agree that the Handled property shouldn't be set internally in the framework. Removing that property from MouseEventArgs and promoting to classes further down the heirarchy is creating unnecessary differences between WPF and Silverlight.
What do I do if want to drag/drop a button around the screen? Do I need to inherit from the button and override the MouseLeftButtonDown event so I can prevent the event from being handled and having my drag/drop code be notified of the MouseLeftButtonDown event?
Hello, can you tell me why do you want to set MouseEventArgs.Handled to true, to prevent the event from bubbling? What's your scenario? In Beta 2 timeframe, we heard a lot of feedback that a lot of events are marked as Handled internally. This had caused
a lot of troubles. Generally speaking, you should only mark an event as handled when other event handlers expects you to do so. But it's unlikely that is a requirement, especially for events using MouseEventArgs, such as MouseEnter/Leave/Move. Leave this property
will cause more confusions than the problems it solves. So we decide to remove it from some events, while keep it on the other, when necessary.
By the way, you can always check e.OriginalSource in your parent Control's event handler, to determine if you want to handle the event or not.
I am sorry, but I think you are completely missing the point of Handled. It does not mean that it is the FIRST object dealing with an event, but it says that previous object has DONE something with this event, This (I quote) "unlikely requirement" happens
in almost all my applications, for example to identify while m oving the object, over which panel moved object is currently positioned or how to display moved object or to change dynamically the cursor.
Before you say to use MouseEnter and MouseLeave - they are not raised in the proper (for me) moments as well.
Of course everything can be somehow implemented and lack of Handled will enforce me to implement separate stack keeping extra information, so it is doable. I just cannot understand a logic in removing this property. As the person starting this thread said,
Handled should be in fact part of every RoutedEvent. I would also recommend to add something like Tag to keep extra data which can be used by event handlers and pass an information from one to the other. We for example need it to implement properly doubleClick
(Double Click event sequence should be called after finishing MouseUp bubbling sequence)
I couldn't agree more. I created a drag and drop extension, this is not a UI element but more of a behavior (ala Nikhil Kothari), I can dynamically attach this behavior to different UI elements so I don't have to write the same drag code everywhere. When
dragging something around I need to prevent event bubbling so that UI element to which my behavior is attached no longer gets mouse move messages. (This is probably why the windows forms implementation creates a hidden window so that it can capture the mouse
exclusively) Without the ability to prevent bubbling this makes extensions like this unwieldly because you need to put logic in the attached UIElement to check for drag drop states and therefore compromises the composability of your controls.
I CANNOT believe the Handled property has been removed! This totally screws up my control which was working great in beta2. AAHHHRRRRRR!
The upgrade from beta2 to RTW was going to good to be true and it ended up not being true. You talk about closing the API gap with WPF yet you go ahead and do this. I guess there's no use complaining. RTW is out and that's just the way it's going to be
Hi, I have a big problem: when I resize my control I want it don't drag. With Silverlight 2 beta 2 I used MouseEventArgs.Handled property, but now with RC1 it doesn't exist. Can you write me some line of code to explain me how can I resolv my problem?
cobyjone
0 Points
6 Posts
RC0 - MouseEventArgs.Handled removed
Sep 27, 2008 12:30 PM | LINK
In an application that I was creating, I was using the MouseEventArgs.Handled property. After upgrading to RC0, this property was removed and promoted to MouseButtonEventArgs. If one of the main goals of RC0 was to close the gap between WPF and Silverlight, why was this done? If anything, the Handled property should exist on RoutedEventArgs. In my specific case, because I am trying to target both WPF and Silverlight, this forced me to create wrappers around the MouseEventArgs. This is not desirable. I would ask that the Handled property be moved either back to MouseEventArgs or to the proper location on RoutedEventArgs.
Martin Krusz...
Member
15 Points
30 Posts
Re: RC0 - MouseEventArgs.Handled removed
Sep 28, 2008 08:08 AM | LINK
Could you show how you make the wrapper for MouseEventArgs ?
cobyjone
0 Points
6 Posts
Re: RC0 - MouseEventArgs.Handled removed
Sep 28, 2008 03:54 PM | LINK
I just created a class that has all the same methods as the SL version of MouseEventArgs, but also added the Handled property. The class takes a MouseEventArgs in the constructor and forwards all method calls to it. For the Handled property, I used #if's. If compiling against SL, I use a private field in the wrapper class. If compiling against WPF, I forward the call to its Handled property. I then had to factor the code so that anywhere that depended on MouseEventArgs, now takes my wrapper. This doesn't actually cancel event bubbling in the same way as it would in WPF. However, in my app, I am manually handling the event chaining, so I can work around it. I admit this probably isn't the best solution, but it works in my case. Hope this helps.
Yi-Lun Luo -...
All-Star
25149 Points
2759 Posts
Microsoft
Re: RC0 - MouseEventArgs.Handled removed
Sep 29, 2008 08:37 AM | LINK
Hello, can you tell me why do you want to set MouseEventArgs.Handled to true, to prevent the event from bubbling? What's your scenario? In Beta 2 timeframe, we heard a lot of feedback that a lot of events are marked as Handled internally. This had caused a lot of troubles. Generally speaking, you should only mark an event as handled when other event handlers expects you to do so. But it's unlikely that is a requirement, especially for events using MouseEventArgs, such as MouseEnter/Leave/Move. Leave this property will cause more confusions than the problems it solves. So we decide to remove it from some events, while keep it on the other, when necessary.
By the way, you can always check e.OriginalSource in your parent Control's event handler, to determine if you want to handle the event or not.
cobyjone
0 Points
6 Posts
Re: RC0 - MouseEventArgs.Handled removed
Sep 29, 2008 12:16 PM | LINK
Yes, I need to set that property to Handled to stop event bubbling. In my case, I am building a map control. There are times when a consumer of the map control will want to override the default behavior of the map. This is what I was using the Handled property for. I totally agree that the Handled property shouldn't be set internally in the framework. Removing that property from MouseEventArgs and promoting to classes further down the heirarchy is creating unnecessary differences between WPF and Silverlight.
fsuguinness
Member
18 Points
27 Posts
Re: Re: RC0 - MouseEventArgs.Handled removed
Sep 30, 2008 03:47 PM | LINK
zbychuk
Member
56 Points
34 Posts
Re: RC0 - MouseEventArgs.Handled removed
Sep 30, 2008 05:44 PM | LINK
I am sorry, but I think you are completely missing the point of Handled. It does not mean that it is the FIRST object dealing with an event, but it says that previous object has DONE something with this event, This (I quote) "unlikely requirement" happens in almost all my applications, for example to identify while m oving the object, over which panel moved object is currently positioned or how to display moved object or to change dynamically the cursor.
Before you say to use MouseEnter and MouseLeave - they are not raised in the proper (for me) moments as well.
Of course everything can be somehow implemented and lack of Handled will enforce me to implement separate stack keeping extra information, so it is doable. I just cannot understand a logic in removing this property. As the person starting this thread said, Handled should be in fact part of every RoutedEvent. I would also recommend to add something like Tag to keep extra data which can be used by event handlers and pass an information from one to the other. We for example need it to implement properly doubleClick (Double Click event sequence should be called after finishing MouseUp bubbling sequence)
splace
Member
20 Points
19 Posts
Re: RC0 - MouseEventArgs.Handled removed
Oct 03, 2008 05:13 PM | LINK
I couldn't agree more. I created a drag and drop extension, this is not a UI element but more of a behavior (ala Nikhil Kothari), I can dynamically attach this behavior to different UI elements so I don't have to write the same drag code everywhere. When dragging something around I need to prevent event bubbling so that UI element to which my behavior is attached no longer gets mouse move messages. (This is probably why the windows forms implementation creates a hidden window so that it can capture the mouse exclusively) Without the ability to prevent bubbling this makes extensions like this unwieldly because you need to put logic in the attached UIElement to check for drag drop states and therefore compromises the composability of your controls.
GA30
Member
35 Points
59 Posts
Re: RC0 - MouseEventArgs.Handled removed
Oct 15, 2008 10:23 PM | LINK
I CANNOT believe the Handled property has been removed! This totally screws up my control which was working great in beta2. AAHHHRRRRRR!
The upgrade from beta2 to RTW was going to good to be true and it ended up not being true. You talk about closing the API gap with WPF yet you go ahead and do this. I guess there's no use complaining. RTW is out and that's just the way it's going to be
ice85
Member
16 Points
16 Posts
Re: RC0 - MouseEventArgs.Handled removed
Dec 04, 2008 04:03 PM | LINK
Hi, I have a big problem: when I resize my control I want it don't drag. With Silverlight 2 beta 2 I used MouseEventArgs.Handled property, but now with RC1 it doesn't exist. Can you write me some line of code to explain me how can I resolv my problem?
Thanks!