Re: [gef-dev] ChopboxAnchor/AutomaticRouter bug?

[Randy Hudson <hudsonr@xxxxxxxxxx>]

The problem you are seeing is fixed
in more recent builds.  It is related to a ListenerList removing the
wrong listener because it was removing using .equals() instead of ==. The
equals() for ChopBoxAnchor is working properly.

Sapna George <sgeorge@xxxxxx>
Sent by: gef-dev-admin@xxxxxxxxxxx

02/18/2005 04:33 PM

Please respond to
gef-dev

To	gef-dev@xxxxxxxxxxx
cc
Subject	[gef-dev] ChopboxAnchor/AutomaticRouter bug?

My problem:

"My polyline connection uses ChopboxAnchors and
FanRouter+BendpointConnectionRouter like in the Logic example. However,
if i
move a node with two or more connections, one one of the connections move
along with the node. The others stay hanging in the original place. If
i
click on any of these dangling connections, they refresh and fix themselves
to the node automatically."

I debugged a little and found that ChopboxAnchor and AutomaticRouter have
certain behaviors that might be leading to the above problem: 
1. The automatic router (FanRouter in my case) groups together all anchors
on 
mulitple connections that are at the same "location" using a
HashKey. This is 
so that it can take approriate handleCollision action. In the case of 
FanRouter, it inserts an additional bendpoint inorder to fan out. It order
to 
find out if 2 anchors on different connections are at the same location,
the 
router expexts the Anchor class to implement the equals method and the
getHashCode method. 
2. The equals method in ChopboxAnchor returns true if the two chopbox anchors
belong to the same figure irrespective of the location of the anchor on
the 
figure.So, two anchors may be at opposite sides of the figure, but will
still 
return true. This should not be the case, in my opinion. Only a new anchor
that is at the exact location as an exisiting one should return true. A
new 
anchor at the opposite side of the figure should return false.

So, I modified ChopboxAnchor behavior to as follows and there is some 
improvement:

protected Point locationPoint; // new variable to store anchor location.

public Point getLocation(Point reference) { // super class is ChopboxAnchor
  locationPoint = super.getLocation(reference);
  return locationPoint;
 }

public boolean equals(Object obj) { // returns true only if the location
of 
both anchors
                    
                     
         // is exactly the same.
  if (obj instanceof MyChopboxAnchor ) {
   MyChopboxAnchor other = (MyChopboxAnchor )obj;
   if (getLocationPoint() != null && other.getLocationPoint()
!= null)
    return other.getOwner() == getOwner() && 
other.getLocationPoint().equals(getLocationPoint());
  }
  return false;
 }

After implementing this, the above dangling problem is not caused for ALL
connections on a node. It is caused for ONLY those connections using anchors
at the same location on the node boundary. i.e. if the node has 2 connections
on two opposite sides, moving the node WILL NOT leave some connections
dangling.

For those connections that DO have anchors at the exact same location,
Here's 
what is causing the dangling problem. But i have no idea where it is being
caused and how to fix it:

At some point, by some class, the connection figures get removed from the
list 
of AnchorListeners in the ChopboxAnchor. This occurs for all connections
except the last one added to the figure. I found this by moving the node
figure and debugging ancestorMoved(IFigure figure) method in 
AbstractConnectionAnchor class. Inspecting the variables in the class shows
that all anchors except one, on the figure had AnchorListener = null even
though they have connections associated with them. Therefore if the node
figure is moved, the connections do not receive anchorMoved events and
the 
connections are left dangling!

I tried a lot to find out where this was occuring, but i was unsuccesful.
Can 
any of the experts help?

thanks

_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/gef-dev