I guess it’s obvious that the Function CopyFromCollection has problems with copying GoLabeledLinks, maybe also GoLinks in Common.
I’ve done a routine, which copies graphical objects from one doc to another, while there are some data-objects which also get updated.
After thoroughly checking the programme routines, we noticed that the GoDocument.ContextMenu call for a certain Menu-Point wasn’t associated to the right graphical object.
But doubleclick works.
We thoroughly checked the routines and noticed that
there are no bugs in it.
So has anyone experienced problems with GoLinks or GoLabeledLinks when using CopyFromCollection?
Thanks for the answer.
We haven’t heard of any problems like that with any of copying methods. Are you sure there’s a problem copying, as opposed to something with context menus?
Remember that there is a hierarchy of parts, and that the object that is picked at a particular point may be a child of the object that you care about. In the case of GoLabeledLinks, maybe you are getting the object that is the label, and you need to look at its Parent to get the GoLabeledLink.
No definitively not.
I tried again yesterday with the other overload of CopyFromCollection taking only one parameter.
Then I got the old node in the new Doc.
There are definitively different behaviours dependant on which CopyFromCollection I call.
I can’t explain that.
I will have to reprogramme a big part of the programme now if I won’t find the mistake whether it’s from GoDiagram or not.
I’ve checked for the right objects. foolproof…
I’ve checked for the right document. foolproof…
then I’ve checked for the clicked document…
that’s the point where could still be a opportunity that it’s my bug.
Furthermore I’ve noticed that the clicked transactions (only them) have the wrong document. (calling GRTransition.Document (GRTransition is derived from GraphLink).
And this is already after just using CopyFromCollection.
I saw it when I cut my routine to test to use just CopyFromCollection copying the objects from one Document to another. The routine did only that. Nothing else.
But I could also think of a property in GoLabeledLink which prevents CopyFromCollection doing it’s job correctly, would that be possible?
I got another idea that it may be dependant on using different layers. I tried to copy 2 nodes connected by a link all existing on the default layer.
Then I tried again
GoCopyDictionary dict = CopyFromCollection(view.Selection)
Problem still exists.
But I’ve noticed now I got no problem in my Testproject containing also two GraphViews with two GraphDocs.
But there I’ve also treid to copy them to a new window containing a GraphView with a GraphDoc.
If I try this, the objects will not show up.
Why is that?
I’m still using GoDiagram Win 2.1.2 (Win XP)
Could you describe more precisely exactly what you are doing? What state are you starting from, and what are you copying to, and what results are you getting? You’ll want to write code to check the properties of all the copied (and original) objects.
Is there other state that you have added to the classes that is not being copied correctly? In other words, did you override CopyObject appropriately, to avoid unintended sharing of references between the original object and the copied object?
OK, I guess I found the bug, which I still do not know if it’s one of my own.
Situation: copying a bunch of nodes connected to other nodes to another view. calling a contextmenu which refers to the data of the new object searches for the data of the old object.
I was able to figure out today that the menu was shared with the copied of the GoLabeledLinks, but not with the GoTextNode.
So I’ve explicitly set my GoContextMenu property to null
and - guess what - it works.
But why is this problem only related to GoLabeledLinks? (it could maybe be related to all kind of links, but since there are just GoLabeledLinks in my app… you know?)
Ok, just wanted to let you know that the problem is solved.
Did you add a field and property on your GoLabeledLink-derived class? Then that field in the copied object will share the same reference as the original link, unless you explicitly do something in GoObject.CopyObject.
Typically one sets fields referring to Windows resources to null in CopyObject, and then any code needing that resource can re-create it on demand. Of course, you may need to save/copy additional information so that you can recreate that Windows object again…
Yes.
The object has a variable cmLinkContextMenu which
was created in the constructor.
When reconstructing the problem and recoding the routine to make the problem disappear I’ve set it to null and now the menu is created again, when doing a right click on the object whether it is a GraphNode or a GraphLink.
But the GraphNode has also many properties like this.
Still don’t know why it didn’t happen there.