Hi
{
public MyNode()
{
}
}
{
public MyLinkData()
{
}
ctlDiagram.Model = model;
Key = m.Key,
Text = m.Name,
Location = e.Options.RelativeDragPoint
});
Hi
I cannot explain that with the information I have.
When I diff the sources between 1.2.6 and 1.3.3, the only difference in the GraphLinksModel and …NodeData and …LinkData files is the change relating to Guids, as documented in the release notes.
(Well, there are also changes in the comments, including doc strings, but never mind those.)
Is this for Silverlight or for WPF? I ask because the built-in drag-and-drop support is different for the two platforms.
Are you using a GoXam Palette control or something of your own construction? I’m guessing it’s the latter, because one doesn’t normally need to write code to handle drops that are dragged from a Palette.
Thanks for the response and sorry for not being clearer.
I just tried this, using GoSilverlight 1.3.3.5 with Silverlight 5.
First I modified the GoSilverlightBasic demo app so that the model use “int” instead of “string” as the node key type. As expected, drag-and-drop from the Palette still worked just fine.
Then I modified the NodeMenuClick method to insert a copy of the data into the main diagram:
var data = ((PartManager.PartBinding)elt.DataContext).Data as MyNodeData;
//MessageBox.Show("Node color: " + data.Color);
myDiagram.StartTransaction("insert");
myDiagram.Model.AddNode(data.Clone());
myDiagram.CommitTransaction("insert");
When repeatedly executing this context menu command on a node in the palette, this also worked fine, without any exception and properly assigning new keys to the added node data.
So I do not understand how your situation is different from the one I just described.
Please note that I’m using 1.3.2.5
I tried your code, and as you say it failed with 1.3.2.5. But it also failed with 1.2.6.4.
I changed the code to use “int” instead of “long”, and it worked with not only 1.2.6.4 but 1.3.2.5 and 1.3.3.5 also.
So I think the problem is the use of “long” instead of “int”, not a change between 1.2 and 1.3.
GoXam models only know how to make string, int, and Guid type node keys unique.
But you can easily implement what you want by overriding MakeNodeKeyUnique.
Thanks Walter, you are correct, it’s a long issue.
Well, the data type should matter to the code that makes use of the property, so that it can compile.
And it only gets modified when the node data is added to the model, because only at that time is there any context in which uniqueness would make any sense. That assumes, of course that the key value isn’t modified out from under the model. Not much we could do if that happens.