The layout does seem to apply - the arows/links are affected by it. However, unlike the org-chart example, the layout doesn't re-arrange my nodes in a tree like view.
The "All" in the conditions property is indeed just to see that the layout enforces the nodes spreading. Links do go from the parent nodes to the child nodes. However, as I stated, the nodes position doesn't change according to the layout.
What could be the reason that the position of the nodes is not enforced by the layout?
By the way, my final goal is to create a simplified flow (e.g. a straight vertical list of nodes), but i need the GraphLinksModel because i need to create groups/sub graph and two kinds of links.
I don’t have an explanation for why it isn’t working. Can you determine if there are any relevant differences between your application and any of the samples that make use of TreeLayout?
Are the nodes actually connected by links in the manner you would expect? In other words, is the only problem that the TreeLayout doesn’t seem to be positioning the nodes? So that if you drag the nodes by hand you can get something like what you want?
The difference is that I use the GraphLinksModel and the GraphLinksModelNodeData and the examples use the TreeModel with the TreeModelNodeData, but according to the documentation it should work the same. Is there any example of a GraphLinksModel with a tree layout?
The nodes are connected fine (either manualy or in code) and i can set it the way i like, i'd just like the layout to enforce the tree structure so that the user won't mess it up.
First, while trying to debug the Location property, I've inherited from GraphLinksModelNodeData<string> and override it:
private Point m_location;
public new Point Location
{
get { return m_location; }
set { m_location = value; }
}
And suddenly it worked!
The second way was just to remove the binding to the Location property (since I don't need to persist it).
Thanks for the help, hope my solution will help others
I think the issue is that by default when a diagram is loaded, if all of the nodes have definite Locations, no layout is performed.
A Node.Location is “definite” when both the X and Y values are not NaN – in other words when the X and Y value are both regular numbers.
By not setting or data-binding the go:Node.Location attached property, it defaults to NaN,NaN, which results in a layout assigning the node locations. That’s why your second solution worked.
If you don’t like this “don’t do an initial layout when all of the nodes have locations” behavior, you can change it by customizing the LayoutManager:
The default value is “InvalidateIfNodesUnlocated”.
It isn’t clear to me why your first solution worked. I would have thought that your data-binding of Node.Location was assigning actual locations to all of the nodes, but redefining the data.Location property wouldn’t change that because the default value of your m_location field is 0,0.
That’s odd, because when I modified the FlowChart sample, everything behaved the way it’s supposed to.
The existing behavior is to load a diagram from XML; it doesn’t do any layout.
If you define a go:Diagram.Layout, that layout doesn’t happen after the initial diagram is loaded. It only happens when its DiagramLayout.Conditions are met – by default when nodes or links are added or removed, etc.
But if you define a go:Diagram.Layout and a go:Diagram.LayoutManager with Initial=“InvalidateAll”, the layout occurs immediately after loading, thereby discarding all of the node locations that were read from the XML and assigned to the go:Node.Location via data-binding.
Just to be clear: I never re-defined a “Location” property in the data class.
