sorry for the late reply, I was too busy on other fronts. I'll follow your unordered thread in my answer.
Thanks for the link to the HowTo section, somehow I've missed it the first time round.
On why moving to the new DragDropManager, I don't really know what the previous limitation were, but I don't need long explanations on this, of course you had good reasons, I'm sure of it and I'm not being sarcastic.
After carefully reading the provided information about your scenario I think that I understand the big picture of your application. As far as I understand, you use CSLA object which is exposing a boolean IsDeleted flag. If this flag is set to true for any business item, it is deleted from your database. Your issue is that somehow this flag is automatically set to true after the migration.
this is all 100% correct! The following bit confuses me though:
Basically, when we changed the default setting of the RadTreeView control we expected that customers will complain about custom code that is not being triggered. Your issue may be caused just by that. If you have implemented custom drag drop logic in any handler of the old manager's events, this logic will not be triggered now. If any of your custom logic for handling the CSLA object is not triggered the IsDeleted flag may be automatically set. Please keep in mind that we do not provide support for CSLA objects out of the box. This is why it is up to you to properly handle those objects.
You may be onto something here, but if you are you've lost me. What I was trying to explain above looks in conflict to what you are telling me now.
The story goes like this:
1) I update our project so to use Q2 2014
2) we notice that drag and drop within a treeview was looking OK on the client, but changes were not saved. In another context, drag and drop from the tree into another control (also a treeview) was not working, and actually deleting the dragged elements on server side (Bad!).
3) From there, finding out that our "custom code" was not being called was easy.
4) First attempt to resolve the issue was by following the suggested route. Ditch the old way of handling drag/drop events and use the new way. I was able to do so (and I've kept the code), our custom code was now executed, and the only changes that seemed to be necessary had to do with how to access the relevant objects (dragged object, target object and so forth). All looked fine for a very short time.
5) It all became worrying again when I noticed that more often that not, the (dragged) object had the "isDeleted" flag set to true. This is automatically handled by CSLA, and is read only, I can't simply check if the value is right and change it when necessary. The result is that we can drag and drop, send the relative commands to the server to send the changes, and it all works. But while all this happens the CSLA framework also sends the "deleted" object back (it all works asynchronously) and eventually the dragged object gets deleted.
Hence my original question: do you have any idea of why dragging what is a silverlight control may impact the particular "IsDeleted" CSLA field in the underlying data-object. I am guessing some binding trickery is at play, and since this is the direct consequence of Telerik changes, I'm asking my question here (guessing that the CSLA folk will not be able to help).
What your answer may suggest is that the flag gets changed because we are not subscribing to some event, which is then handled in the telerik default way, and that something that happens there may be interpreted by CSLA as a good reason to believe the data object should be deleted. This is not impossible, but I'm stretching your words, so I may be completely off the mark.
As per your specific question, I can tell you that the code I've wrote for my point 4) above was handling one and one only event, I've tried a few alternatives, but with no luck. The code I've posted names the RadTreeViewDragEndedEventHandler but I'm happy to use another event, if that will solve the issue and allow us to react properly.
What we need to achieve is allow users to drag and drop tree-branches as they may see fit. As the tree structures we handle can be quite big, this is very useful for our users. At the business logic level, this requires to change the following:
on the "moving" node, change the value of "parentID" (identifies what data-object contains the current one) and change the "order" field, so to know where in the list of same-level objects (siblings) it should be.
on the old siblings of the object, decrease the "order" value of the ones that came after the moved object, so to fill the missing place and leave no gaps.
on the new siblings, increase the "order" values of the ones that now come after the moved object.
On the old parent object, remove the moved object from the list of its children. On the receiving object, add the moved object to the list.
What happens in the handler can be summarised in this way: 1st, the "Order" field of the data-objects associated with the affected nodes in the tree gets an update on client side (instructing CSLA that changes should not be propagated); the ParentID field of the dragged object is updated locally. All the other changes I mention above happen in the same way (they don't get individually saved to the server).
2nd, a CSLA command is sent back to the server, containing the required information (what data object was moved, where it was, where it is now) so that exactly the same changes can be independently saved on server side. This seemed like a good idea to avoid triggering a lot of chit-chat between client and server, as otherwise all affected object would do a round trip to the server on their own.
3rd, the command sends back to client a "success" or "error" message, the client is listening and will show an error if the commit operation failed, otherwise we'll know our data was saved successfully.
All of the above works perfectly with the old event-handling system, handling the TreeView.PreviewDragEnded event alone. As far as I can tell, we don't subscribe to other events. Also: if my analysis is right, the only problem with the new system is the "isDeleted" flag, if it wasn't for that, it would be working just as well.
I hope this clarifies, thanks so much for your assistance!