Is there not an event that is fired when the GoSubGraph is expanded and or collapsed.
I see I can override FinishCollapse or FinishExpand but I would like to handle the event in my View not in the GoSubGraph.
Nope, no events fired.
My View has a Layout method on it that I want to call when the user expands or collapses a GoSubGraph. I read this post and tried handling the ObjectSingleClicked event but that didn’t work it seemed to perform the layout before expanding or collapsing.
There must be a way without having to duplicate the layout code in the GoObject.
All ideas are welcome
You could catch the GoView.DocumentChanged event and look for the SubHint GoSubGraph.ChangedState when the new integer value is either GoSubGraphState.Collapsed or GoSubGraphState.Expanded.
If I call a layout code in the event handler under the conditions you describe,
the lay out works in the case of expanding a subgraph node.
In case of collapsing a subgraph node the layout seems to be made too early - when the subgraph is still expanded.
But I need to perform a new layout after the subgraph is really collapsed!
How can I call the layout-procedure late enough?
The default behavior of making the nodes and links not visible and moving the nodes to be at the same position (where the collapsed subgraph will be) should be sufficient.
So I don’t think you would need to perform a layout when collapsing. Or do you want to do achieve some other effect?
I have to deal with subgraph hierarchies with many subgraphs, which can contain 10 - 100 nodes.
So I want to provide both a clear arrangement and access to detailed views.
When expanding a subgraph this subgraph should be displayed on an area large enough for its nodes (that works with the eventhandler as described).
When collapsing a subgraph the neighbors should be moved back near to the collapsed node. (Otherwise I will end with an very sparse arrangement).
You get a good insight in my goal, if you look at the Grouping demo of GoXam (http://www.goxam.com/1.1/WPF3.5/GoXbapDemo.xbap) Here you see a situation similar to my application.
I hope I could describe my situation clear enough !?
So when the subgraph is expanded you want to lay out the member nodes and links.
Then when the subgraph is either expanded or collapsed you want to layout the “parent” graph. If that “parent” is actually another subgraph, then after it’s done, you want to layout its “parent”. And so on until the “parent” graph is actually the top-level graph.
Yes.
And the question remains for the collapsing case:
Which is the event, when the subgraph is already collapsed, and the layout of the “parent” (or may be the “parents”) can be performed?
See Walter’s much earlier reply above about DocumentChanged.
I already followed Walters reply and failed,
because at that event he described
in case of collapsing a subgraph the subgraph seems be still open.
At least the layout then works as if the subgraph would be still open.
Therefore actually I wrote my first reply!
At the time GoSubGraph.Collapse() sets the State to GoSubGraphState.Collapsed, all of the subgraph’s member nodes and links should already be not Visible and positioned at the same location.
However, it’s true that at that time the GoSubGraph.Handle, .Port, and .Label haven’t been re-positioned yet, because Collapse() hasn’t called LayoutChildren yet. I suppose you could call it explicitly before you perform the outer layout that arranges the graph that includes the collapsed subgraph as a single small node.
Thanks Walter,
this last hint helped.
Now I replaced the DocumentChanged Handler in the sample SubGraphApp3 by the following code and it worked. Perhaps it is useful for other people.
private bool _inDocumentChanged = false;
private void goView1_DocumentChanged(object sender, Northwoods.Go.GoChangedEventArgs e)
{
if (_inDocumentChanged) return;
_inDocumentChanged = true;
if (e.Hint == GoLayer.InsertedObject)
{
UpdateHighlighting();
}
if (e.SubHint == GoSubGraph.ChangedState)
{
goView1.StartTransaction();
((GoSubGraph)e.Object).LayoutChildren(null);
LayoutSubGraphs(goView1.Document);
goView1.FinishTransaction("autolayout");
}
_inDocumentChanged = false;
}
Of course for productive use the amount of the recursive calls of LayoutSubgraphs should be minimized.