Hello everyone.
I’ve encountered a strange behavior involving a GoCollapsibleHandle and GoSubGraph.
I used a GoBasicNode which adds a GoCollapsibleHandle (much like the TreeAppNode in the demos).
The problem occured after those nodes were SubGraphed. Upon expanding a collapsed SubGraph,
the CollapsibleHandles’s location changed - it moved away from the node, and thus enlarged the subgraph.
I tried to force the handle’s location be the node’s location on the FinishExpand method. Although it kept the
handle inside the node (as it was before the collapsing), the subgraph kept growing on each expand.
I’ve tried the same thing with the GoSubGraph demo. Inside a MakeNode method I added those lines:
GoCollapsibleHandle h = new GoCollapsibleHandle();
…
h.Location = bn.Location;
bn.Add(h);
And the same thing happened - the GoSubGraph kept growing on every expand, and the handle kept moving away
from the node.
Walter, what am I doing wrong? :)
P.S.
I’ve managed to bypass the problem by removing the handle upon PrepareCollapse() and restoring it upon FinishExpand().
But still, it’s interesting how/why the aforementioned problem occurs.
I’ll look into this. Thanks for reporting it.
Thanks :)
By the way, I there is one small bug in the GoSubGraph demo. If the SubGraph is collapsed, and the “Ungroup” button is pressed, the node is deleted with all the nodes and links inside it. The links which were connected to the SubGraphed node stay in their place, until slightly moved, in which case they disappear (naturally, because they are no longer connected to anything).
To solve this, in the demo code, I just called Expand() before the ungroup method’s entry.
Other then that - GoDiagram is just perfect :)
I just tried modifying SubGraphApp.Form1.MakeNode as follows:
GoBasicNode MakeNode(PointF loc) {
GoBasicNode bn = new GoBasicNode();
bn.LabelSpot = GoObject.Middle;
bn.Text = (myCounter++).ToString();
bn.Label.Editable = true;
bn.Location = loc;
bn.Port.IsValidSelfNode = true;
GoCollapsibleHandle h = new GoCollapsibleHandle();
h.Location = bn.Location;
bn.Add(h);
goView1.Document.Add(bn);
return bn;
}
(I also added an “sg.Expand();” after the first comment in the button2_Click method. Thanks!)
Collapse and Expand seem to work just fine for me, with all three kinds of subgraphs. So I don’t understand how to reproduce the problem.
Now, it is the case that GoBasicNode.LayoutChildren will not know about the extra child object, so it will not reposition it. Just moving or copying the node will be fine, but if the node is resized, or if part of the node is repositioned or resized, it’s possible the handle won’t be positioned in the manner you want after the call to LayoutChildren.
Generally, if you add child objects to a node and care about their positions relative to other child objects, you should override LayoutChildren so that you can make sure they are positioned/sized the way you want.
I’m not sure if there’s other code involved in your case that might be causing this latter problem.
Thanks for the reply, Walter.
I have a few images which demonstrate the problem:
Handle added (no [+] naturally, because I didn’t implement IGoCollapsible). Two nodes were selected, and SubGraphed with CustomSubGraph.
Figure 1- Right after grouping:
Figure 2 - 1st collapse/expand (clicking on the [+])
Figure 3 - 2nd collapse/expand
Figure 4 - 10th collapse/expand
Sorry. Another post.
Now, when I forced the h.Location upon FinishExpand(), it seemed to stay inside the node, but the size of the SubGraph still kept growing.
I am able to reproduce this on both 2.3.1 and 2.4.1 on 3 different computers.
Strange, huh? :)
So the only change you made to SubGraphApp was what I posted earlier?
Weird. Let me try again… (I was using 2.4.1, and .NET 1.1.)
Same, only .NET 2 (using VS2005 Team Architect edition)
Aha! I reproduced the problem with 2.3.1, but not with 2.4.1.
The difference is due to a change in GoSubGraph.Collapse to address the cases where nodes did not implement LayoutChildren completely, as I discussed in the second half of my post above (11 Jan, 6:56pm). It’s also mentioned in the release notes for 2.4.1.
A similar problem exists in 2.4.1 with autolayout, which we’ll fix for 2.4.2.
Oops. As usual, Walter, you are absolutely right.
I made a mistake, and it was indeed only affected in 2.3.1. I’ve made sure that 2.4.1 was installed, and tested it, and it worked.
But, there is one more issue though :) In 2.4.1, when the same 3 lines of code used to add the handle to the nodes, the yellow handle was drawn blank (without the +/-). I simply thought it was because I did not implement IGoCollapsible, however I’ve tried it now on 2.4.1, and the - sign was only drawn when the nodes have been subgraphed.
Also, upon clicking on one of those handles, the subgraph itself collapsed :)
Like I said, this is a no-issue, so I thank you again Walter for taking the time. 
Yes, that’s an unrelated improvement for GoCollapsibleHandle for 2.4.
In 2.3 and earlier, it just looked at the immediate Parent to see if it implemented IGoCollapsible. That policy restricted the flexibility of that GoCollapsibleHandle–for example, you couldn’t nest the GoCollapsibleHandle inside a GoGroup inside the group or node that you wanted to collapse/expand.
Hence the generalization in 2.4. We added the virtual FindCollapsible method that searches up the Parent chain for an IGoCollapsible.
When there is no IGoCollapsible that is found by FindCollapsible, it doesn’t do much, and that includes not drawing a + or - or whatever as determined by the GoCollapsibleHandleStyle.