Summary: | ShortestPathConnectionRouter cannot count correct router | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Tools] GEF | Reporter: | zhang wei <zhang-wei> | ||||||
Component: | GEF-Legacy GEF (MVC) | Assignee: | gef-inbox <gef-inbox> | ||||||
Status: | NEW --- | QA Contact: | |||||||
Severity: | normal | ||||||||
Priority: | P3 | CC: | nyssen, wang-wei | ||||||
Version: | 3.1 | ||||||||
Target Milestone: | --- | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
zhang wei
2005-04-06 02:55:22 EDT
Created attachment 19584 [details]
this pic show the bug
this pic show the bug
Created attachment 19585 [details]
another pic show the bug
Aah. Good test cases. The picture in comment 1 is working as designed. If a connection starts inside the bounding box of another obstacle, that obstacle ignored, which is what you are seeing. I think we're having a similar problem with our figures (see the "another pic show the bug" picture), where the router pulls the line unnecessarily towards the other figure. In our case however, the figures are not overlapping... (we're also using the most recent Eclipse/GEF 3.2 milestone releases as of the beginning of January) After looking at the situation in comment 2, that's not a bug in the algorithm. The connection anchor's reference point is probably the center of the circle. So, SPCR is going to route from the center of the circle to the destination. After it routes, the anchor is asked to provide it's connection point closes to the nearest bendpoint, which then ends up being on the outside of the circle instead of its center. One possible fix might be to use attachment points at the beginning, then updating them at the end, but there will still be strange cases. Chris, please provide a snippet of draw2d that shows the problem you are having. |