this works fine but i don't want the user to even be able to drag the node on the y axis. i tried to examine the sequence diagram sample but didn't understand whats going on there.
I looked at the demo but overriding computeMove doesn't help my problem. the user can still drag the textNode anywhere on the view. the computeMove function is activated only when the user stop dragging and do the drop. i want to limit the user to drag only on the X axis. the sequenceDiagram sample works fine but i don't understand how did you do that.
Sure! this solved the problem. last night i dreamt about it and in my dream i figured out that i should use the dragsrealtime prop. and here you are saying just that…
when i set the dragsRealtime=true if the node is connected to other nodes and you replace the dragging tool to TreeDraggingTool from the sample applications you get a strange behavior of the link. it simply moves away from its original position up or down - very strange (see picture)
this is how it looks when you start dragging:
now look what happens after a while (usually when you stop dragging but keeps the mouse down):
the link starts separating from its nodes moving freely up or down.
if you disable the dragsRealtime (i.e. = false) then everything works fine
what do you say? is it a bug?
most important what is the workaround for it?
is there a simple property i can set in order to cause all the connected nodes to move with the selected one instead of replacing the mouseDragging tool?
Modify the TreeAppNode in the TreeApp sample as follows:
public override PointF ComputeMove(PointF origLoc, PointF newLoc)
{
return new PointF(newLoc.X, origLoc.Y);
}
and.... you will get the same unexpected result.
OK, I can reproduce this in TreeApp, but only if I have the “Moving selection moves subtrees” checkbox enabled, and only if I move a “root” node, not the “leaf” nodes. Does that match what you’re seeing?
TreeDraggingTool includes the links in the EffectiveSelection. The code in GoDraggingTool makes the optimization that any link that is in the selection being moved, if both end-nodes are also in the selection, that it doesn’t have to call CalculateRoute as the selection is being dragged.
But, in this case, your node class is limiting the movement to the X direction, and the links aren’t. and GoToolDragging doesn’t see that.
so, in TreeDragginTool.AddReachable… comment out these two lines:
Note that GoToolDragging has a property called EffectiveSelectionIncludesLinks that allows control over this, but in this case the TreeDraggingTool in the TreeApp sample just isn’t that sophisticated.