Hello,
Given the SubGraphApp sample, I overriden some methods from TreeSubGraph.
Here are the modifications
PointF expandedPosition;
protected override PointF ComputeReferencePoint()
{
if( this.State == GoSubGraphState.Expanded ||
this.State == GoSubGraphState.Expanding
)
{
return this.expandedPosition;
}
else
{
PointF res = base.ComputeReferencePoint ();
return res;
}
}
public override void LayoutHandle()
{
//move the handle a little inside the group.
this.Handle.Position = new PointF(
this.Position.X +10,
this.Position.Y +10
);
}
public override void Collapse()
{
//Save the position where the group is expanded.
this.expandedPosition = this.Position;
base.Collapse ();
}
My problem is that after aplying the above modifications, when I collapse/expand the group multiple times, the group moves toward the upper left corder of the drawing area.
I don’t think this should happen because I save the expanded position before collapsing and I restore it in ComputeReferencePoint().
Any help is much appreciated.
Liviu
ComputeReferencePoint is called both for collapsing and for expanding. Perhaps you need to have it return your “expandedPosition” all the time.
But in either case, will that work if the user collapses a node, moves it, and then expands it? What are you trying to do?
What are you trying to do?
I want two things:
1) On collapse the group must be collapsed on the position represented by the spot location of the handle. This is why I used the default implementation of ComputeReferencePoint()
else
{
PointF res = base.ComputeReferencePoint ();
return res;
}
Note that the handle is not in the default position. I moved it a little bit:
this.Handle.Position = new PointF(
this.Position.X +10,
this.Position.Y +10
);
2) On expand the group must be expanded on the exact position it was previously expanded. If for example the group now has ‘group.Position = {10, 10}’, after collapsing and expanding I want the group to have ‘group.Position = {10, 10}’
The code in the first post tried to follow the specifications above. Unfortunately it doesn’t. As stated in the first post: 'My problem is that after aplying the above modifications, when I collapse/expand the group multiple times, the group moves toward the upper left corder of the drawing area. '. This is because at runtime, the expanded position is not the same as the previous expanded position as specified by point 2).
And I didn’t find any reason for this behaviour.
> But in either case, will that work if the user collapses
> a node, moves it, and then expands it?
I am not interested by this situation. We may presume that the user is not allowed to move the group while it is collapsed. It may only expand it.
> Perhaps you need to have it return your
> “expandedPosition” all the time.
The expandedPosition must not alter the collapsed position. Both positions are independent. So I cannot return the expandedPosition all the time.
As a conclusion, I want to know why the code presented in the first post does not follow correctly my specifications (point 1) and 2) above) as it should.
Thanks a lot for any help.
Liviu
I think your definition of LayoutHandle isn’t a reliable one, because it is depending on the Position of the whole group, which may vary depending on the contents and order of execution of LayoutChildren (which calls that method and related methods). Usually the actions of the Layout… methods should depend on the result of ComputeBounds (in version 2.2) or ComputeBorder (in the next release, which allows the bordered area to be different from the Bounds).
Furthermore, if you want to make sure the Position is a particular value after expanding, regardless of the position of the handle, why not set the Position in an override of Expand, after calling the base method?