WPF Is it legal to invoke another event from within an event-invocation-method.

Question

The following code was part of an answer I have received to solve a probem I have posted in SO. It works fine, however I'm curious if its allowed to manually invoke another event from within an invocation-method with the EventArgs of the original event:

protected override void OnMouseLeftButtonUp( MouseButtonEventArgs e )   {   
    base.OnMouseLeftButtonDown( e );   
}  

I have seen this pattern frequently but never used it because I feared always that this could lead to sideeffects or problems in future versions of WPF. Has anyone the insight to tell me if such redirected event-invocations are save?

Answer 1

I don't see any reason why you would not be able to do this, you're just calling a method on the base class. There's a WndProc() somewhere that receives the actual windows messages and translates them into the same call you're making.

Answer 2

I would be very careful with doing this. If the event data contains stuff that is only relevant to the original event the other event handler can be confused by this data. Especially when it comes to events from external devices like the mouse.

Maybe this example you posted is ok, I don't know. But I can definitely see a problem with doing the other way around, raising mouse down when you get a mouse up - the mouse down handler could (potentially, I have no idea if it does this) query the input device for the actual status of that mouse and they wouldn't match. Or perhaps do some operation on the mouse that only works when it is pressed etc.

So in summary: It may work, but I would not rely on it unless you are 100% sure it won't break under certain conditions

Answer 3

It would be much better if there were a new event or method that both OnMouseLeftButtonDown and OnMouseLeftButtonUp could call, with an appropriate name clarifying your intention. As the code stands right now, the control is basically lying, which works only as long as your clients never call your bluff and rely on you being truthful. It's the kind of the thing that, with more complex code, can lead to very frustrating debugging sessions. It's much better to structure and name your code so that you're expressing your intention, rather than lying to achieve a convenient side effect.