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.
I observed this problem during working with the UML drawing tool, but I think this is a problem of the Visual Library itself. When resizing, for example by dragging the bottom right control point and then dragging over the left top point, the bounds start to move. This is the first wrong behavior as resizing should not move the bounds as a whole to another position on the screen. And furthermore, when you release the mouse button, the widget will be at at the original position, but so little, that it is not possible to catch a control point to make it big again. There are even some other problems, when the bounds were moved to another position in the described way. For example when you drag the mouse pointer back to the right bottom screen in my example, the bounds take up a lot of space. When then releasing the mouse button, the widget is back at it's orginal place (even when the bounds are somewhere else) and a bit resized (you never know for sure how big or small it will get). I suggest: When dragging over the left top edge in my example (this must logically be implemented for every edge resp. side) the bounds should not move, but just take the minimum area. And when then releasing the mouse button, the widget should be resized, but not the absolute minimum. There must be a minimum size constraint.
Actually I am not sure whether it is an issue in Visual Library. I have tried test.resize.ResizeTest example and it does not allow to go to negative width/height. By default the Resizing is activate by dragging a border of a Widget. Anyway a developer has a possibility to pre-process or limit the resizing by supplying ResizeStrategy argument to createResizeAction factory method, so it should possible to limit the minimum boundary. Please, could you create a test-case to reproduce your issue? For now, adding INCOMPLETE keyword.
Thanks for the answer. Then I move the bug to the "uml" component, cause it's obviously is one. Let's see, what the UML people say. When I have a bit time again I also investigate it further.
it's a valid uml issue, mostly resolved in 6.5
in my opinion it's fixed, may be except some object may have relativey small minimum size and may be adusted, but bouds don't move on resizing any more.