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 82583 - Strange behaviour of Preferred height/width in Null layout
Summary: Strange behaviour of Preferred height/width in Null layout
Alias: None
Product: guibuilder
Classification: Unclassified
Component: Code (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@guibuilder
: 57578 74762 83370 86649 185541 (view as bug list)
Depends on:
Reported: 2006-08-13 16:14 UTC by _ viendu
Modified: 2010-11-30 13:31 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Please try this form (no package for this file) (1.76 KB, application/octet-stream)
2006-08-23 04:32 UTC, _ viendu

Note You need to log in before you can comment on or make changes to this bug.
Description _ viendu 2006-08-13 16:14:32 UTC
I have a null layout.  Then a scrollpane and a text area inside it.  I try to
resize the scollpane's horizontal size, but after save and open the form (in
Netbeans), it goes back to the old size.  Looking in the properties panel, I see
that the value was set as Relative.  I change that by set in a number instead. 
Now, I save and open and it keeps the size.  I think in null layout, this
relative thing should not be there.
Comment 1 _ viendu 2006-08-13 16:16:58 UTC
Correction.  The value is called "Preferred", not relative.

Additional info: I open the form, and try to resize the horizontal size again
after putting in some number, and save and open again.  The value to back to
"Preferred", and the box is small again.
Comment 2 Jan Stola 2006-08-14 11:33:00 UTC
I am sorry, I am not able to reproduce this issue. Are you still able to 
reproduce it? I tried NB 5.5 beta 2 build and the following steps:

1. Create new JFrame.
2. Set its layout to Null Layout (using context menu of the JFrame).
3. Select JTextArea in the Palette and place it into the frame - it will
   be wrapped by JScrollPane automatically.
4. Resize the JScrollPane with the JTextArea horizontally.
5. Save and close the form.
6. Reopen the form again.

Are you able to reproduce the issue with these steps? Is there anything I 
should do differently?
Comment 3 _ viendu 2006-08-23 04:32:02 UTC
Created attachment 33182 [details]
Please try this form (no package for this file)
Comment 4 _ viendu 2006-08-23 04:35:15 UTC
Yes, it appears that this is not a general problem, because I could not
reproduce it in a new form.  Please try the attachment above to see if you can
reproduce the problem.  Please select the scrollpane and resize horizontally,
save, close and open the file again.
Comment 5 Jan Stola 2006-08-23 11:47:59 UTC
Thank you for the test case - I was finally able to reproduce this issue. The 
problem is in the JTextArea that has lineWrap property set to true. Such text 
areas don't have its preferred size well defined - in fact, they have preferred 
height for a given width. Unfortunately the layout management doesn't work well 
with such components.

When you resize the component in the null layout, we try to check whether the 
actual size is equal to the preferred size and if so then we set the Width (or 
Height) layout property to special constant Preferred. Text area with a line 
wrap returns its actual width as its preferred width. That's why the Preferred 
value is always set.

AFAIK there is no solution to this problem. There is not way how to recognize 
such problematic components. As you can see from your test case the problematic 
component can be hidden inside another component.

I will close this issue as WONTFIX, but there is an easy workaround for your 
test case - switch off lineWrap before resizing and switch it back after 
Comment 6 _ viendu 2006-08-23 18:18:58 UTC
I understand the issue.  However, I think this needs to be fixed.  To users,
this is very confusing.  It's very clear that there is a way to fix this (by set
the height and width).  I am not sure why in null layout, you set these to
preferred.  Is it possible to always set them absolutely, because that's how
it's going to be displayed anyway?  Also, what if I set the horizontal scroll
for the scrollpane to never?  This means that it's logical for the wrapping
property to wrap.  I still think this is an issue.  I know it's special case,
but just ignore it for any poor user to guess is probably not a best idea.  Null
layout seems to be crazy, but lot of times, people need just that.  With all
respect, please reconsider.
Comment 7 Jan Stola 2006-08-28 17:06:17 UTC
> I am not sure why in null layout, you set these to preferred.
> Is it possible to always set them absolutely, because that's how
> it's going to be displayed anyway?

I think that the purpose of the 'preferred' value was to keep the preferred 
width/height of the component and just hard-code its location e.g.


But you are right that the generated code uses hard-coded values even 
when 'Preferred' value is used e.g.

jButton1.setBounds(110, 150, 75, 23);

There are even more problems. Consider the following scenario:
1. Add a JButton into Null layout. It will have 'jButton1' text.
2. Change the text of the button to 'Extremely long text'.
   You can see that the text doesn't fit into the button.
3. Save and close the form.
4. Open the form again. Now you can see that the text fits into
   the button nicely!
Comment 8 Jan Stola 2006-08-29 11:44:08 UTC
*** Issue 83370 has been marked as a duplicate of this issue. ***
Comment 9 Jan Stola 2006-09-05 10:25:12 UTC
*** Issue 74762 has been marked as a duplicate of this issue. ***
Comment 10 Jan Stola 2006-10-09 09:58:12 UTC
*** Issue 86649 has been marked as a duplicate of this issue. ***
Comment 11 Petr Dvorak 2008-04-29 13:41:18 UTC
*** Issue 57578 has been marked as a duplicate of this issue. ***
Comment 12 Tomas Pavek 2010-05-07 11:48:53 UTC
*** Bug 185541 has been marked as a duplicate of this bug. ***
Comment 13 xandrani 2010-05-10 00:54:41 UTC
The whole 'preferred' height / width is currently broken.

In setBounds() the preferred height and widths are qualified as -1.  This -1 should signify to the setBounds() function to get the preferred height or width that is set to -1.

For example in the Properties for a Label I have:
* preferredSize [337, 16]
* Width 360
* Height preferred <-- this line represents the -1

In the code I have:
* jLabelScraperDescription.setBounds(10, 290, 360, -1);

What the setBounds() function should first do is when it finds a -1, it should look up the preferred size and utilise that.

If I change this call:
* jLabelScraperDescription.setBounds(10, 290, 360, -1);
* jLabelScraperDescription.setBounds(10, 290, 360, 16);

The problem is fixed!  But surely the code inside setBounds should do something like (note this is pseudo code)

if (height == -1)
   actualHeight = whatever.getPreferredSize.height;
if (width == -1)
   actualWidth = whatever.getPreferredSize.width;

This would be the fix required.  The fact that the code doesn't already do this is pretty confusing to me./
Comment 14 xandrani 2010-05-10 00:57:10 UTC
I forgot to mentioned that if people agree with my fix then I'm willing to go ahead and fix this bug.  If someone more experienced can tell me where to look in the code in order to save me time then I'll attempt this fix.
Comment 15 Tomas Pavek 2010-05-10 11:52:37 UTC
It's strange this is happening even with a simple JLabel. There indeed is code that replaces -1 with actual preferred size when generating the setBounds method. It works for me. Would be worth attaching here a sample form where it is happening.

Some components like JTextArea with line wrapping or JLabel with html text that also wraps over multiple lines are not suitable for using "preferred" size, they should always have an explicit size set. However, I don't see -1 in generated code of setBounds...

Anyway, maybe using the 'preferred' constant for null layout should be eliminated and left only for AbsoluteLayout.
Comment 16 xandrani 2010-05-10 20:41:53 UTC
If changing:

jLabelScraperDescription.setBounds(10, 290, 360, -1);
jLabelScraperDescription.setBounds(10, 290, 360, 16);

Causes a behaviour change in the label being displayed correctly or not, then there is a bug in the setBounds() code.

There should be no real functional difference between:
jLabelScraperDescription.setBounds(10, 290, 360, -1); (with preferred height set to 16) and jLabelScraperDescription.setBounds(10, 290, 360, 16);

Indeed if anything I'd hope there was code similar to this:

void setBounds(x, y, width, height)
   int actualWidth  = width;
   int actualHeight = height;

   if (width == -1)
      actualWidth = [get the preferred width value here];
   if (height == -1)
      actualHeight= [get the preferred height value here];

   setBoundsActual(x, y, actualWidth, actualHeight);

Please double check the setBounds() code because it's definitely not right.
Comment 17 Tomas Pavek 2010-11-26 17:48:15 UTC
*** Bug 192507 has been marked as a duplicate of this bug. ***
Comment 18 Tomas Pavek 2010-11-30 13:31:55 UTC
As found in bug 192507, the simple case where -1 is generated for any component, happens in JLayeredPane, which also uses null layout. It does not happen in a general container like JPanel with null layout.

Fixed the JLayeredPane case: