A couple of quick questions. I wanted to set the position of a note object anchored to a node once it is moved. Im curious, do I need to override the OnMove function of my node class, and find the note through a child property? Also, I’ve noticed that if i specifically set a position for a node in my view, the golayeredlayout doesnt seem to move it during a layout, is there a property i need to set to move nodes with specified position values?
Thanks,
Ryan
Is your situation one where there are two independent top-level objects, and when the user moves one of them, you want the other one to move too? What should happen when the user moves the other one?
Let’s say that you have a node A and a comment B. We’ll assume that comment B is semantically “about” A, and that when A moves, we want B to move with A, but not vice versa.
This situation is very similar to the label of a GoIconicNode, when DraggableLabel is true, except that in your case they are two independent objects, rather than a label that is also a child of a node.
It might be easiest to implement this by using “observers”. Call A’s GoObject.AddObserver(B) method and override B’s OnObservedChanged method. Look for the GoLayer.ChangedObject hint and the GoObject.ChangedBounds subhint and that the object is the A that you care about following. Then adjust the position of B as you see fit, according to the position of A.
One complication is that if A is removed from the document, you may want to call GoObject.RemoveObserver so that B is no longer dependent on A. That requires checking for the GoLayer.RemovedObject hint. You’ll want to call RemoveObserver if B is removed too.
Hey Walter,
I implemented, or attempted to implement the solution you gave me for moving my balloon objects anchored to a multitextnode when it moves. So I implemented the observer, and I have the following code in my balloon OnObservedChanged override, but Im getting really odd results, when I move my multitextnode, sometimes it repositions the balloon well, and sometimes its way way off. Also, I have been having this problem with the anchor of the balloon pointing to the orgin of the view, instead of its anchor object, until i move the balloon a little bit, then it points the anchor back to its anchor multitextnode. Im enclosing my OnObservedChanged code, if anyone has any suggestions for either of my problems I would appreciate it.
CAssignmentNode is an inherited GoMultiTextNode, and CNoteNode is an inherited GoBallon.
protected override void OnObservedChanged(GoObject observed, int subhint, int oldI, object oldVal, RectangleF oldRect, int newI, object newVal, RectangleF newRect)
{
base.OnObservedChanged (observed, subhint, oldI, oldVal, oldRect, newI, newVal, newRect);
CAssignmentNode oParent = (CAssignmentNode)observed.ParentNode;
SetPosition((newRect.Location.X + 100), (newRect.Location.Y - 50));
}
Thanks,
Ryan
Well, you at least need to check subhint == GoObject.ChangedBounds, or the RectangleF values may be undefined.
Walter, I added the subhint checking, and it seems that the x and y values im getting are indeed correct, but my anchor point ends up pointing out to no where, and the balloon positions correctly sometimes, and way off to the bottom right of the screen sometimes, and i mean way off. I am suppose to set the position property of the balloon? Am i somehow suppose to reset the anchor point of the balloon? Any suggestions on why my ballon would position itself way off, even though ive set break points and the values coming in look fine. I mean the values coming in from the newrect argument. Im just having alot of problems with the balloon object that I dont have with any of the other go objects.
Thanks for the help,
Ryan
This is a bug in the computation of the Bounds of the GoBalloon object. Or maybe I should say this is a bug in the design of the computation of the Bounds of a GoBalloon. Having the Bounds include the pointer to the Anchor object causes the problems that you see.
This has been fixed for the next release, 2.2, by changing ComputeBounds not to include the part of the background polygon that is pointing to the Anchor, and overriding ExpandPaintBounds accordingly.
Your great, thanks Walter!
I am still having issues with the GoBalloon not correctly recalculating
the tip of the anchor pointer. When I move a node (GoIconicNode), the
GoBalloon anchor pointer points back to the origin of the view. I am
running version 2.2.1. I know it is not the latest but I am unable to
upgrade at this time due to development cycle constraints.
Do you see this problem in Demo1? What relevant changes have you made in your application?
Demo1 does not have this problem as it stands.
Change the anchor for the GoBalloon in the AddStuff method to the BasicNode by changing the line
<span style="font-family: courier new,courier,mono;">balloon.Anchor = anchor;</span>
to
<span style="font-family: courier new,courier,mono;">balloon.Anchor = bn;</span>
Run Demo1, Insert -> Lotsa Stuff, grab the orange and black node with the 23 above it and move it around.
You will notice the balloon anchor point fly up to the origin as you
drag the node around. Seems to reset itself most of the time, but if
you do a quick small adjustment to the position, it will always fly off
to the origin and stay there.
I traced our problem seems to be in
GoIconicNode.GetNearestIntersectionPoint. Seems that half the time it
does not compute a valid value and returns (0,0).
In our GoIconicNode derived class I placed the following override …
public override bool GetNearestIntersectionPoint(PointF p1,
PointF p2,
out PointF result) </span><br style="font-family: courier new,courier,mono;">
{
bool rc = base.GetNearestIntersectionPoint( p1, p2, out result );
if ( ! rc )
result = this.Center;
return true;
}
The above override provides a reasonable behavior in the situations
where the base class (GoIconicNode) is not able to correctly calculate
the intersection point.
Thanks for telling us about this bug in GoBalloon’s computation of the anchor point.
By coincidence, we had already fixed that bug for version 2.3, which is just entering beta test. But you found a clever work-around, which I hope will be satisfactory for now.
By the way, version 2.3 adds a new feature to GoBalloon, to allow users to interactively re-anchor a GoBalloon, with two virtual methods to customize where the anchor point is and how new anchors are chosen, and to specify where the balloon should point when there is no Anchor object.