DragDrop move method in tree view

[owenwengerd]

I tested your latest sample and it works as expected even though you are deleting the source item from within the drop handler. I'm not sure why you get different results.

[Fred Tomke]

I tested your latest sample and it works as expected even though you are deleting the source item from within the drop handler. I'm not sure why you get different results.

Yes, you are right: I've justed this sample on AutoCAD Map 2010 x64 on Win7 x64. There is a significant difference to AutoCAD Civil 3D 2009 on WinXP x86 and Map 2010 x64 on Vista x64: Only on Windows 7 x64 the dragged item will be kept. I would backtrack this topic if the way it works on Win7 x64 it also works on Windows XP and Windows Vista.  ;)

Other question towards this: you wrote

2) If the return value is <MOVE>, delete the source item.

Would it be possible to extend the if condition for the case the event handler DragDropFromControl ist active?
= 2) If the return value is <MOVE> and the eventhandler name <> "", then delete the source item.

Just a thought.

Fred

[owenwengerd]

The AddSibling function should fail when it is called after the target key has already been deleted, but for some reason it works anyway in AutoCAD 2010. I tested in AutoCAD 2004, and the AddSibling function fails there as I would expect. I was going to suggest simply removing the calls to DeleteItem, but this presents a different problem: AddSibling fails in that case because the item key would be a duplicate.

To address the problem, I have made some changes for the next build so that DeleteItem within the drop handler works as you expected, and the source item correctly recognizes that it has already been deleted. I think this will resolve the problem and allow your latest sample to work the way you want.

Would it be possible to extend the if condition for the case the event handler DragDropFromControl ist active?
= 2) If the return value is <MOVE> and the eventhandler name <> "", then delete the source item.

In addition to the problem that I explained in the previous post, the source object would have no way of knowing where it was dropped, and so it would have no independent way of determining whether the event handler existed at the drop point. In any case, I thinkthe problem is now resolved.

[Fred Tomke]

The AddSibling function should fail when it is called after the target key has already been deleted.

Hm, I cannot see where I should have deleted the target item. I my code I have deleted the dragged item. Of course, AddSibling must fail if the target item was deleted before.

However, thanks Owen for your patience. I am looking forward to test the new release.

Fred

[owenwengerd]

I should have said "source item" instead of "target key".

[awybo]

Hi Owen, Hi Fred,

I've followed your dialog here and have gone through the code that has been posted because I am also trying to build a tree where I can re-order, or, 'move' items around without nesting them. Seeing as this thread is quite old, I'm wondering if there is some 'new' way to achieve this behaviour in release 7?

Otherwise, the problem that I am facing right now is that I have a tree of items where the parents have keys but the children do not. The DropPoint variable of OnDragnDropFromControl is useful when the item has a key, but, when it doesn't, instead of getting the item's handle DropPoint becomes an entity name and I'm not sure how to use that information to do anything useful like add a sibling. Is this a bug? I was expecting a handle if the tree item doesn't have a key.

Thanks for taking a look at this entry.

[owenwengerd]

The "entity name" is not an entity name -- it is the item handle.