How to break when an event occurs, or determine associated handlers? - c#

I'm using a large open-source control and I can't seem to find the code that handles a double-click event. Could I perhaps have the debugger break when a double-click occurs or otherwise learn what code is associated with that event?

Well, I stumbled around until I found the code I was looking for.
BTW, before the DoubleClick event occurs, a MouseDown event occurs for the second click, with MouseEventArgs.Clicks == 2.

The event you're probably looking for is Control.MouseDoubleClick, which is raised whenever a control is double-clicked by the mouse. Or, if you're deriving from Control, you can override OnMouseDoubleClick.

Related

What is the difference between Form.Move and Form.LocationChanged?

If you create a standard C# WinForms application, you fill find that a form has two events: Move and LocationChanged.
Move is raised when the form moves and LocationChanged is raised when the form location property changes.
Surely if the form moves, the location property will change, too?
What is the difference between the two events? In which case will one fire and not the other?
The Move and LocationChanged events are declared on the Control class, which is then inherited by ScrollableControl, ContainerControl and finally Form.
According to the source code, OnLocationChanged calls OnMove before it invokes the LocationChanged event handler. So, the OnMove event will be raised first and then LocationChanged. You could in theory handle both events knowing that Move will be occur first.
If you look through the source you'll see that LocationChanged is raised when the bounds change (or similar events). You'll also notice that the only thing which actually invokes OnMove is in fact OnLocationChanged.
According to MSDN, the LocationChanged event:
Occurs when the Location property value has changed.... This event is
raised if the Location property is changed by either a programmatic
modification or through interaction.
It makes no such distinction for OnMove, where it merely states:
Occurs when the control is moved.
Which is curious since the two events are tied to each other.
This is however how one specific class handles these events. I did a bit of searching through the reference source and I couldn't find anything (inheriting from Control) which explicitly called OnMove other than the instance I've already cited. That doesn't mean they don't exist or that one couldn't invoke it separately in their own subclass of Control.
Both Move and LocationChanged events are interconnected. I believe there is no situation when one if fired and the other is not. The difference is that they belong to different categories of events.
The Move event has [SRCategoryAttribute("CatLayout")] attribute.
The LocationChanged event has [SRCategoryAttribute("CatPropertyChanged")] attribute.

Prevent child controls from receiving routed events

Lets say I have my user-control somewhere in the visual tree. Parent and children are 3rd-party controls that I cannot modify. I want to filter keyboard events in my control so that children controls do not receive some keyboard events, but the parent controls do.
I'll try to explain what I want to achieve with some diagrams. If controls do not handle keyboard events, all events bounce through the visual tree:
But, f.e. when user presses A,
Child2.OnPreviewKeyDown() should NOT be called
but Parent2.OnTextInput should still receive an event
I can achive (1) by setting e.Handled = true in MyControl.PreviewKeyDown. The problem is that in this case TextInput event is not generated:
Is there a way to achieve behavior like on the 2nd picture?
Added:
The problem I'm trying to solve is that a 3rd-party control (Child 2) steals some input in OnPreviewKeyDown (and marks event as handled), and I'm trying to avoid that.
What you can generally do in WPF to handle a suppressed event is add a handler in code and re-raise the event. To do this, you use the UIElement.AddHandler() method, for example:
child2.AddHandler(UIElement.TextInput, new TextCompositionEventHandler(nameOfYourHandlerFunction), true);
The 'true' boolean value is what makes nameOfYourHandlerFunction fire even if the Handled flag is set. The event won't automatically re-bubble by doing that, so you need to raise the event again.
base.RaiseEvent(e);
This works for events that have a routing strategy of Bubble.

RaiseEvent PreviewMouseDown

How does one go about raising an event for PreviewMouseDown. I can successfully do this for MouseClick events... but falling short on the preview variation. The goal is the automate PreviewMouseDown and then PreviewMouseUp only when needed.
Cheers.
Not sure what you mean by "automate PreviewMouseDown" but PreviewXXX routed events in WPF are tunneled down the control automatically (from top of the visual tree) and then it calls the XXX event which gets bubbled up.
There is no way you can 'just' call PreviewXX event. Though you can handle them separtely by attaching to the right event.

Is there anyway to stop the flow of events in .NET?

that is a question I have been asking myself for a while.
Giving a certain flow of events, can I when handling one of them, stop the next ones to be raised?
For example, when collapsing a node which child was selected in a treeview (winform), the events are raised like that:
BeforeCollapse
BeforeSelect
AfterSelect
AfterCollapse
I could stop them by using a class member, but I was wondering whether there was a built-in function or just another way (a more elegant way) to achieve this, by acting directly on the events queue.
Any idea?
Not easily, no. The order of the events firing is controlled by the TreeView control class, and there is no built-in way to prevent events from firing. But you have a couple of options:
Create your own TreeView class that inherits from the base class,
then add a bool property to prevent the events from processing.
Then you can override BeforeCollapse, etc. to check the bool
before calling base.BeforeCollapse.
Just create a bool flag, and check the flag in each of the events.
No there is no way to do that for that type of event (you are asking for TreeView).
Like for example could be managed KeyEventArgs.Handled via built-in mechanism.
You can use some instance (boolean ?) value to manage the flow,
or you can, unsubscribe from the event that you don't want more recieve, but after subscribe to it again. Sounds rough solution, but sometimes turns out reasonable one.
even if the event are raised nothing will happen if you don't bind an event handler to them. In this case you can just remove the handler using the code below:
object.Event -= new EventHandlerType(your_Method)
Otherwise you should create your own custom control
according to OnBeforeCollapse you get an TreeViewCancelEventArgs which has an Cancel property. Setting this to true should stop the flow, but will also not collapse it.
Same goes for OnBeforeSelect.
The only times you can easily "cancel" an event is if the event handler has the CancelEventHandler delegate type. Even then it doesn't really cancel it as much as set a flag for the remaining events that makes it skip performing all the events subscribed to it.
If you did have a CancelEventHandler type (which these don't) you'd simply set Cancel to true on the event object itself in the handler.
Plenty of other answers give you suggestions for what you should o. I'd just go with your idea: set a 'event cancelled' flag in your control class, and check it. When the last event in the series gets called, reset it.

Events Firing Unexpectedly

Can you write code to tell an event not to fire? Sometimes in my applications events fire unexpectedly. I know this is a broad question, but it must have happened to others out there.
You could put an if-statement in your event handler around all the code or you could dynamically detach and reattach the event handlers from outside the event handler, if necessary.
But really, events don't just fire without reason. You probably have something else going on. Maybe you can explain more what the situation is?
There is no standard way to suppress an "unexpected" event. But you could remove all of the event handlers. This is rather drastic, but would be equivalent to suppressing the event.
Alternatively you could add code to the event handlers to do nothing when the event is fired unexpectedly. This assumes you can define "unexpected".
Rather than suppress an event, a better approach is to remove/suppress whatever is that's causing the event to fire.

Categories