You’re using WPF, right? And your application is running with the permissions for using real Windows drag-and-drop, right?
There are the standard UIElement.Drag… events. There are no Diagram-specific events during the external drag.
The Node that is created in the target Diagram is based on the node data that has been (temporarily) added to the model. If your “visible” string is data-bound to your node data, perhaps you can make sure the newly created data has the string value you want.
For example, if you show the node Key in your Node DataTemplate, you’ll see that the Node being dragged in the target Diagram will have a unique Key value, which may be different than the source data Key value.
DraggingTool.CopiedParts shouldn’t be null during the call to DraggingTool.DropOnto for an external Windows drag-and-drop.
DraggingTool.DragOverPart may or may not be null, depending on where the mouse pointer is at the time of the drop. Recently we fixed a fixed a bug where if the mouse changed what Part was being dropped onto, it didn’t update the DragOverPart property. (It did drop onto the correct Part, it just didn’t update the DragOverPart property until the end when it sets DragOverPart to null.) I don’t remember off hand whether that fix is in the latest baselevel or not. But the point is that that property should be null after the DropOnto method completes.
In a successful external drop, Diagram.SelectedPart should be non-null in a Diagram.ExternalObjectsDropped event handler. However, CopiedParts and DraggedParts should be null by that time.
So if CopiedParts is null during DropOnto, and if SelectedPart is null in the ExternalObjectsDropped event handler, is drag-and-drop working at all for you?