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.

Bug 65403 - [50cat] Flow design transitions changes shape
Summary: [50cat] Flow design transitions changes shape
Status: CLOSED WONTFIX
Alias: None
Product: javame
Classification: Unclassified
Component: Visual Designer (show other bugs)
Version: 5.x
Hardware: PC Windows XP
: P3 blocker (vote)
Assignee: David Kaspar
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-29 17:52 UTC by malakim
Modified: 2008-09-10 15:56 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Original layout (86.71 KB, image/png)
2005-09-29 17:53 UTC, malakim
Details
Changed the shape of the transition (85.99 KB, image/png)
2005-09-29 17:53 UTC, malakim
Details
Moved the entry point (86.05 KB, image/png)
2005-09-29 17:54 UTC, malakim
Details

Note You need to log in before you can comment on or make changes to this bug.
Description malakim 2005-09-29 17:52:51 UTC
[ 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.
Comment 1 malakim 2005-09-29 17:53:17 UTC
Created attachment 25321 [details]
Original layout
Comment 2 malakim 2005-09-29 17:53:58 UTC
Created attachment 25322 [details]
Changed the shape of the transition
Comment 3 malakim 2005-09-29 17:54:26 UTC
Created attachment 25323 [details]
Moved the entry point
Comment 4 malakim 2005-09-29 17:57:05 UTC
The transition to watch is the one originating at the SplasScreen and ending at
the WaitScreen.
Comment 5 David Kaspar 2005-10-03 14:45:17 UTC
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.
Comment 6 malakim 2005-10-03 15:33:11 UTC
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.
Comment 7 malakim 2005-10-03 16:42:04 UTC
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.
Comment 8 David Kaspar 2005-10-03 17:22:59 UTC
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.
Comment 9 malakim 2005-10-03 17:33:11 UTC
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).
Comment 10 David Kaspar 2005-10-04 14:44:53 UTC
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.
Comment 11 malakim 2005-10-05 07:18:18 UTC
Sounds reasonable to me.
Comment 12 Lukas Hasik 2006-01-06 13:21:14 UTC
set TM according by David's comment to 5.1
Comment 13 Lukas Hasik 2006-06-23 14:42:41 UTC
moving to mobility component
Comment 14 David Kaspar 2006-08-14 11:04:00 UTC
Setting Target Milestone to Dev
Comment 15 David Kaspar 2007-07-11 09:02:56 UTC
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.
Comment 16 Fabiola Rios 2007-10-30 14:07:32 UTC
Verified B2
Agree
Comment 17 Ivan Sidorkin 2008-09-10 15:56:45 UTC
close old issues