This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
[ BUILD # : 200509261930 ] [ JDK VERSION : 1.5.0_04 ] If the entry/exit point of an object in the flow designer is moved, and the transition from that point to another object has been reshaped, the transition changes back to it's original path. Don't know if this is understandable, please see the attached screenshots for a clearer understanding of the problem.
Created attachment 25321 [details] Original layout
Created attachment 25322 [details] Changed the shape of the transition
Created attachment 25323 [details] Moved the entry point
The transition to watch is the one originating at the SplasScreen and ending at the WaitScreen.
This is caused by: When a node is moved, then all its ports are moved too. All moved ports invoke rerouting of all transitions that are attached to them. The same applies to a port which is manually moved or changes its logical order. I am closing this issue as WONTFIX because it is as designed. If you think this is a bug, feel free to reopen this issue and add your proposal of correct behaviour.
I certainly think this behaviour needs a change. Of course the route might need to be retraced, but the shape assigned by the user should take preference over the concieved "best" route designed by the IDE. If the design get's a bit messy in the process, leave it up to the user to sort it out after the move. In the example I provided in the screenshots, it's a bit excessive to reset the whole route to it's original shape, dont't you think? Just imagine what would happen if there were a few dozen screens with manually adjusted routes and hours spent getting a clean, readable layout, and then you need to add another screen. To keep you layout clean and organized you realize that you need to move ports, which results in several of your routes reverting to their original paths.
I just noticed that the retracing affects all paths connecting to any port on the component. This makes me even more convinced that this behaviour has to be remodelled.
Sounds resonable. I am thinking about it and fully agree that your second case is a bug. I would propose to do: 1) When a user changes a position of a control point of a transition, then the transition is locked and will not be automatically rerouted 2) There will be add/remove control point actions available (probably in the popup menu on the transition). 3) It will be possible to freely move control points. Control points will be using snap-to-grid feature. This change sounds more like a feature than a bug fix.
That sounds like a good solution. Of course I realize that it might be hard to make this change for the upcoming 5.0 release, but IMHO the visual designers are the flagship features of the Mobility Pack, and should be given pretty high priority. At least the case of retracing of every point should probably be addressed for the 5.0 release (again, MHO).
I would like to fix the case of retracing of every point as soon as possible but currently it is very risky because of implementation of property change events in GraphLib/FlowDesigner. Therefore I am scheduling fix of this issue for next release where it should be fixed as proposed.
Sounds reasonable to me.
set TM according by David's comment to 5.1
moving to mobility component
Setting Target Milestone to Dev
Designer 1 has been removed from NB 6.0 therefore resolving issue as WONTFIX. Designer 2 has the same issue filed already - see issue: #108296.
Verified B2 Agree
close old issues