Hi,

The order or child nodes in layouts such as TreeLayout or FlowchartLayout depends on the order of links in the parent's OutgoingLinks collection. So instead of recreating links, try connecting the existing ones to the new node. That should ensure the link order in the neighbor nodes collections won't change. I haven't tried the code, but this should do the trick:

void ReplaceNode(DiagramNode oldNode, DiagramNode newNode)
{
	DiagramLinkCollection inLinks = oldNode.IncomingLinks.Clone();
	DiagramLinkCollection outLinks = oldNode.OutgoingLinks.Clone();
	foreach (DiagramLink link in inLinks)
		link.Destination = newNode;
	foreach (DiagramLink link in outLinks)
		link.Origin = newNode;
	diagram.Items.Remove(oldNode);
} 

I hope that helps,
Stoyan

Hi Rich,

If I understand the LayeredLayout code correctly, it depends more on the initial order of nodes within Diagram.Nodes collection than on links' order. LayeredLayout first assigns nodes to layers according to StartNode,EndNode,EnforceLinkFlow and/or EnableCustomLayers properties, where nodes in a layer are initially added in the same order as they have in diagram.Nodes. Then the layers are rearranged in a way that minimizes link crossings between nodes in adjacent layers. So I think in this case you should try placing the new node at the same position within diagram.Nodes. E.g. try saving the Nodes.IndexOf(oldNode) value, add the new node, then offset nodes in a loop:

for (int i = diagram.Nodes.Count - 1; i > oldNodeIndex; i--)
  diagram.Nodes[i] = diagram.Nodes[i - 1];
diagram.Nodes[oldNodeIndex] = newNode; 

LayeredLayout might be depending on the links order too, so you should probably still use the ReplaceChild method above to preserve the links order.

You might also consider using the same node object but replacing its content. E.g. if your diagram uses ControlNodes, just replace ControlNode.Control instead of creating a new node to host the control.

I hope that helps,
Stoyan

Perhaps you should also try preserving the order in diagram.Items, just in case. I.e. duplicate the code above and replace diagram.Nodes with diagram.Items. It's really hard to say what all the factors are, LayeredLayout.cs has about 3000 lines of code...

Regarding reusing objects instead of creating new ones, ControlNodes were just an example. If you are using ShapeNodes, you can update the node's Text, Shape, Brush / Image, etc. to show the dropped data instead of creating a new node. Same applies to other node types - you should be able to easily update their content to show the new data instead of creating a new node and removing the temporary one, and should be much easier than ensuring all items in all collections preserve their order.

I hope that helps,
Stoyan

Do you mean that two runs of LayeredLayout on the same graph result in different arrangements, or that running it once on a changed graph does not show the children in the order you expect them? I was assuming you are trying to preserve the arrangement when running LayeredLayout for a second time with a replaced node - the results should be consistent if all collections preserve their order and the connections between nodes do not change.

In the general case, the order of nodes within a layer does not reflect the order of node connections to their parent. It probably has some impact, since the initial configuration of LayeredLayout data structures depends on it. However, while the algorithm runs it reshuffles the nodes within a layer many times, looking to minimize crossing of links between layers, so adding a new child node can change the final result a lot. So I'm afraid there's nothing you can do to preserve the order within a LayeredLayout layer after adding new children and connections.

If your data is hierarchical, use TreeLayout instead: TreeLayout arranges children under a parent node in the order of links within the OutgoingLinks collection. If your diagram is an arbitrary graph where nodes could have more than one parent, you can still use TreeLayout, but must implement some additional processing for non-tree links because TreeLayout will ignore them.

I hope that helps,
Stoyan