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.
dev build 200806111204 1) Create a new JTextArea, the default font is Tohama 11 (at least under my system) 2) Create a second JTextArea alongside it, change the font to Tohama 12 Run the code. The JTextArea with "Tohama 11" will actually use Courier or something under the hood whereas the "Tohama 12" one will use the correct font. If you look at the actual code, Netbeans does not generate a setFont() instruction for "Tohama 11".
This bug only occurs if I have "UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());" before initComponents(). If I move it after initComponents() the problem goes away. It isn't clear why this is the case.
*** This issue has been marked as a duplicate of 38145 ***
Please explain why you believe this is a duplicate. In my case I am initializing the components using the same L&F as used in the Form editor, as mentioned in comment #2. Why does running UIManager.setLookAndFeel() before initComponents() cause this problem?
> Please explain why you believe this is a duplicate. Note the Summary of this issue. It complains about missing setFont() statement in the generated code. Issue 38145 explains that - Tahoma 11 is the default font on your system and we don't generate set<Property>() statements for default values. The rest of your description seems like a misunderstanding of UIManager.setLookAndFeel(). This method should be called before any Swing component is created. If it is called later then SwingUtilities.updateComponentTreeUI must be called on the root of every component tree to update UI of these components to match the new look and feel. Hence, you should call UIManager.setLookAndFeel() in main() method before new YourForm().setVisible(true); If you call it in the constructor of YourForm() then you should call also SwingUtilities.updateComponentTreeUI(this); otherwise the form will be partially initialized with the old (e.g. the default) look and feel.
1) Using SwingUtilities.updateComponentTreeUI(this) in the constructor does not help. 2) Using UIManager.setLookAndFeel() in main() before YourForm().setVisible(true); does not help either. I'm attaching a minimal testcase. Play around with the code yourself and you'll see I'm right. The middle panel (using Tahoma 11) renders using the wrong font/size even if you do the right thing.
Created attachment 63282 [details] Minimal Testcase
> I'm attaching a minimal testcase. Play around with the code yourself and you'll see I'm right. Could you, please, explain what is your problem exactly? It is still not clear to me. I am not able to see anything wrong in the attached test-case. Tahoma 11 is not the default font for JTextArea on my machine. Hence, when I execute the attached form then the middle JTextArea uses completely different font (as it should). If I set its font to Tahoma 11 then the corresponding setFont() is generated and is (of course) used during execution. It seems that you see Tahoma 11 as a font of newly created JTextArea in GUI builder when NetBeans IDE is run on Windows look and feel. What font is used by your JTextArea when your application is executed in Windows look and feel? I guess that you complain that it is not Tahoma 11. Unfortunately, I am not able to reproduce it.
Right, so the problem is as follows: 1) When I created the testcase in the form editor, the default font for JTextArea was "Tahoma 11" and it displayed correctly between the two other JTextAreas (one both it, and one below it). 2) However, when I ran the testcase, the middle JTextArea suddenly rendered with something other than "Tahoma 11" (I have no idea which font it is) It is my understanding that in both cases (Form editor and Runtime) the Windows/System L&F is being used. The crux of the matter for me is this: if Tahoma 11 is not the default font for JTextArea under the Windows/System L&F then the Form editor should not display it as such. The Form editor and Runtime views should match 100%. Would it be possible to find someone running Windows XP or Vista which can run this testcase? It is my understanding that Tahoma 11 is the default font for JTextArea under these platforms.
> 2) However, when I ran the testcase, the middle JTextArea suddenly rendered with something > other than "Tahoma 11" (I have no idea which font it is) What about to try System.out.println(jTextArea2.getFont()); > The Form editor and Runtime views should match 100%. Yes, that is the goal that we are trying to achieve. > Would it be possible to find someone running Windows XP or Vista which can run this testcase? > It is my understanding that Tahoma 11 is the default font for JTextArea under these platforms. I am running Windows Vista and Tahoma 11 is not the default font for JTextArea on Windows look and feel on my machine. In fact, it is not the default font on your machine according to your description. The default font is the one you see during execution of your form. So, the question is why JTextArea has Tahoma 11 font by default when you create it in NetBeans GUI builder. What JDK do you use? Do you use any special command line argument when running NetBeans? Did you modify any font-related setting in NetBeans?
Here is what I get when I fire off getFont(): font1=java.awt.Font[family=Tahoma,name=Tahoma,style=plain,size=10] font2=javax.swing.plaf.FontUIResource[family=Monospaced,name=Monospaced,style=plain,size=13] font3=java.awt.Font[family=Tahoma,name=Tahoma,style=plain,size=12] To answer your other questions, I am running Windows Vista x64 under JDK build 1.6.0_10-beta-b25. I didn't change any font-related settings in Netbeans as far as I can tell, but I do note that the "Netbeans" color profile (which I am using) has "Monospace 13" as its default font. I wonder why the Form editor thinks differently.
Thank you for the additional information. Finally, I was able to reproduce the problem. It doesn't happen with JDK 5 and JDK 6 Update 6. It happens with JDK 6 Update 10 only.
If it is a bug in update 10 I need to report it to Ingrid at Sun as soon as possible (so they can fix it before it goes final). Is it possible for you to investigate very briefly whether the problem lies in Netbeans or the JDK?
It is not a problem in JDK 6 Update 10. It is a problem in NetBeans. The design of UIManager and UIDefaults is not very good from GUI builder's point of view. We have to include a lot of hacks to shield the components in the designer from NetBeans specific look and feel modifications. These hacks, unfortunately, must depend on some private implementation details. JDK 6 Update 10 change one of the details we depend on - it added MultiUIDefaults.entrySet() method. I have rewriten the affected hacks to reflect that. Modified file: http://hg.netbeans.org/main?cmd=changeset;node=568bdf9f5502
Changing the target milestone - release65_m1 branch was created just before this commit.
*** Issue 146180 has been marked as a duplicate of this issue. ***