I have a Java swing application with a panel that contains three JComboBoxes that do not draw properly.
The combox boxes just show up as the down arrow on the right side, but without the label of the currently selected value.
The boxes will redraw correctly if the window is resized either bigger or smaller by even one pixel.
All of my googling has pointed to calling revalidate() on the JPanel to fix this, but that hasn't worked for me.
Calling updateUI() on the JPanel has changed it from always displaying incorrectly to displaying incorrectly half of the time.
Has anyone else seen this and found a different way to force a redraw of the combo boxes?
Can you give us some more information on how you add the combo boxes to the JPanel? This is a pretty common thing to do in Swing so I doubt that it's a JVM issue but I guess anything is possible.
Specifically, I would double check to make sure you're not accessing the GUI from any background threads. In this case, maybe you're reading the choices from a DB or something and updating the JComboBox from a background thread, which is a big no-no in Swing. See SwingUtils.invokeLater().
Related
I have written a Swing UI that has a JPanel with numerous controls and on the right hand side a few columns of JCheckBoxes. This is all handled by making the JPanel use a GridLayout. The problem I am having is that a given checkbox toggles it's selection status no matter where in it's grid "cell" you click in. Note, I am not using a JTable approach. The "cell" is just the rectangular area of the screen the GridLayout gave to the checkbox. It can be much bigger than the checkbox. I can't figure out how to make sure the checkboxes are only selectable when you click in the tiny box of the drawn control (not the big box of the "cell" that the checkbox is basically centered in). I've googled a lot and everyone talks about JTables. Again, I am not using a JTable. This issue is causing headaches for my users as they click on the application window and accidentally select an option!
The GridLayout forces all UI components to fill their cell completely, so the actual checkbox only gives the illusion that it's smaller than the cell it occupies. The solution here, as with many other more complex UI designs, is to use multiple layouts nested inside one another.
In your case, try putting all your check boxes inside a BoxLayout and using glue to space them as needed. This BoxLayout should be placed side by side with your GridLayout in another enclosing container (either a JPanel or your ContentPane -- I can't say for sure because you only gave a brief description of your UI with no code or illustration).
Play around with the idea of nesting layouts until you get something you like, and don't forget to try resizing your window to see what the layout manager does under the circumstances. The final appearance isn't always exactly what you imagine it will be.
I have a JPanel (pNums) which contains another JPanel (pGrid). pGrid itself contains a grid (JLabel[][] in a GridLayout) of labels. There is a mouse listener which catches events from pGrid and does fairly important stuff with them (as in, the entire functionality of the program relies on the mouseClicked() event). This works perfectly, exactly the way I wanted it to... until I add tooltips to the labels.
As soon as I call JLabel.setToolTipText("SomeString") the listener stops reacting to events (I have tried most, if not all of the mouse events, none of them seem to be called).
I am sure that it is the tooltips by the way, commenting out the setToolTipText() completely fixes the problem. Of course, since I needed the tooltips, it also causes a whole host of other problems.
I've looked around and while I haven't found anything quite right, I get the impression that I just chose a really bad way to do what I wanted. But I also want to know for sure.
Can I get both the event and the tooltip or should I go back to the drawing board.
I think you might be able to "fix" this issue, with setting delay on tooltip appearance. But once it will appear user will have to click to hide it anyway.
http://docs.oracle.com/javase/7/docs/api/javax/swing/ToolTipManager.html
The reson for this might be, that tooltip itself needs mouse click, to hide.
My friend is facing an issue where in he has a Swing Dialog and it has several text fields, combo boxes and radio buttons. Also it has a JPanel which holds the search results if at all the user wants to perform any search.
It looks fine with normal font size. But once the font size is increased to say 150% or even 200%, then the text boxes are not growing and the text in them is growing. So, they are not fitting in and are getting clip-ed.
He managed to overcome this limitation by using the setPreferredSize method on the UI components. Now it seems that he is able to control the behaviour in case of text boxes, combo boxes etc. But the search panel is still an issue.
Could some one please point out what the issue could be?
UPDATE:
They also have a JTable where the search results are displayed. Now, the thing is, they are hardcoding the height of each row in that JTable using the call setRowHeight. And due to this, if the font size is increased, the row height still remains the same. Is there any method call that resolves this.
We honestly think that they should not have done that hardcoding. Is there any solution for this? Please share.
Thanks,
Pavan.
Which layout is your friend using? Choosing a suitable layout may help.
Try pack() it will automatically adjust the Window to fit the preferred size of the components.
I have a large JPanel embedded in a JScrollPane. When I move the scrollbar, I notice that the visible portion does not render itself and I get glitches. Whereas when I resize the frame, I can see the new visible portions rendered. So I need to know which methods are fired upon frame resize to repaint the view. What listeners/methods should I use?
So I need to know which methods are fired upon frame resize
You don't need to know that. All you need to do is change the value of the scrollbar or the position of viewport and the component should repaint itself properly. If it is not painting properly, then you have a problem with something else. Maybe
incorrect custom painting code
the code is not invoked on the EDT
If those suggestsion doen't help then you need to post a proper SSCCE that demonstrates the problem because we can't keep guessing what your code is doing.
Did you revalidate the panel?
It might be that something is not right in the code of yours.
I have been using lots of scrolls and never had an issue as you describe.
Maybe a code sample showing the problem would be nice.
Good luck, Boro
The code pretty huge and involves a lot of different class/methods:
But here is the gist:
There is a main frame : A_Main
Selecting something in the main frame A: opens a JDialog B_Dialog
This B_Dialog has a JPanel on it: C_Panel
This C_Panel comprises of a textfield and a button
On clicking on the textfield/button: opens a tooltip and another JPanel: D_Panel
Now, the problem is:
1) The tooltip overflows the size of B_Dialog and therefore gets truncated
2) D_Panel however; even if its outside the boundary of B_Dialog gets displayed fully
2.1) There are some texfields and drop down menus in this D_Panel
2.2) The mouse events function correctly in this D_Panel items (drop down menus)
2.3) But Keyboard events do not function correct (Textfield)
I would be glad if you could help!
Thanks!
This can only be done in newer versions of the JDK.
See, Mixing Heavyweight and Lightweight Components.
Now, when I try to enter something in the JAR JPanel's text field, I am not able to do so as this pops out of the border of the main JDialog that contains it.
Add a JScrollPane around the JPanel, and allow it to expand both horizontally and vertically. If this doesn't work, you may need a customized Layout Manager, or use one of the default ones like GridBagLayout.
Also, you'll need to gain focus before you can enter text, but that doesn't seem to be the problem here.