![]() Furthermore, WPF’s TreeView tends to fire all sorts of SelectedItemChanged events if it’s being refreshed or rebound, which caused side-effects with TwoWay data binding. I became aware of the default control’s limitations during my last project – I naturally started with hierarchical data templates, but was soon confronted with quite a few issues: I missed a simple API to control the tree, and styling of the tree’s nodes proved hard as well. This is a little something I’ve been working on for a while: A replacement (or better: enhancement) of WPF’s built-in TreeView control. I’ll update the CodeProject article once the current filtering mechanism has been rewritten:ĭownload: wpf-treeview.zip (Current version: 1.0.7, updated 2008.04.06) Update: The latest version is currently only available through the download link below. And please leave your rating if you like the control □ Ooh well, the MouseUtilties class Josh created is a good solution, but I sure hope Microsoft is going to fix this problem in the next version of WPF.A tutorial is now available on Code Project, so check the article for a detailed overview. However what I don' t understand at this point is why WPF doesn' t fire the MouseMove event anymore when you are performing a drag-drop operation. It' s pretty logical that Microsoft didn' t include the method GetItemAtLocation in the treeview, because that would pretty much break the whole idea of having a separate visual tree. Object dataObject = (hitTestResults.VisualHit as If(hitTestResults.VisualHit is FrameworkElement) HitTestResult hitTestResults = VisualTreeHelper.HitTest(treeView,location) The code to get a visual from the current mouse location is shown below. Depending on how you configured the DataContext, you will get the item that is bound to the element, in my case a task. This proved to be really helpful, because now you can cast it to something a bit more meaninful and extract the DataContext from there. ![]() This can be anything, from a TextBlock element to a Border element or even controls you didn' t creat but were added during runtime by WPF itself. I discovered that if you do a VisualTreeHelper.HitTest(reference,location) call, a visual gets returned that represents the control you clicked on. ![]() Code to move the item in the model is placed here. Task targetTask = GetItemAtLocation(MouseUtilities.GetMousePosition()) Task sourceTask = (Task)e.Data.GetData(typeof(Task)) void treeView_Drop(object sender,DragEventArgs e) Because WPF has a separated visual tree, this can' t be done using normal methods. In this eventhandler I had another problem, how to get the target item to drop the source item on. This is done by moving the dragged item to another position in the tree and setting the isDragging flag to false again, so that the user can issue another drag-drop movement. Last you need to finish the drag-drop movement in the Drop eventhandler. The code here will look something like this: void treeView_DragOver(object sender,DragEventArgs e) Next you need to check if the user is doing the correct thing in the DragOver eventhandler, you can manipulate the behaviour of the drag-drop movement by setting the Effects property of the passed DragEventArgs object. This issues the drag-drop movement and ensures that the user can' t start the same operation a second time. If(!_isDragging & e.LeftButton = MouseButtonState.Pressed)ĭragDrop.DoDragDrop(treeView,treeView.SelectedValue, In the MouseMove eventhandler you have to add code similar to the following snippet: void treeView_MouseMove(object sender,MouseEventArgs e) It' s as simple as implementing three eventhandlers: MouseMove, DragOver and Drop. Appearantly I wasn' t the only person who noticed this weird behaviour, because Josh Smith tried to do something similar and had to write a wrapper for the Win32 mouse api to get the correct result.Īfter using this utility I had the whole thing working pretty quickly. ![]() I tried different variations on this, but to no avail. When you issue a DragDrop.DoDragDrop operation within a mousemove eventhandler, the mousemove event no longer gets fired, until you drop the item. As it turns out there' s a problem with the mouse eventhandling. However, getting items dragged from one point in the tree to another point in the tree is a whole different story. Creating the basic structure was rather pleasing work to do because setting up databinding and getting the items to render correctly is a breeze with the new layout and databinding capabilities. Last week I was trying to get a drag and drop treeview to work in WPF. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |