Try calling Diagram.computePartsBounds on a collection of the Group.memberParts that are Nodes but excluding the Links. (That’s assuming Group.computesBoundsIncludingLinks is false. If it’s true, you can just call group.diagram.computePartsBounds(group.memberParts).)
Yes, const groupSize = this.diagram.computePartsBounds(this.containingGroup.memberParts) did the trick, now all computes correctly.
Also we noticed, that there are reproducible issue, when there is nested groups and when one is removing layout breaks:
It becomes as red arrow pointing, where green is expected. But, if in red state just drag and hold some action and hover it over any link back and forth multiple times, layout is refreshing step by step moving towards a green one and finally becomes a green one:
We’ve tried these commands to force refresh it but nothing helps:
_d.layoutDiagram(true)
_d.requestUpdate
_d.redraw()
_d.layout.invalidateLayout
What can cause it? Maybe there is another command to refresh diagram?
I don’t understand the problem. Isn’t what you show in the first screenshot on the left what you want? All of the nodes are left aligned. Wasn’t that produced by the layout?
What do you mean by “removing layout breaks”?
So is the user dragging the “If Else” group towards the right, resulting in the smaller screenshot at the top right that has the red arrow point to it? But if they are dragging it towards the right, isn’t that what they want?
Or are you saying that the layout is producing the screenshot at the top right, rather than the bigger screenshot on the left side?
Your second set of screenshots seems to be showing what happens when the user is dragging the “If Else” group towards the left. Is that correct? What’s wrong there – it looks good to me, except that there is an “Action” node in the “False” case that shows up during the drag and then disappears!? I can’t explain that “Action” showing up – you must have customized the dragging somehow.
My bad, I’ll try to explain, top left big screenshot is how diagram looks now, all is nice, exactly what we was aiming for, also all drag n drop operations working well.
But there is one issue when user delete nested group, like IfElse (on the big screen) select and delete, after this diagram should back to green arrow state, but it goes to red arrow one.
What we try in this case is how to refresh diagram that it will be redrawn and become a green arrow state (as it should be), but nothing of that 4 commands affect anyhow the diagram, it is not refreshing.
But we’ve noticed when in red arrow state (after deletion), user will try to add another action and will just drag it over some link, the layout is refreshed and moved towards green state a bit (not completely, links and content just moved couple pixels), seems like something while hovering triggers diagram to “recalculate” something and refresh. And if user continue to hold action and hover it over link without dropping it will trigger layout more with each move until it finally become green state.
Have you set Layout.isOngoing to false on any layout? Have you set or bound Part.layoutConditions on any Node or Link?
Normally, removing a node (such as the nested “If Else” group) will invalidate the layout that is responsible for positioning that node (in your case the layout of the outer “If Else” group). So that the layout will be performed again at the end of the transaction.
You can also force all layouts to be performed again by calling myDiagram.layoutDiagram(true). A call to Layout.invalidateLayout should work for that particular layout and (probably) any enclosing layouts.
Layout.isOngoing and Part.layoutConditions was not touched, so set by default.
Also as I mentioned none of these commands has any effect:
_d.layoutDiagram(true)
_d.requestUpdate
_d.redraw()
_d.layout.invalidateLayout()
Then it sounds like a full layout really does produce the result that you are getting. Maybe it now thinks that your group is wider than it originally was.
It is also reproducing on the Flowgrammer page:
Remove all and add three nested switches like on screen, then select middle one and remove:
Left group will be wider than its initial size
And then try to drag action and hover on any link but not release, diagram will move towards its normal state.
That’s interesting. Thanks for pointing it out in the Flowgrammer sample.
The bug is in the definition of the group template in that sample, which was explicitly setting the width of that lime green highlight bar. That length was preventing the group from naturally becoming narrower when the Placeholder did. Please use this instead:
myDiagram.groupTemplate =
$(go.Group, "Spot",
{
locationSpot: go.Spot.Center,
avoidableMargin: 10, // extra space on the sides
layout: $(ParallelLayout, { angle: 90, layerSpacing: 24, nodeSpacing: 30 }),
mouseDragEnter: function(e, group) {
var sh = group.findObject("SHAPE");
if (sh) sh.stroke = "lime";
},
mouseDragLeave: function(e, group) {
var sh = group.findObject("SHAPE");
if (sh) sh.stroke = null;
},
mouseDrop: dropOntoNode
},
$(go.Panel, "Auto",
$(go.Shape, "RoundedRectangle",
{ fill: "rgba(0,0,0,0.05)", strokeWidth: 0, spot1: go.Spot.TopLeft, spot2: go.Spot.BottomRight },
new go.Binding("fill", "cat", groupColor)),
$(go.Placeholder)
),
$(go.Shape, "LineH",
{
name: "SHAPE",
alignment: go.Spot.Bottom,
height: 0, stretch: go.GraphObject.Horizontal,
stroke: null, strokeWidth: 8
})
);
Also, we’ll improve the routing at Switch nodes by decreasing the …EndSegmentLength values on the Link template.
myDiagram.linkTemplate =
$(go.Link,
{
selectable: false,
deletable: false,
routing: go.Link.Orthogonal, corner: 5,
fromEndSegmentLength: 4, toEndSegmentLength: 4,
toShortLength: 2,
. . .
Thank you, Walter, this solves the issue.
shape.width = Math.max(20, group.actualBounds.width - 20) was causing it.
We’ve updated code according to your and now all works fine.