We Keep Coding

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.

How To Detect When Other Code Setting e.Handled = true?

Using C#, .NET 4, WPF.
I have a Telerik rich text control that is losing certain key events (tab, backspace, delete, and the arrow keys are specifics).
For debugging purposes I have added handlers for PreviewKeyDown, KeyDown, CommandExecuting, and DocumentContentChanged. The behavior presents both with and without the handlers present, in both DEBUG and RELEASE mode.
If I press a key other than those listed above I get the events in the order listed above. As an example, if I press the 'a' key I get PreviewKeyDown, KeyDown, CommandExecuting, and DocumentContentChanged.
If I press the right arrow key I get PreviewKeyDown and no other of the events fire.
My suspicion is that there is something trapping the KeyDown event at some point in the message chain before it gets to me and setting e.Handled = true.
Is there any tool available that would allow me to detect the KeyDown event and see in what code it's e.Handled is modified? I know I'm stretching here...
Thanks!
rjsjr

You could use Snoop. It can tell you, which Element set handled = true.
If you need to process these events, you can use EventManager.RegisterClassHandler().

ContextMenuStrip - Prevent item-selection by key-press

When a ContextMenuStrip is open with, say, an option for Copy - if the user presses C - Copy is selected.
How can this be prevented?

If setting the KeyPressEventArgs.Handled field doesn't do the trick, you may need to catch the PreviewKeyDown event and change the event to not be an input key (PreviewKeyDownEventArgs.IsInputKey = false) to prevent it from ever getting treated as a regular KeyDown/KeyUp/KeyPress.
See http://msdn.microsoft.com/en-us/library/vstudio/system.windows.forms.control.previewkeydown(v=vs.110).aspx for further details.
Note: you'll also have to move all your KeyPress-handling code into PreviewKeyDown, because you'll stop getting the KeyPress event when you set IsInputKey to false.

textbox not losing focus

I have a Form which covers the entire screen. I have a textbox on it which is normally hidden but appears when a user clicks, drags mouse and then leaves. After that user can enter any value in the text box. Once entered, ideally user should be able to click outside of textbox and then the normal service should resume.
By normal service I mean that form should start getting all the events. What I have done so far is that on TextBox's KeyDown event; when Escape key is pressed, I have set the focus to the main form like this:
this.Focus(); //where this is mainform.
But this doesn't seem to work since Textbox still keeps receiving all the keys. I have a KeyDown event handler both for Form and Textbox and I have checked that all the KeyDown events pass on to the TextBox. I have a TextBox Leave event Handler as well which never gets called.
This TextBox is the only control on the form and the main form is used for drawing shapes (if that matters).
So, how can I make this TextBox lose focus when user clicks outside of it.

if it works like in VB, for what I remember, try to set the form property KeyPreview to false so all keys will be passed only to the focused control on the form.

If you set your form KeyPreview property to true, your form has first chance to handle any keystrokes that you make. If it is something you want to handle i.e. escape as in your comment above, handle it in your form's KeyDownEvent and mark it as handled so your textbox will not see it.
From above Msdn Page:
When this property is set to true, the form will receive all KeyPress, KeyDown, and KeyUp events. After the form's event handlers have completed processing the keystroke, the keystroke is then assigned to the control with focus.

I guess back in '11 this didn't work, but now
this.ActiveControl = null;
works fine. However if you intend to use Tab to cycle controls, focusing a label with suitable TabIndex is the way.

What is the right method of validating .NET Windows Forms?

I'm searching on everywhere but just couldn't find a good example or text about this subject.
I would like to check for example the username and password validity when a user presses the OK button in a dialog.
Should I do this in the closing event, and cancel the dialog close if the validation fails? Or set the DialogResult to none instead of OK. These all seem kinda the wrong way to do it. I also saw the Validated and Validating events but aren't those for only validating a single control for valid input?
How can I check more controls together when the OK button is pressed, and cancel the form closing?

It depends on what you are trying to do. If you want to verify that the user entered something that could possibly be a valid username/password, you could use the Validating events (e.g. make sure it is long enough, etc). If you want to verify that the username/password corresponds to a valid account, then you have to wait until they hit the OK button and check the credentials. If they are bad then you can throw up a message box (or whatever) and prevent the dialog from closing (DialogResult.None).

Each control offers Validating event. In this event you can implement validation of a single control. By default this validation is triggered when control lose focus. In contrast to Validated event, handler of this event receives CancelEventArgs so if validation fails you can cancel current operation (losing focus).
When you want to deal with complex validations you can set AutoValidate property of your form to AutoValidate.Disable. This will disable implicit validation (default behavior described before). Instead you will have to call ValidateChildren to trigger explicit validation of all child controls.