Hi,

There is no built-in support for that. You could try to reattach the dependant nodes to the currently selected node when NodeActivated is raised.

Alternatively, handle NodeModified or NodeModifying for the root nodes and update the dependant nodes' positions from the handlers. If you do that from NodeModifying, you will also have to call the RecreateCacheImage method.

I hope that helps,
Stoyan

Although the NodeActivated method works well in far as movement of nodes I have found an undesirable knock affect.  This is that a _fcnet_AttachTo command is added into the UndoManager.  Since the attachto is done in order to achieve something invisible to the user it does not make much sense to the user to have this in the History.  Is it possible to prevent this command being added to History or remove afterwards.  I have already  tried to set UndoManager.UndoEnabled to false, perform the attachto, then set UndoEnabled back to true but this has the (also) undesirable affect of clearing out all the commands from the UndoManager.

Thanks for the reply Stoyo.   Although this works I am sometimes loosing commands for the command history when I move nodes.  This is probably my implementation but I'm thinking that I will look at your alternative to manually move the dependent nodes in NodeModified or NodeModifying.  To do this I will need to know how much the node e.Node has moved.  Is e.Node.Bounds the original node position and MousePosition the new node's position.  Otherwise can you point me in the direction of how I might determine the amount moved.  Thanks

Hi.  Sorry to revert to you yet again.  However I try to achieve this I do at first appear to be able to add the functionality we want.  However after more testing I find unwanted side affects.   So far these side affects appear when ContainerNodes and/or undo/redo functionality is added to the mix.   Is this the reason that the control as supplied behaves as is it and does not behave or have the option of behaving in the way we want it to?   Or am I being a bit dim!  In either case do you have any plans to add this behaviour we need in the future or is this behaviour not at all in demand to make the work worthwhile?  Many thanks again.

Behaviour being that a DiagramNode moves whenever the Origin of an IncomingLink moves no matter how many IncomingLinks with Origin there are.

The control automatically collects multiple ModifyItemCmd's from the same interactive move operation into a single undo/redo record, so undo should work fine if you trick it into believing that the dependent nodes movement is caused by the user.

One way to do that if you use custom node class is to override the StartModify, UpdateModify and CompleteModify methods and call the same methods of nodes on the other end of this node's outgoing links.

Another method you might try is to automatically select the destination nodes when an origin node is clicked; then the user will be moving all the nodes using the built-in multiple selection feature. The multiple selection handles will show the user that all these nodes will be moved anyway, but you could hide them by temporarily setting their HandlesStyle to Invisible.

I don't know what problems you have with containers. but the effect of dropping the multiple selected nodes into a container should be that they all become its children.

You aren't doing anything wrong, but it seems the control assumes it adds children to a container every time you drop nodes over it and creates an AddToContainerCmd instance, even if the dropped items were originally in the same container.