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 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.
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.
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?
Created attachment 33182 [details] Please try this form (no package for this file)
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.
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 resizing.
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.
> 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. jButton1.setBounds( 110, 150, jButton1.getPreferredSize().width, jButton1.getPreferredSize().height); 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!
*** Issue 83370 has been marked as a duplicate of this issue. ***
*** Issue 74762 has been marked as a duplicate of this issue. ***
*** Issue 86649 has been marked as a duplicate of this issue. ***
*** Issue 57578 has been marked as a duplicate of this issue. ***
*** Bug 185541 has been marked as a duplicate of this bug. ***
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); to: * 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./
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.
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.
If changing: jLabelScraperDescription.setBounds(10, 290, 360, -1); to: 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.
*** Bug 192507 has been marked as a duplicate of this bug. ***
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: http://hg.netbeans.org/core-main/rev/90391d24f846