Walter,
We’re subclassing GoLink, GoSubgraph, and GoIconicNode in our application. Cut/copy/paste seems to work fine. We are doing cut/copy/paste via making the involved drawing entities [Serializable]. We also have a business object in the UserObject field.
I have two questions.
We want to update one of our fields in the new Object’s UserObject upon paste (and drag/drop). How can we do this easily? I tried overriding CopyObject and that seemed to affect both the copied and pasted object.
We take two GoIconicNodes that are programmatically created within a GoSubGraph, and then link them. Then, we cut them and paste them outside of the GoSubGraph. Problem is, the GoLink.ToNode and GoLink.FromNode properties are null. When are these supposed to be set?
Thanks -Tyler
You’ll want to override CopyObject to make sure there’s a copy of your business object, if you don’t want to share it between the original node/link and the copied node/link.
Alternatively, you can implement a GoView.ClipboardPasted, a GoView.ExternalObjectsDropped, and a GoView.SelectionCopied event handler to make sure your new nodes/links have the right business objects associated with them. That should handle all of the predefined ways the user could make copies of nodes, but that won’t handle other ways your application might make copies programmatically – which is why overriding GoObject.CopyObject is a safer way to go, since that will do the right thing no matter the circumstance.
Did you include the link in the Selection before cutting them? If so, that should just work. If not, then the link wasn’t supposed to be copied anyway.
I’ll try to do this more explicitly and see if it solves the problem. Someone is making a copy of the business object, because I can change data in one and have it not affect the other, however, setting the business object property by accessing this.CopyObject().UserObject.[attrib] at copy time seems to change it before it gets cloned.
For 2), we did include the link in the selection before cutting them. In fact the link appears when pasted, but its ToNode and FromNode properties are both null. However, the link moves with its two connected nodes, and the business objects behind the link and two nodes in question seem to be intact. Perhaps something somewhere isn’t updating these link-based properties?
This only seems to happen A) after we have deserialized a document (our implementation of deserialization), B) when we’re cutting from inside of a GoSubGraph, and C) all of the elements cut are inside of the same GoSubGraph.
You shouldn’t be calling CopyObject() directly for any reason but calling the base method in your override of CopyObject.
Well, cutting (i.e. copying to the clipboard and then deleting) might result in deleting the nodes before you get to deleting the link, depending on the order of objects in the GoView.Selection. So the reason you happen to see null values for the link’s FromNode or ToNode (and presumably for FromPort or ToPort) might just be because of the time at which you are examining those properties.
By the way, if a link is between two nodes both in the same subgraph, do you add the link to the subgraph too? You might want to call GoSubGraphBase.ReparentToCommonSubGraph to do the right thing for you when you are adding stuff to subgraphs programmatically.
This might be the issue. I have set the tooltip method to return the names of the nodes a link is connected to, and I first noticed this when, after a cut and paste out of a deserialized subgraph, the tooltip text returned null.
I did this for programmatic link adds and it seemed to solve the problem. Within a programmatic add of a GoLink:
GoNode a = (GoNode)l.FromNode;
GoNode b = (GoNode)l.ToNode;
if ((a != null) && (b != null))
{
if ((a.Parent != null) && (b.Parent != null))
{
GoGroup p = (GoGroup)GoSubGraphBase.FindCommonParent(a, b);
if (p != null)
{
GoSubGraphBase.ReparentAllLinksToSubGraphs(p, true, view.Document.LinksLayer);
}
}
}
Does the new linking tool do this automatically? If not, what is the recommended way for the tool to do this?
Yes, GoToolLinkingNew and GoToolRelinking both call GoSubGraphBase.ReparentToCommonSubGraph, either directly or indirectly.
So the standard linking behavior for users will result in “properly” parented links.
Walter,
Very odd behavior. I used the GoSubGraphBase.ReparentToCommonSubGraph() during the programmatic AddLink() call in our API, and everything works fine. We’re using the GoLink.ToNode and GoLink.FromNode to generate a tooltip text so that the user can hover over and see what a link connects.
I’ve observed that inside of a GoSubGraph, GoToolLinkingNew (our basic subclass of it, at least) creates a link where GoLink.ToNode and GoLink.FromNode are false. We’re using a PropertyGrid to uncover this information. Our tooltip won’t even appear for some reason; I don’t know if this is related or not. However, if I cut and then paste outside of the GoSubgraph onto the main document, the tooltip still says that GoLink.FromNode and ToNode are null, but the PropertyGrid still says otherwise.
Any ideas on what could be happening?
Thanks, Tyler
Sorry Walter - Now I feel kind of dumb! I found it… it was a combination of not updating the tooltip text on-demand (which I thought I was doing right all along) and using
ReparentAllLinksToSubGraphsincrementally rather than
ReparentToCommonSubGraph
incrementally. I was just worried that if there were links with null attributes, something would break later :-)
-Tyler
I guess you hadn’t overridden GoLink.GetToolTip? That’s the natural way of generating dynamic tooltips.
Setting the GoLink.ToolTipText property is convenient when the tooltip information is relatively static.