I’m not sure that I fully understand your scenario. The drag and drop code is attaching handlers for the preview mouse events with the assumption that during a drag drop operation, we don’t want mouse events to affect anything else in the app. If you need to detach the preview mouse events temporarily in your app, you can use the standard event syntax:

element.PreviewMouseLeftButtonDown -= MyElement_PreviewMouseLeftButtonDown;

And to re-attach it, you can do the same thing with +=.

Bea

FYI: I have updated the source code of this post with a fix for the issue you encountered.

Bea

I have used this generic approach for our application and now the list items are becoming richer and richer…. to the extent that we have an AdornerDecorator which can be made visibleon occasions as part of the list item. The AdornerDecorator can contain other controls… and what I have noticed is that controls that rely on drag and drop themselves [e.g dragging a scroll bar, or drag -resizing a grid column] do not get an opportunity to handle their drag events before the DragDropHelper takes over…

Hope this makes sense.

Is there some way of making such an Adornerdecorator not allow the PreviewMouseDown, PreviewMouseMove etc to block these events temporarily?

Thanks for any insight you can give.

Derek

The code assumes that if the mouse is over a ListViewItem, it will figure out a way to insert the item before or after the hovered item. If it’s not, then it inserts the item at the end of the list. The problem you see (which I can repro) is that the default style for ListViewItem introduces a 1 px margin around it, so when you’re hovering that 1 px area, you’re not really over a ListViewItem.

One solution to this problem is to remove the margin from the ListViewItem. This can be easily done by adding a style to ListViewItem that sets its margin to 0.

<Style TargetType=”{x:Type ListViewItem}” x:Key=”ListViewItemStyle”>
<Setter Property=”Margin” Value=”0″/>
</Style>

<ListView ItemContainerStyle=”{StaticResource ListViewItemStyle}” …

If you want that 1px space to remain for aesthetical reasons, instead of a margin you can add it as padding, or a border.

Hope this helps.
Bea

Yeah, the fact that selection gets messed up when adding the same item twice to a ListBox is a well known and much discussed issue. When I was still on the team, we often talked about how common of a scenario that is, the priority of fixing it, and how we should fix it. Somehow the team never actually shipped a solution to that issue.

Your solution is good. Another alternative is to wrap the data items in containers. This way, even though the actual items may not be unique, the containers are.

Thanks for posting your solution! I’m sure it will be useful to others.

Bea

Yep, I can repro what you describe (you can see my code in this project), and understand what is going on.

The code in “GetItemContainer” first gets the type of container for the ItemsControl, which in this case is ContentPresenter. Then it walks up the visual tree, starting from the bottom-most element clicked (in this case, the Label), until it finds the first element of type ContentPresenter. Then it checks that the ContentPresenter found is in fact a container of the ItemsControl passed as a parameter. This is where things go wrong. The problem is that Label’s default template contains a ContentPresenter, and this one is encountered first when walking up the tree. So the code failes when verifying that it is a container of the ItemsControl.

There are a few ways in which the code can be fixed:

- You can use a TextBlock instead of a Label.

- You can modify the code in “GetItemContainer”. Here’s the code that checks whether the container belongs to the ItemsControl (the comparison that fails in your scenario):

FrameworkElement itemContainerVerify = itemsControl.ItemContainerGenerator.ContainerFromItem(itemContainer.DataContext) as FrameworkElement;
if (itemContainer != itemContainerVerify)
{
itemContainer = null;
}

If the verification that the container belongs to the ItemsControl fails, you can continue walking up the tree looking for the next container of the same type, and repeat the comparison. This would be done until the container in fact belongs to the ItemsControl or the tree walk reaches the top window.

Let me know if this makes sense.

Thanks,
Bea

i get into troubles when i have to drag the same object multiple times into the same drop target. The underlying listbox can’t make differences between the items and selected them all.

To fix this i used die IClonable Interface in your InsertItemInItemsControl. Hope this can help someone else.

if (itemToInsert != null)
{
IEnumerable itemsSource = itemsControl.ItemsSource;

if (itemsSource == null)
{
itemsControl.Items.Insert(insertionIndex, itemToInsert);
}
// Is the ItemsSource IList or IList? If so, insert the dragged item in the list.
else if (itemsSource is IList)
{
/* New */
if (itemToInsert is ICloneable)
{
object copy = ((ICloneable)itemToInsert).Clone();
((IList)itemsSource).Insert(insertionIndex, copy);
}
else
{
((IList)itemsSource).Insert(insertionIndex, itemToInsert);
}/* New end */
}
else
{
Type type = itemsSource.GetType();
Type genericIListType = type.GetInterface(“IList`1″);
if (genericIListType != null)
{
type.GetMethod(“Insert”).Invoke(itemsSource, new object[] { insertionIndex, itemToInsert });
}
}
}

with kind regards
daniel

Bea