How does relink work with ancient JGo version?


#1

Specification-Title: JGo Graphical Object Editor Library
Sealed: true
Specification-Vendor: Northwoods Software Corporation
Implementation-Vendor: Northwoods Software Corporation
Specification-Version: 4.0
Implementation-Version: 4.0
Implementation-Title: com.nwoods.jgo

We’re working with a very old version of JGo that was purchased by SAIC for Envision in (maybe) 2001. I don’t have any information on the order number or anything.

We’re near the end of phase 1 of a project and can’t afford to upgrade JGo now. If we win phase 2, we’re definitely going to upgrade.

For now, though, I’m wondering if there is any documentation for this old version. I’ve never worked with JGo before and I’m trying to figure out what was done 10 years ago.

Specifically, I’m trying to capture when a reLink event occurs. It was never implemented - if a user relinks a node, the underlying model isn’t changed at all. In our document listener, I’ve added a handler for JGoDocumentEvent.CHANGED but it is called 4 times the number of links. I’m guessing it is called once for each little square along the path of the link.

My question is, how can I cut through all that clutter and find the node unlinked and the node newly linked?


#2

Instead of looking handling the JGoDocumentEvent.CHANGED event, you can handle the JGoViewEvent.LINK_RELINKED event.


#3

Thank you for your reply. I would love to do that but this ancient version of JGo doesn’t define LINK_RELINKED! I can’t find anything else to use but CHANGED. But there has to be a way to use that to do what must be done. Clearly the view changes so I must be able to figure out what changed programmatically.

The problem is that, when I relink a link in the document, a bunch of CHANGE events are generated as follows. I have to find a way to sift through those and find which one is the real relink.

What I’ve inherited is a family of node classes which have JGoArea as a base class. The links are not modeled explicitly. When a link is changed, the callback generates a pile of events of which only one is the real link event.

Link from Monitor3 to Condition
Link from Start to Script
Link from Application1 to Script
Link from Script to Monitor3
Link from Condition to End
Link from Condition to Application1
Link from Condition to Application1
Link from Condition to Application1
Link from Condition to Application1
Link from Condition to Application1
Link from Condition to Application1
Link from Application1 to Script
Link from Application1 to Script
Link from Application1 to Script
Link from Application1 to Script
Link from Application1 to Script
Link from Application1 to Script
Link from Condition to Application1


#4

I suggest you override JGoView.reLink,
because before you call the super method, you can examine the oldlink argument to see what it was connected to before.


#5

Thanks!! That was very helpful!

I did as you suggested but, when I examine the oldLink one part of it is not specified, depending on whether I relink the “from” end or the “to” end. To be specific, oldLink.getToPort().getParent() returns null so I can’t tell where half the link was linked before it was reLinked.

In case that wasn’t clear, here is what I am seeing:

When I reLink the “to” part of the link, I get:

OLD link was from Condition to ???
NEW link is from Condition to Script

When I relink the “from” part of the link, I get:

OLD link was from ??? to End
NEW link is from Application1 to End

Unfortunately the missing piece of info is very important to make sure the model is in sync with the view.

Is that normal (remember this is a very old version)? Is there a way to get the entire oldLink?

Thanks! :)

Jim


#6

Ahh, now I get it. startReLink() is the key. :)

I’m such a newbie! LOL.