#144 closed defect (fixed)
GINY: In submodules arcs point to the wrong anchor of the target node
| Reported by: | mirschel | Owned by: | mirschel |
|---|---|---|---|
| Priority: | major | Milestone: | Promot 0.8.3 |
| Component: | PromotGuiVizNav | Version: | 0.7.2 |
| Severity: | fatal | Keywords: | giny, arrow, arc, explorer |
| Cc: |
Description
Using GINY, in submodules arrow heads pointed to the anchor of the source or target module. Probably something goes wrong with the calculation of intersection of source or target module and the arc. The problem can be manually fixed by adding a handle to the arc. When deleting the handle afterwards the the problem occurs again. Needs more testing.
Change History (3)
comment:1 Changed 16 years ago by mirschel
- Status changed from new to assigned
- Summary changed from GINY: In submodules arcs point to the wrong anchor of the source or target module to GINY: In submodules arcs point to the wrong anchor of the target node
comment:2 Changed 16 years ago by mirschel
- Resolution set to fixed
- Status changed from assigned to closed
fixed with r8768.
comment:3 Changed 15 years ago by mirschel
- Milestone changed from Promot 1.0 to Promot 0.8.3
Note: See
TracTickets for help on using
tickets.
It is the method for updating the source and target node (updateTargetPointView() --> updateEndPointView()) which leads to the intersection calculation. However it has something to do with the handlePointList.size. Is handlePointList greater than 0, all is fine independent of !globalScale. Is handlePointList equals to 0 than the ev with !globalScale = 1.0 is ok, the ev with !globalScale = 0.2 is is buggy. HandlePointList equals to 0 means: if there are no points in the list, use the point opposite to the targetPoint... the sourcePoint. Generally, the problem is independent of shape (different calculation of ellipse and polygon) and size of target node, means the error is somewhere before in the method.