The treeview control is always a bit difficult, I remember my first contact with Gtk.TreeView and it wasn't straightforward but the behaviour of WPF Treeview is still weird for me.
Basicly if you use a HierarchicalDataTemplate you won't be able to manage the TreeViewItems programmatically so better you create the whole treeview programmatically.
In order to go through the items in the tree, the LogicalTreeHelper and the VisualTreeHelper are very important classes. They are key classes for XAML in general.
The links below has been very useful to undertand that:
As you can read in the posts, to find out what item in the TreeView is at the position where the ContextMenu was opened, you should populate the tree with TreeViewItems, not with the HierarchicalDataTemplate.
When populating the treeview with TreeViewItems, use the Header property to attach the objects you really want to show in the tree. As usual, override the ToString property in such objects to display the desired content
Given the investment that MS is making in their new technology, WPF and its derivates (ie, Silverlight) are gonna be a very popular technology in the future and propably nice technology for the MS environment but so far I find this technology very inmature. Here you go, some reasons:
1. Visual Studio 2005 and the Cider plugin for XAML edition is plenty of bugs
2. MS Expression Blend is one of the alternatives to VS for GUI designing but it is so "inmature":
a) The xml editor is as simple as the notepad, it doesn't have intellisense, it doesn't have capabilities to indent the code, it is just a notepad with coloured syntax
b) The properties palette doesn't show all the properties than an object has and given the lack of intellisense you have to search the API in the msdn website
c) The designer behaviour is very weird and it is a nightmare if you have to relocate the controls in the GUI or just resize a grid to make it smaller (it makes the controls inside smaller as well!). I miss Glade and Stetic so much
d) The designer doesn't work on custom made controls, as you can see in the screenshot (even though the xaml is valid and the app works).
3. You miss a lot of things in the API, ie. you cannot change a selected item in a treeview programmatically because that property is readonly. Well you can do it using reflection with a few tricks, ... unbelievable. In general it is rough to change the GUI programmatically, I do think that they haven't written many applications using their own API
4. Simple controls have annoying bugs. One of the worse for me is when the SelectedItem in a ListBox never gets unselected even though you called UnselectAll, or you cleared all the items, or you assigned the SelectedItem to null. In those cases you have to manually get the SelectedItem, go to the Items property, and invoke the Remove method passing in the selectedItem.
5. The behaviour of some controls is not natural. For example, what you expect when you have a treeview and you click an item in the tree with the right mouse button, is to see a context menu and obviously to get the item selected. Well, the current treeview doesn't select the item with the rmb, you have to click with the left one first. And it is not straightforward to change this behaviour programmatically because you have no way to know which item the user clicked. Another example: if you add the width or height properties to an image it loses the size aspect ratio even if you write its real dimensions. You have to remove that properties in order to display the image properly.