We have recently updated the GoXam WPF to 3.0 version, but we’ve been using the controls for quite a long time. We’ve noticed a problem that occasionally occurs and we cannot intentionally replicate. We have Subgraph nodes that should act as parents to the nodes contained within them. Sometimes, the child nodes would get links to more than one parent, as two different Subgraph nodes would have references to the same child node within the MemberKeys property. The Subgraph nodes are not and should not be linked to each other.
We haven’t figured out when this bug occurs, we’ve tried replicating it but none of the actions have resulted in the same issue. We are wondering if someone has noticed a similar behavior, and possibly found a solution to it?
Are you saying that this is a new problem with GoXam 3.0, or that it has happened occasionally for many years?
Does this problem happen upon an initial load of model, or only after changing some memberships?
Does an undo have to happen in order to cause the problem?
Hi, this has been a problem for a long time, even before we’ve upgraded to the new version of the controls. The upgrade hasn’t solved the problem, so I think it might still be present.
We discovered yesterday that the problem occurred when a user selected a bunch of nodes (including Subgraphs and their child nodes) and copied and pasted the bunch in the same diagram page. It doesn’t happen every time, but there is a high chance the issue will occur. We usually do not notice it immediately, but after saving and reloading the model afterwards.
What happens (most probably) is the following: before the copy-paste the diagram page has some Subgraph nodes with references to the “child” nodes in the MemeberKeys; some of the referred child keys (and the matching nodes) are actually not present at the diagram page anymore, but the Subgraph node is not aware of that. Then, the copy-paste generates new keys for the newly added nodes, and some of these nodes (the child nodes of the copied SubGraph nodes) get the same Key values as some of the missing Keys from the above Subgraph nodes. And then we have a child node whose key appears as a Member key of two Subgraph nodes (one that already has this as a member key, and the other one that was generated upon copy-paste).
It’s a concern that there is some non-temporary inconsistency – that there are keys in the GraphLinksModelNodeData.MemberKeys list that do not refer to existing node data in the model. How did you get to such a state?
Hi,
I finally have a specific scenario of steps that can illustrate the problem we’ve been facing.
It is a combination of nodes’ creation, their copy-pasting in the same diagram page, and later reorganization in the page.
Our users frequently use copy-paste option to create new nodes on the page. So, they copy a group and its sub-nodes and paste them on the same page. They also drag and drop various nodes, moving them from one logic group to the other, thus changing their parent along the way.
What I have discovered is that LogicGroup serialization into XML is not working as expected in certain scenarios.
I’ll try to explain the scenario:
-
A new logic group is created (Key = “lg 1”) from the palette and two shapes are added to it (“rl 1” and “rl 2”), also from palette.
If we serialize this into XML, the Logic group won’t have any KeyMembers in its definition. Nodes rl 1 and rl 2 indicate that their subgraph is lg 1. When loading the model everything works fine. -
Load the model from XML.
Next, we select all three nodes from the above and copy-paste them to the same diagram page (“lg 2”, “rl 3”, and “rl 4” nodes are created).
Now, the serialization into XML will have the following:
lg 1 won’t have any KeyMembers; nodes rl 1 and rl 2 indicate that their subgraph is lg 1.
lg 2 has key members rl 3 and rl 4; nodes rl 3 and rl 4 indicate that their subgraph is lg 2.
When loading the model everything works fine. -
Load the model from XML.
Again, copy-paste either of the two logic groups and its subnodes (“lg 3”, “rl 5”, and “rl 6” nodes are created).
Now, the serialization into XML will have the following:
lg 1 won’t have any KeyMembers; nodes rl 1 and rl 2 indicate that their subgraph is lg 1.
lg 2 has key members rl 3 and rl 4; nodes rl 3 and rl 4 indicate that their subgraph is lg 2.
lg 3 has key members rl 5 and rl 6; nodes rl 5 and rl 6 indicate that their subgraph is lg 3.
When loading the model everything works fine. -
Load the model from XML.
Drag the node rl 3 and move it and drop it in the logic group lg 3; make sure the logic group “snaps” the node.
Now, the serialization into XML will have the following:
lg 1 won’t have any KeyMembers; nodes rl 1 and rl 2 indicate that their subgraph is lg 1.
lg 2 has key members rl 3 and rl 4; node rl 4 indicates that its subgraph is lg 2.
lg 3 has key members rl 5 and rl 6; nodes rl 3, rl 5 and rl 6 indicate that their subgraph is lg 3.
When loading the model, node rl 3 behaves as if it doesn’t belong to any logic group.
I have tried manually swapping the order of nodes in the XML for the nodes lg 2 and lg 3, so that the lg 3 is loaded before the lg 2; in this case the mode rl 3 behaves as it’s supposed to - as if it’s a part of the lg 3 logic group.
Removing the MemberKeys from the XML solves the problem for us, as all the nodes behave as they are supposed to when the XML is de-serialized into a model.
Now, I’ve seen situations when in XML two logic group nodes have the same node Key listed in the MemberKeys; I haven’t figured out how this occurs, but I think it has something to do with the copy-paste operations, and order of nodes’ creation and later reorganization (drag-dropping the nodes from one logic group into the other).
Hmmm, there appears to be some inconsistency regarding the use of the MemberKeys property. Try setting GraphLinksModel.MemberNodesPath to the empty string. For example:
myDiagram.Model = new GraphLinksModel<NodeData, String, String, LinkData>() {
MemberNodesPath = "", NodesSource = nodeData, LinksSource = linkData, Modifiable=true, HasUndoManager=true
};