Do you have a property in LayeredDigraphLayout similar to “alignment: go.TreeLayout.AlignmentCenterChildren” in TreeLayout?
Basically I am trying to create a flow diagram using LayeredDigraphLayout (as this layout quite impressively gives the closest default result). One of the elements in the flow could be a decision node from where multiple branches can come out. The problem I am facing is the inconsistent layout of the children branches and its nodes with respect to the parent (decision node). Often decision node is not in the center with respect to its branches. The same can be done in tree layout using the alignment property but using tree layout is not an option. So I need something similar to this property in LayeredDigraphLayout. Please help. We are quite close in our POC for GoJS and are stuck only at this last issue.
I’m looking into this issue; I’m not sure how long it will take.
[EDIT: updated with ParallelLayout extension]
Use the ParallelLayout extension.
It is demonstrated at: Parallel Layout
It is implemented at: https://gojs.net/latest/extensions/ParallelLayout.js
It is documented at: ParallelLayout | GoJS API
Hi, We tried your Parallellayout example, After adding few more nodes and branches it looks like as below.
As you can see Nodes S, J, FFF, 0 and * are not aligned with base line (imaginary).
and same case with second red line.
As we keep on adding more nodes and branches, it results in more elbows.
Could you please suggest any solution to correct it.
Thanks in advance.
I can see your point about FFF and 0 and * not being aligned with S and J, but I don’t see how you could expect anything else on the right half of the diagram to be aligned with it.
The ParallelLayout is just a simple customization of LayeredDigraphLayout. The design of LayeredDigraphLayout has a lot of features that you apparently do not want. That explains why DDD has been moved up, because of influence from EEE.
I’ll see if a different kind of layout can get you what you want. However I will make the assumption that there are always pairs of Split and Merge nodes, and that they always nest properly, and that there are no links that cross boundaries (e.g. from H to E), and that any path to a Merge node will come from it corresponding Split node.
[EDIT: ParallelLayout is now an extension.]
I have updated Parallel Layout to use TreeLayout and require the use of Groups, where each Group has a single pair of Split and Merge category Nodes.
With some additional programming one could remove the requirement of having Groups in the model data, but I didn’t do so, since I thought you didn’t require it. Note that whether the Groups are visible in the Diagram is completely up to the template that you use to represent them. In this sample now the Group template holds only the Placeholder, no Shape or TextBlock, so there’s nothing to be seen.
Hi, Thanks for the solution, it’s giving the perfect desired result.
Now we are facing a small alignment issue.
Some times the diagram is not drawing properly and producing small alignment issues.
As marked in below image, you can observe that some nodes are not properly aligned.
We found the cause of the problem is,
Our nodes are having images, when we load the diagram first time diagram is getting loaded and then the images gets loaded. so there is a time lapse causing alignment issues.
when ever we refresh or click it again, its taking from cache so it draws properly.
Is there any way that, we can display the diagram once the images loaded.
Specify the Picture.desiredSize, or the Picture.width and height.
Hi walter,
We were using Parallel layout for our diagram.
Now we are trying for a different layout which should be top aligned.
It should look like below diagram.
So to achieve this, I modified parallel layout code with
this.alignment = go.TreeLayout.AlignmentStart;
this.alternateAlignment = go.TreeLayout.AlignmentStart;
But it resulted in below diagram
Here, you can see the nodes (S,C),(A,J),(J,T) are not aligned properly.
I observed one thing which is pointed in above diagram with red dot line.
When the alignment is AlignmentStart, all the nodes will be aligned with there top most Y point, and this behavior leading some elbows in the layout.
When all the nodes heights are same, then it draws perfectly as first diagram. But we are having different sizes for different nodes.
How it can be avoided, and how can we get the desired diagram output ??
To be clear, TreeLayout.AlignmentStart is supposed to do what you see. Otherwise with differently sized nodes the edge would be jagged.
One possibility is to go through the nodes afterwards and shift them down the way that you want. The only problem is if that might cause an overlap, but I am guessing that for your diagrams that would not be a problem.
Hi Walter,
As I mentioned, it was drawing properly with nodes having same height.
So to make it work,
I added transparent shapes with static height to all the nodes,
<span =“Apple-tab-span” style=“white-space:pre”> $(go.Shape, { fill: “transparent”, stroke: null,width:0, height : 50 }),
so Now it makes all the nodes with same height. and its not disturbing the look of small and big nodes.
In below diagram the vertical red lines are the shapes I added, And its giving our desired output.
But One problem I’m facing here is, Its not drawing properly when I add border to the group.
In above diagram, Split node S and Join node J and the branches are part of a group, currently which is not having any border.
When I add any border, the group (group’s border) is aligned to the top instead of inside nodes (Which were aligned without border earlier).
You can see a tilt between Item2 and S nodes.
Can we fix this behavior, If we some how fix this thing then our work is almost done.
Appreciate your help
Thanks
What happens when you set Group.layout = null in your Group template?
That We cant use, because we are having the same flow inside groups also.
We fixed it using moving groups with some static length in Y axis.
One problem we are facing here is,
The link connected to Join node is getting changed to its default, when ever the connected node or group has been moved. This is observed with manual moving also.
Initially the join link has been reshaped in commitlinks.
Then in commitNodes we are moving group with some Y offset, after that the join link is redrawn to its default automatically.
There is no callback to commitlinks while it changed to its default.
How can we avoid?
Or Is there any way so that we can find the changed link so that we can reshape it again ?
Thanks
And same behavior observed with Split node links connected to groups
How is the link not routing correctly after you have shifted some vertexes in the layout? Or, to ask it another way, how is the default route incorrect?
We are using parallellayout [EDIT: now an extension] Parallel Layout and http://gojs.net/latest/extensions/ParallelLayout.js
Here we are routing all split links and join links in commitLinks method.
As we need split and join links should be splited or joined from one line (Same as above sample diagram).
So with default behavior that is not achievable.
You can observe in above sample, When you (manually or using with gojs api) move node Another or group T–K the link is getting changed to default route and changed the desired look.
This we want to avoid.
Try setting:
adjusting: go.Link.End
on your Link template
Hi Walter,
We are moving groups upwards to solve the tilts in layout,
That’s causing overlaps with other branches.
Why the layout not maintaining nodeSpacing, after any node/group got moved ?
Is there any way to maintain constant nodeSpacing, in this situation ?
Please find below post of mine which explains the problem.
http://www.nwoods.com/forum/forum_posts.asp?TID=5537&PID=24159&title=center-children-in-layout#24159
Thanks
If you are explicitly moving some nodes, then the layout has nothing to do with the positioning of nodes, so perhaps you should move those other nodes too.
What has changed since a month ago?
As I told earlier to solve tilts, we are moving groups littlebit upwards,
Earlier we tried with only a group inside a group, so that doesn’t caused any overlap.
But now we are having 5 iterative groups(group inside a group…)
So all these are combinely moved by 5*move_height,
Now with this the overlap is coming.
Coming to your solution, how should we move other nodes?
Because this ovelap length is not consistent, it depends on number of groups inside it.