I have a number of various components in a very large JavaEE application. As such, debugging is a pain, and sadly I cannot provide an SSCCE that accurately depicts the problem I'm having.
In a nutshell, somehow my fonts change by themselves for things like JLabels and JTabbedPanes. Without ever touching them, they're being repainted as bold, italicized, dramatically changed in size, or any combination thereof.
Simple question: why?
If I step through the Eclipse debugger, no changes are made, ever. So time is somehow a factor.
I'm still a Java grasshopper (working by myself), and haven't built this program in such a way that the EDT is a sacred object. I'm worried that because I'm potentially not making all repaint() calls on the EDT that the JTabbedPane, JLabel and other font properties are being reset and repainted.
EDIT:
Forgot to say that I'm constrained to Java 1.5.
I think I've narrowed it down to an issue with using HTML in JLabels and JTabbedPane tab titles...but past that I've got no idea. With regards to the JTabbedPane, it's going into the drawing methods with the right Font/FontMetrics objects, but for whatever reason it will very rarely (sometimes more often; still haven't figured out the timing trigger) switch up what font, style, and even size at which it's painting the text.
Related
Simple as the title says. They just won't appear. I don't know why. BTW, The table is added on a panel that has setLayout(null); So, I don't know if that affects it. I just really don't know where the problem is coming from. I'm completely clueless.
DELETED
Change DisplayTab.add(table); to DisplayTab.add(scrollPane); and make use of appropriate layouts
Avoid using null layouts, pixel perfect layouts are an illusion within modern ui design. There are too many factors which affect the individual size of components, none of which you can control. Swing was designed to work with layout managers at the core, discarding these will lead to no end of issues and problems that you will spend more and more time trying to rectify
I'm using JavaFX 2 for UI. I'm having to put a lot of text inside of a TextArea; loading anywhere from 500KB to 1MB of text into the TextArea.
When doing this my UI is running slower with the BorderPane layout when resizing the panes. Is there a specific method to speed this up? Another UI component that I should be using?
Seems, there is no better component for JFX text rendering now. You can rely on TextArea, or try textNode in stack pane as option. But nothing better.
There is an issue about preformance of TextArea : javafx-jira.kenai.com/browse/RT-16853
What I can suggest : you can implement your own component, which will have restricted functionality, but tweaked for performance : just understand, which part of text you must show, and create a Text node, which will render only very restricted part of text. And a piece of technical fantasy and straight hands.
Also, if you wish, you can fix the issue in existing TextArea, and push the fix into OpenJFX, and possibly, push the fix into existing JFX (8.0 version).
Also, you should try 8.0 version, because it actually contains significant performance fixes and improvements.
I am working with an application that is experiencing painting issues on some users computers when the mouse passes over the tabs in a JTabbedPane. They also occasionally have similar issues on other interactive components like JButtons. I have only ever seen this error occur on mouse overs.
The application is being run with 1.6.0_20 and I have already tried the flag recommended in update 10 in case it was an issue with D3D (-Dsun.java2d.d3d=false).
Since I am a new user I cannot post a picture to illustrate this error. The best example I can think of is using Windows paint eraser on an image would create something similar to what I am seeing.
I appreciate any help you can provide.
Without an sscce that exhibits the problem you describe, it's hard to be specific, but this reminds me of the rendering artifact associated with setting the opaque property to true without completely rendering the area defined by a component's bounds. In particular, if you override paintComponent() and "do not honor the opaque property, you will likely see visual artifacts." Finally, the default opacity setting of some components varies by Look & Feel, so the effect may be platform dependent.
I've got a problem, that swing components in different parts of program have sometimes wrong background. For example this or this.
As I mentioned, the bug is not permanent and it can appear in one place one time and never after. But still there are some places, where I can randomly reproduce it. Unfortunately, I don't see any solutions.
Has anyone some ideas how can I fix it?
If you set your components to non-opaque (I think the call is setOpaque(false)), that will let the background colour of the component that it is on top of show through.
in addition to what Paul said, there's the question if you use self made components.
Such components should take care of their complete occupied region (or at least the invalidated regions) in the paint callback. An error seen quite often that leads to strange artifacts when moving or resizing is that only "important" parts are repainted, for example a string to be shown, without drawing the background.
In this case, anything previously blitted ther will show through.
I've created a small gui app in Netbeans. As I was adding in some buttons and text areas the mainPanel resized itself. Now it is really wide [probably 4x as wide as I want] but when I try to drag the edge in it won't resize back down. If I drag it out, making it bigger, it takes that change. I would just like to return the mainPanel back to a reasonable size. Not sure what I'm doing wrong here. I've tried to change the min size, max size, and preferred size settings for the mainPanel with no success. I've even tried to change the menuBar & statusPanel settings at the same time as the mainPanel [thinking that one of them was making the others too big] without success.
Any ideas?
Netbeans does do really stupid things like that sometimes, and I generally get around them using either of these two methods:
First thing to try is to change the layout used. Try the Grid Bag Layout, or any of the others and see if you get better results.
If that doesn't work, then probably the easiest thing to do is to change stuff in the code. You will notice that Netbeans automatically adds a call to initComponents(); in the constructor (you have to switch to Code view from Design view). And if you look at initComponents, it will have a whole heap of auto-generated code to create the GUI. Do NOT edit this, because it's just a matter of time before Netbeans overwrites your changes. What I do is to create a new method initComponentsFix, and call that immeidtaely after initComponents in the constructor. In initComponentsFix, I would add the code to resize the component to the preferred size, and any other things you you want to fix.
BTW I empathise with you - Netbeans' GUI editor is still in need of much work. However, it's code auto-generation is still very useful, so I wouldn't recommend coding the GUI the good ol' fashioned way. That's why I'm advocating using it up until you start felling its limitations, after which you "take control".
There is also a third way, which I would not recommend, is to edit the file that Netbeans stores the Design view in, which is basically shares the same file name as your frame's class' source code, except with a .form extension.
This file is XML, and is pretty easy to edit. I don't recommend this because it is sorta going around the back door, but as a last resort, you can still try it.