Drag and Drop issue with GoDiagram 2.6.2.2

We have recently upgraded from version 2.4.1.1 to 2.6.2.2 and have encountered a drag/drop problem when using the new version.

We have a Systems.Windows.Forms.TreeView from which we are dragging a Systems.Windows.Forms.TreeNode onto our GoView.
Here are the GoView methods we have overridden pertaining to drag/drop:
DoExternalDrag() - there is 1 particular case where we set evt.Effect to DragDropEffects.None. Otherwise, the value is always DragDropEffects.Copy.
GetExternalDragImage() - we create a GoIconicNode (with a GoImage icon and a GoText label) which is returned to be used as the drag image.
DoExternalDrop() - we create one or more GoIconicNodes (based on what was dropped) and add them to the GoView's document.
-----------------------------
With GoDiagram 2.4.1.1, everything works correctly.
With GoDiagram 2.6.2.2, the problem we have is that, while dragging over the view, we see the correct drag image but the mouse pointer becomes the nodrop cursor (circle with a slash). So, you simultaneously see the drag image and the nodrop mouse cursor.
I have added debug statements to output the value of evt.Effect just before the return from DoExternalDrag() and GetExternalDragImage(), and the value is DragDropEffects.Copy (as I believe it should be).
In these same debug output statements, I also write out the value of GoView.CanInsertObjects(), and it is true.
I do not have event handlers for DragOver or DragEnter on the GoView or on any object that is on the view's document.
I have swapped out GoDiagram 2.4.1.1 and 2.6.2.2 a couple of times to prove that it is a problem with the new version. It always works in 2.4.1.1. It always does not work in 2.6.2.2.
Are there any new properties in 2.6.2.2 that I need to be aware of? Does 2.6.2.2 have different default settings or something that I'm not aware of?
Thanks in advance,
-Darren Jones
So, just to confirm, your code to set Effect to DragDropEffects.None is never executing, right?
There was a related bug fix or two in 2.5. I'll need to investigate if the bug fix(es) might have introduced some other problem.
fixed cursor to show "no drop" for external drag when setting DragEventArgs.Effect to DragDropEffects.None if GoView.ExternalDragDropsOnEnter is true
fixed forced copy (control-drag) not to leave original dropped selection when GoView.ExternalDragDropsOnEnter is true

OK, I just tried a scenario with your three overrides when dragging from a TreeView, and everything works fine.

Obviously GetExternalDragImage is working for you. When the user does a drop, is the drop actually happening? In other words, was the Effect set to None? Or is GoView.DoExternalDrop not being called?
> So, just to confirm, your code to set Effect to DragDropEffects.None is never executing, right?
Correct. For the test case I am trying, my code never sets Effect to None. My debug output statements also confirmed the value is Copy, just before the "return" from DoExternalDrag() and GetExternalDragImage().
Also, I am not explicitly setting the value, but in debug I checked and the value of GoView.ExternalDragDropsOnEnter is false.
> Obviously GetExternalDragImage is working for you.
Yes, it appears that GetExternalDragImage() is being called before DoExternalDrag(). It does successfully create my drag image.
> When the user does a drop, is the drop actually happening? In other words, was the Effect set to None? Or is GoView.DoExternalDrop not being called?
No, the drop does not happen. DoExternalDrop() is never called. I set a breakpoint there as well as added debug output statements to it and it is never reached.
From my debug output statements in DoExternalDrag and GetExternalDragImage, the value of Effect is still Copy upon exiting these methods. Is there some other method from which I should check the value of evt.Effect?
The interesting thing is that we have 2 sources from which we can drag items. One is the System.Windows.Forms.TreeView from which we drag TreeNodes -- this is the one where we have the problem.
The other source from which we drag items is a Syncfusion.Windows.Forms.Tools.GroupView, from which we drag a GroupViewItem (Syncfusion is another 3rd party vendor we use). Dragging these items still works in 2.6.2.2.
I've tried to figure out what is different between dragging from these 2 different sources, and I've tried to eliminate as many differences as possible but still have the issue.
Thanks again for your help,
-Darren

So DoExternalDrop is never called?

I wonder what else might be different from what I just tried.
Had you also switched to .NET 2.0 at this time?
Here's what I did, starting with the ProtoApp sample application, adding the following overrides to GraphView.cs:
[code] protected override void DoExternalDrag(DragEventArgs evt) {
base.DoExternalDrag(evt); // also do standard behavior
GoObject over = PickObject(true, false, this.LastInput.DocPoint, true);
if (over is GraphNode) evt.Effect = DragDropEffects.None;
}
protected override GoObject GetExternalDragImage(DragEventArgs evt) {
IDataObject data = evt.Data;
Object treenodeobj = data.GetData(typeof(TreeNode));
if (treenodeobj is TreeNode) {
TreeNode treenode = (TreeNode)treenodeobj;
GoObject tag = treenode.Tag as GoObject;
if (tag != null) {
return tag;
}
}
return base.GetExternalDragImage(evt);
}[/code]
Try this and see if this modified ProtoApp works for you.

So DoExternalDrop is never called?

Correct
> I wonder what else might be different from what I just tried.
Had you also switched to .NET 2.0 at this time?
Yes, when I use GoDiagram 2.4.1.1 with Visual Studio 2005 (.NET 2.0) it works. When I use GoDiagram 2.6.2.2 in the exact same environment it does not work. To switch, I just removed the reference to 2.4.1.1, added a reference to 2.6.2.2, and updated my licences.licx.
> Here's what I did, starting with the ProtoApp sample application, adding the following overrides to GraphView.cs:
I'll give it a try and let you know.
> Here's what I did, starting with the ProtoApp sample application, adding the following overrides to GraphView.cs:
> Try this and see if this modified ProtoApp works for you.
I copied and pasted the 2 overrides from your post into ProtoApp, and now I get the nodrop cursor (with no drag image).
I added some debug output statements to those methods, and for some reason, evt.Effect was already set to None upon entering GetExternalDragImage(). I made a change to explicitly set it to Copy, but this made no difference in behavior. I still get the nodrop cursor and the drop does not occur.

OK, this is weird. Are you able to drag the Start, Stop, or Comment TreeView items to a GoView?

But the regular items don't drag-and-drop.
I don't know of any meaningful differences between the two categories. More investigation needed.
To experiment further you could also try commenting out one or both override method bodies, keeping the base call, of course.

Ah, OK, everything works fine, if in the override of GetExternalDragImage we make a Copy() of the object, instead of re-using the same object each time.

if (tag != null) return tag.Copy();
I don't know why that would be different for those kinds of nodes, but that's something specific to the ProtoApp sample application.
The basic mechanisms -- overrides of those three GoView methods -- work fine.
So in your application, perhaps there is some sort of inadvertant error in your GetExternalDragImage code -- including in the value that it returns -- that causes an exception that is treated as a "can't-drop-here" effect by the rest of the GoView code that handles drag-and-drop.
I think you're right that the bug fixes that I mentioned earlier are not relevant here, since you do not have GoView.ExternalDragDropsOnEnter set to true.

Ah, OK, everything works fine, if in the override of GetExternalDragImage we make a Copy() of the object, instead of re-using the same object each time.

> if (tag != null) return tag.Copy();
I made this change and the ProtoApp does indeed work for me now.
> So in your application, perhaps there is some sort of inadvertant error in your GetExternalDragImage code -- including in the value that it returns -- that causes an exception that is treated as a "can't-drop-here" effect by the rest of the GoView code that handles drag-and-drop.
This does not seem to be true.
In my application, I have now commented out the overrides for GetExternalDragImage() and DoExternalDrag(). I still get the nodrop mouse cursor (with no drag image, obviously) when dragging a TreeNode, and DoExternalDrop() is never called.
When dragging a Syncfusion GroupViewItem the drop still works.
I feel like there is something simple that is missing. As far as I know now, the only override that I have that is related to drag/drop is DoExternalDrop(), and this method is never even called for the case that does not work.
The drag/drop works in all cases when I use GoDiagram 2.4.1.1, just not with 2.6.2.2.
I can try with other versions of GoDiagram in between (2.4.1.2, 2.5.x, ?) if that would help narrow down the issue.

I’ll diff our sources to see if I can guess what the problem might be.

I just tested 2.4.1.2 and it works correctly.

Just tested 2.5.1.2 and it also works correctly. So far I only have the problem with 2.6.2.2.
One interesting side note: I didn’t use the 2.5.1 License Manager before testing (and I’ve never installed 2.5 before), but I noticed that I didn’t have the eval watermark on the GoView. So, after testing I opened the 2.5 License Manager and it said that I had a binary development license for Go (not eval). Does it automatically assume I am licensed for 2.5 because I am licensed for 2.6, without having to enter a specific 2.5 unlock code?

Tested 2.6.1.2 and it does not work.

Tested 2.5.2.2 and it does work.

So, it seems that 2.5.2.2 is the last version that worked, and 2.6.1.2 is the first version that did not work (unless there are some versions in between that I missed).

Wow, thanks for trying all those different versions.

In diff'ing the sources for GoView between 2.5.2 and 2.6.1, there's hardly any relevant change.
GoView.DoExternalDrag now sets the Effect to DragDropEffects.Copy when CanInsertObjects() is true; it used to set the Effect to DragDropEffects.All. This certainly could be an issue, but according to what you have said, I believe this is not the issue in your application.
GoView.GetExternalDragImage and DoExternalDrop now check for up to two different data formats in DragEventArgs.Data. Originally it only looked for the GoSelection type; now it also looks at the type of GoView.Selection if the first lookup fails (this is to support customized GoSelection). This is unlikely to be an issue in your application.
I'll see if I can do more experimentation to figure out why the change to ProtoApp only partly worked, since that might provide a clue. But if I recall correctly, it had the same behavior in 2.4.1 as in 2.6.2, so this might not be the most likely to be fruitful course of investigation.

But if I recall correctly, it had the same behavior in 2.4.1 as in 2.6.2, so this might not be the most likely to be fruitful course of investigation.

Yes, I saw the same thing in ProtoApp. With both 2.4.1 and 2.6.2, it did not work unless I returned Tag.Copy() rather than Tag.
----------------------
Here's a thought. Is it possible for you to send me the 2.5.2 source code for GetExternalDragImage() and DoExternalDrag()?
I could try using the 2.6.2 dll, but putting in the 2.5.2 version of those 2 methods in as an override (and not call the base 2.6.2 version). That way, we'd be able to see if the problem was definitely in one of those 2 methods, and I could even narrow down which of the methods it was in.
But I understand if you're not allowed to send the source for them because of licensing issues.
Thanks,
-Darren

I’d be happy to give you those sources. But I don’t see why that would change anything, since you said that whether or not there was an override didn’t change the behavior. Hmmm, well, that’s true for GetExternalDragImage. But not for DoExternalDrag, since you do call the base method when the override is defined.
They’re on the way…

I’d be happy to give you those sources. But I don’t see why that would change anything, since you said that whether or not there was an override didn’t change the behavior. Hmmm, well, that’s true for GetExternalDragImage. But not for DoExternalDrag, since you do call the base method when the override is defined.

Well, what I'm saying is that in my current implementation, I have totally commented out my overrides for GetExternalDragImage() and DoExternalDrag(), and I still have the problem (DoExternalDrop() is never called).
I am hopeful that if I put in the 2.5.2 implementations of those 2 methods as a complete override of the 2.6.2 base (no call to the base), that it will start working. That would prove that the problem is in the 2.6.2 implementation for one of those 2 methods.
If it does not work, even though I'm using the 2.5.2 source for those 2 methods, then the problem is elsewhere.
I just received the email, so I will let you know the results of my test.
Thanks,
-Darren