We just fixed a difficult to diagnose case where GoDiagram was tossing an exception when dragging a custom container object. For this object of course we construct our own selection. It seems to be the case that when a hidden GoBalloon is included in a selection on start drag, GoToolDragging.Start() (invoked from GoView.Tool setter on mouse move) throws a null ref exception, but not having source code we could only guess. Is this the case, or was there another reason that removing this object from the selection fixed the problem.
What was the top GoDiagram method on the call stack at the time of the exception? GoToolDragging.Start doesn’t do too much that’s complicated besides call DoDragDrop. DoDragDrop initiates the drag-and-drop, so there could be all kinds of opportunities for exceptions during the drag before the call to DoDragDrop returns.
Is there any other relevant information you could provide?
I did save off the call stack contents, which was:
Northwoods.Go.GoToolDragging.Start()
Northwoods.Go.GoView.set_Tool(GoTool value)Northwoods.Go.GoToolManager.DoMouseMove Northwoods.Go.GoView.DoMouseMove
Northwoods.Go.GoView.OnMouseMove
System.Windows.Forms.Control.WmMouseMove
… etc.
My bad though. I thought that I had located all my event handling code prior to the exception, but before I posted this reply I had another idea of where to look, and I found the culprit – the selection was erroneously getting cleared. Apparently some code does not handle an empty selection. Probably mine of course, but I can’t find it.
I’m not familiar with what your application is doing, of course. But typically when what you want to drag is different from what is selected, the responsible method for deciding what is really going to be dragged is GoToolDragging.ComputeEffectiveSelection. If you want to remove balloons from the collection to be moved or copied, then you ought to override this method. Call the base method and then adjust the resulting collection, which should always be a new GoSelection object with no View.
I could imagine that there would be odd behavior if the actual GoView.Selection is being modified during a drag. We are pretty careful about dealing with empty selections and all kinds of weird state (never can be too careful when programmers can override all kinds of methods!), but maybe we missed a case.