We Keep Coding

WPF MVVM C# Input Bindings With TextBox key presses

I am currently stuck on an issue that I have been unable to find an answer for. It involves 'overriding' built-in TextBox keyboard functions using MVVM. Here's my issue:
I have a TextBox that the users enters text into during runtime. I'm looking to implement keyboard shortcuts, or input bindings with this TextBox. I started out by using what seems to be the standard ICommand interface based approach, which I implemented simply as:
<TextBox.InputBindings>
<KeyBinding Key="Up" Command="{Binding testCommand}" Modifiers="Ctrl" />
</TextBox.InputBindings>
The idea is that I execute the command associated with the ICommand property as set in the ViewModel. However, the TextBox class already contains a baked in function for CTRL+UP which, as you may know, moves the caret to the beginning of the TextBox entry field. This function executes in addition to my Command, resulting in my desired changes, but also the caret moving.
Before MVVM, I would simply use the PreviewKeyDown event in Code-Behind, detecting the desired key combinations and using
e.Handled = true;
to stop the TextBox from firing its built in Command. This isn't an optimal solution, however, as it probably violates MVVM principles. It would also be difficult to implement in tandem with InputBindings declared in XAML.
During my research, I found an article that describes using a class provided by Blend that allows for executing a Command based off an event, potentially allowing me to listen for the PreviewKeyDown event, which fires before the built-in functions, but this would mean that I would not be declaring my key bindings in XAML, as the syntax does not seem to support keypress specific conditions, or InputBindings. I would have to do all key combination processing logic in the ViewModel, which seems like something the View should be doing.
Further research has led me to an interesting new area which involves intercepting and replacing certain 'ApplicationCommands' with a Command that always returns false on CanExecute, effectively removing the function. I was able to locate a case where someone wanted to replace the default CTRL+Z functionality. An abridged version of the full question shows the basic idea:
textBox.CommandBindings.Add(new CommandBinding(ApplicationCommands.Undo,
UndoCommand, CanUndoCommand));
Research of this ApplicationCommands class led me to a few other classes, one of which relates more directly to my issue: ComponentCommands. MSDN describes that class as containing (among other things)
ComponentCommands.MoveToHome
which would fit my Ctrl+Up command's built-in function. Using the syntax in the SO question I linked previously, I could theoretically prevent that command from executing, which is a step in the right direction. However, I'm hoping to make the key combinations that trigger my Command in my ViewModel customizable via ViewModel properties that the InputBindings would be bound to in XAML. If I implemented this approach, it would mean that I could not know ahead of time which built in functions might conflict with the user's chosen key bindings.
This was naturally resolved for me before I switched to MVVM by handling the arguments in the event handler in Code-Behind, as mentioned previously. Any key combinations I wrote into the PreviewKeyDown event handler that I had a special action for set the e.Handled to true, effectively preventing any possible built-in command that would follow once the method finished from executing after the event handler finished.
Is there some way I could implement this functionality, using InputBindings declared in XAML? What are my options?
Some ideas:
Perhaps I could expose the event handler for PreviewKeyDown on my TextBox, and inside the method I iterate through all of the TextBox's InputBindings, looking for provided key combinations that match the provided key press, and if found, I execute the associated command and set e.handled to true? I'm not familiar with manipulating InputBindings from Code-Behind, so I'm not sure how practical this would be, or if it would place too much load on the application (imagine a user holding down a key). It also seems a bit strange in terms of organization to set it up this way. I could see a situation happening where the input bindings fire twice.
I could also make a list of all the built-in commands that I'd want to always have around, even if the user set a key combination that conflicted, and disable the rest. That seems like a bad idea, as it would be quite laborious, and also could mess with something I couldn't anticipate.
Perhaps there's a way that I could calculate which built-in commands would conflict with the current input bindings and disable those, to be calculated each time the user sets the bindings?
I'm still learning MVVM and WPF, so I suspect that I may be missing something obvious or simply looking at it the wrong way. Any help would be greatly appreciated.
Edit:
It has been suggested that my question is a duplicate of this one. I have reviewed the answer and determined that the approach used is definitely a step in the right direction. I could use the attached object to implement the PreviewKeyDown handling without losing functionality of InputBindings in XAML. However, I do have some concerns.
It seems that the resolution was to move the InputBindings to the UserControl, and implement an attached object that would handle PreviewKeyDown. I have multiple TextBoxes in my UserControl which will need their own set of InputBindings, some of which would conflict with one another should they be moved to the UserControl level.
I can only conclude that the reason it was moved away from the TextBox was that the attached object could not be applied directly to the TextBox for some reason. If I was to attempt this, would I have to create some encompassing element that had the attached object that would hold each TextBox? Why can't the TextBox use the attached object itself?

How can I add a get the CommandBarControl of a default button in Outlook?

I'm trying to add a ClickEventHandler to a button to the "Invite Attendees" button found on the "New Appointment" form. However before I can do this I need a control to add the event too. In order to get this control, so far I've been trying to use Inspector.CommandBars.FindControl() without much luck. The documentation hasn't been much help to me either (https://msdn.microsoft.com/en-us/library/microsoft.office.core._commandbars.findcontrol.aspx). Where am I supposed to get the ID of the control from if I don't already have the control?!
Thanks for any help. ☺

This is simply not possible. The closest you can get to this is adding your own button and adding event handlers to that.

What is the equivalent Treeview.OnChange event in .net?

I have treeview control on a winform and need to implement onChange event for it. However, it looks like it doesn't have one and only has onChangeUI.
If the treeview doesn't support onChange event, what is its equivalent in .NET.
I've searched MSDN Library and didn't find any information.
Update: a side note I am converting win32 program for .net.
Thanks in advance,

Support for selection change is a little limited in the Windows Forms TreeView control.
Basically, there is a pair of events (BeforeSelect and AfterSelect) that allow you to react when a tree node is selected. BeforeSelect allows you to cancel the new selection, AfterSelect does not (because it occurs after the new selection has been committed).
However, none of these events are triggered when a node is unselected. To detect that case, you'll have to handle the generic MouseUp event and check the IsSelected property of the clicked node to get the actual selection state.

This is a common restriction in the wrapper classes that wrap native Windows controls. Which only generate notifications for things that you cannot know about. Like anything that the user can do that affects the control. It omits notifications for things that you do, with the underlying philosophy that you don't have to be reminded about something you already know.
Which is certainly the case for TreeView, the user cannot add any nodes. Only you can. Same thing for the text displayed in the nodes. No event to tell you the text changed. Except in the very specific case when the user edits the node, AfterLabelEdit event.
You can derive your own class from TreeView and add a Change event and OnChange() method that fires it. It is up to you to write the code to call the method. Beware that this is difficult to do reliably, the TreeNodeCollection class doesn't have virtual methods so you cannot override them to detect the client code changing nodes. You are actually better off not writing that code and simply generate an internal event in the form in any method that modifies the TreeView content.

Why does nothing in WPF have a click event?

This seems very strange to me.
I know through some adventurous inheritance you can convert most UIElements to a button, but it is a cumbersome way of implementing the most basic of of computer events

The ButtonBase class certainly has a Click event. So has derived classes.

I think the most basic events are MouseDown and MouseUp which are available to every UIElement

use RoutedEvents event if you really need to use.
Other wise use dependency property to register a Click event against your control and then do what ever you want to do.

You can add RoutedEvents to your controls.
Here is an implementation example

RichTextBox SelectionChanged called before MouseDown?

I'm working with a RichTextBox, and would like to do one thing in the SelectionChanged event if the mouse is down, and another if it's not (e.g. if the keyboard is used to select something). However, the SelectionChanged event is apparently called before MouseDown, so it seems there's no way for me to know if the mouse is down while processing the SelectionChanged. Has anyone else run into this problem? Does anyone have a solution that worked for them?
I'm doing some highlighting code, and I need to have the mouse intercepted before SelectionChanged is called.

You could save the selection in a variable and work with it in the MouseDown handler. It would give you pretty much the same behaviour.