Skip to main content
Microsoft Silverlight
Home Forums Silverlight Programming Programming with .NET - General RC0 - MouseEventArgs.Handled removed
13 replies. Latest Post by cobyjone on December 5, 2008.
(0)
cobyjone
Member
0 points
6 Posts
09-27-2008 8:30 AM |
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 K...
15 points
27 Posts
09-28-2008 4:08 AM |
Could you show how you make the wrapper for MouseEventArgs ?
09-28-2008 11:54 AM |
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 L...
All-Star
25054 points
2,747 Posts
09-29-2008 4:37 AM |
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.
09-29-2008 8:16 AM |
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
16 points
26 Posts
09-30-2008 11:47 AM |
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?
zbychuk
56 points
34 Posts
09-30-2008 1:44 PM |
Yi-Lun Luo - MSFT: 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)
splace
20 points
19 Posts
10-03-2008 1:13 PM |
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
19 points
42 Posts
10-15-2008 6:23 PM |
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
16 Posts
12-04-2008 12:03 PM |
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!
12-04-2008 12:30 PM |
Scuse me cobyjone, can you write me your wrapper class because I think that it resolves my problem? Thanks!
12-04-2008 2:42 PM |
All I did was wrap the MouseEventArgs in a class that exposes all the same methods and includes the Handled property. Then I pass this around in all my eventing code. The only reason it works for me is because in my particular case, I am manually handling all event dispatching so I can cancel event dispatching if a callee marks the property as handled. However, I am not actually marking the UIElement event as handled, which you can't do since the MouseEventArgs doesn't expose a handled property.
12-05-2008 3:39 AM |
Thanks cobyjone, but how can I cancel event dispatching without the MouseEventArgs handled property?
12-05-2008 7:30 AM |
As I said, you can't cancel the event dispatching. In my case, I don't have callers subscribing to the events on UIElement, I have them subscribing to events that I created (some of which mirror some of the interaction events on UIElement). So, I subscribe to the UIElement events and then start dispatching my events and since I can control event dispatching for those events, I can cancel event dispatching at any point. However, it is worth noting that the event cancellation only impacts my event dispatching, not the further propagation of the event from UIElement.
RC0 - MouseEventArgs.Handled removed