There are certainly cases when we could do better, but in general the problem 
is not that we would set or reset the size of the container, but the opposite - 
we do no changes. And in many cases the size simply can't be maintained.

A container with "free design" defines fully its size and appears to its parent 
as having the preferred size (so no specific size is set in the parent layout). 
Thus when you change the layout of the inner container, it may change its size 
because its preferred size changes with the new layout.

If the inner container is empty and the parent container has the "free design", 
then switching layout in the inner panel should probably keep the size in the 
parent container - by setting specific component size in the parent layout. 
However, I'm not sure if this should be done for non-empty containers. Probably 
yes if changing to AbsoluteLayout/Null.

Perhaps the same could be done if the parent layout is Absolute/Null. But for 
the other layout managers there is no direct control over the components' sizes.

By maximized mode you mean you invoked "Design This Container" action on the 
container? Here the container spans whole designer and the "visible" size does 
not have to match the real size in the parent container. Changing the layout 
should not change the designer size except growing due to changed minimum size. 
(This seems working to me in 6.0 dev.)

Well, surely the fact that the user has expressed (by resizing) a different
preferred size for the container has greater priority than its own preferences 
:-) (in FreeDesign layout, that is. Of course in other layouts the size is
determined by the parent, but I'm speaking about FreeDesign, and possibly null
layout) 

(BTW by "maximized" I mean just that the designer tab occupies the whole IDE window)

As for "I'm not sure if this should be done for non-empty containers", I
disagree. Here's my particular (real) case : I start with a panel resize it and
align it and start placing components. Now suddenly I decide " What the heck,
I'd be better with a flow layout rather than placing the component with gaps and
so". So I change the layout to flow and suddenly BAM! - chain reaction : the
panel resizes, all components anchored or somehow related to it change, and they
trigger some other change and...you get the picture (and this is componunded by
the fact that undo fails occasionally).

My suggestion is that after changing the layout of a container (whose parent
allows sizes to be manually specified) and before anything else, the IDE should
resize the container to whatever the previous dimensions were. It matches the
intuitive notion that things that that affect only the interior of something (in
this case, how this something arranges and sizes its children) should not affect
the outside.

I understand you case, however we need to take into account the consequences of 
setting the specific size of the changed container and ignoring its new minimum 
size. Setting absolute size is bad.

As I said in my first report, the starting dimensions do not conflict with the
new layout because after changing the layout, the container can be resized again
to the starting size. Nobody is talking about ignoring minimum dimensions. I'm
just talking about preserving something that was, and that is non-conflicting.

As for "absolute size is bad", well this is a matter of preferences, target
market and many other things, among them simply personal taste. I'll point out
that there are thousands of applications that have done and are doing perfectly
fine (and leading markets as well) without resizing every single minuscule
component or icon when a window resizes. Just like an IDE shouldn't force the
coding style (or whatever) of its authors to me, a GUI designer tool shouldn't
force the authors' personal preferences or beliefs about what is good or bad,
either. Especially considering that we are talking about containers handled by
FreeLayout.

Personal judgements aside, I think that we can agree that the fact that 
1) an absolutely sized container changes its *inner* layout to something else
that *does not conflict* with the starting absolute size (i.e. minimum size <=
original size) and
2) the change results in a completely altered *outside* design
is a designer bug - for whatever reasons down the chain of calls - and it should
be fixed.

The absolute sizes are not bad because of resizing, but because of different 
platforms the UI may run on. If you are sure you run your app always in the 
same look&feel and localization, you can do that, but that's a rather special 
case.

> 1) an absolutely sized container changes its *inner* layout to something
> else that *does not conflict* with the starting absolute size
> (i.e. minimum size <= original size)

If you have a panel with three buttons positioned vertically in a column and 
the panel size is just enough to display the buttons, then changing it to 
FlowLayout violates the minimum size of the panel. FlowLayout's minimum size is 
computed trying to put all components on one line. Now you force it to wrap, 
but the result will depend on the target look&feel or localization - it may 
lead to clipping the components or placing two on one line, etc. This is what I 
don't like. In the originally free design-based layout this was not the case, 
even if you sized the container to certain size. It will always make sure there 
is appropriate space (provided you did not make it smaller than min size).

> 2) the change results in a completely altered *outside* design
> is a designer bug - for whatever reasons down the chain of calls
> - and it should be fixed.

I understand the user impact - in some specific situations. Maybe you are right 
and switching silently to absolute size from correct default size is less evel 
than potentially destroying the user design. I'm not saying we are not doing 
it, I just have not decided yet. Could you attach your form here (or send it) 
so I have more exact idea? Thanks

> The absolute sizes are not bad because of resizing, but because of ...

I know I know, I wasn't pretending to be exhaustive. I simply wanted to point
out that absolute sizes are not an absolute evil to be banished :-)

> If you have a panel with three buttons positioned vertically in a column and 
> the panel size is just enough to display the buttons, then changing it to 
> FlowLayout violates the minimum size of the panel. FlowLayout's minimum size 
> is computed trying to put all components on one line. 

Well, this is a different issue you are pointing here. If the minimumLayoutSize
is interpreted as a "minimum area", then it is a mistake to consider separately
each of the longitudinal dimensions as a minimum value. If instead the
minimumLayoutSize is interpreted as a set of two minimum longitudinal sizes,
then Flowlayout is simply lying (=method contract breach) because obviously the
minimum width is not minimum if the container can live with a smaller one. But
that's not the point.

The point that I'm trying to make is that if the container with the new layout
can live on with the dimensions of the old one, there's no reason for not
keeping them. 

>I just have not decided yet. Could you attach your form here (or send it) 
so I have more exact idea? Thanks

I'm afraid the design changed since then so I don't have the original one, but
since I'm trying very hard to use the NetBeans GUI designer and to report
anything strange I find for the benefit of all as soon as I get to another case
I'll attach it here.

Thanks for your patience, by the way :-) 

According to the discussion above it seems that it might be possible to do better in some cases, but that it is mostly 
a matter of preference. There are strong arguments both for and against this change. It clearly is not a pure defect. 
Hence, changing the issue type to enhancement.

*** Issue 139022 has been marked as a duplicate of this issue. ***