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
Related
I create a little program that load a frame in which I added some panels.
When I click on some button it should show some panels and hide other.
I'm experiencing some difficult to do it, even because I don't really figure out the diference between setVisible(true), repaint() and validate() (that some friends of mine suggested to me).
I hope you can make me to understand!
Thank you.
Carefully read the API for JComponent. The usages are:
setVisible - it will hide or show your component altogether. If you set it as false, you won't see it at all.
repaint() - is called when the actual pixels need to be redrawn, this is done automatically. It's used, for example, when you move a window on top of your GUI and then move it away. The part that was covered needs to be redrawn.
validate() - you should call this when the layout of your GUI has changed and you need the manager to replace and redraw your GUI.
It's a bit more complicated than that, so again, carefully read the API.
setVisible(true): sets the component so that it's visible.
repaint(): calls the paint method on the component.
revalidate(): updates the component based on the root component
I have an undecorated JFrame which has a lot of components inside it (such as JSplitPanes, JPanels with GridBagLayouts, BoxLayouts, BorderLayouts etc). The code of building this JFrame is 2500 lines length, so I wouldn't place it here, or it's simpled version, sorry.
When I drag the JFrame by right or bottom side, it resizes OK, but when I drag it by left or top side, the components inside the JFrame are twitching a lot, so it looks very ugly.
My question is: Why does it happen? How can I prevent it (if I can)? Does anyone fix that in own practice?
UPD: I've written my own resizer for JFrame. It works OK for other windows, which have less amount of components.
Resizing the frame implicitly validates the enclosed Container, which causes doLayout() to be invoked on the affected components each time the size changes. You can see a similar effect in repeated calls to paintComponent() when resizing this AnimationTest. As you observe, using thousands of components scales poorly. As an alternative, leverage the flyweight pattern to render only visible cells, as is done in JTable, JTree, JList, etc. If you can't use one of these, CellRendererPane, seen here, may help.
I have a JPanel view inside a JScrollPane. The Jpanel paints some shapes which has to change dynamically in order to reflect a changing datamodel.
I have implemented a timer that should repaint the JPanel/JScrollPane which works fine unless that it resets the scroller. The scroller has to remain at its position (where the user has scrolled to).
I have tried to repaint the JPanel, the JScrollPane, the viewport of the JScrollPane etc, but noting seem to solve this problem.
Do you have a hint? The code is quite large so it is hard to isolate an example.
On the swing timer do not much concerning the GUI, just scrollPane.repaint(50L);. Especially refrain where not needed from layouting calls: (in)validate.
I have now isolated the code only to find out that it works isolated. It seem to be related to the context (a very complex form) that it is put in. Now a SSCCE is completely impossible, but any input is still appreciated.
I wanted to ask whether it is possible to get the correct sizes of an JPanel after it has been placed in another JPanel that uses GroupLayout as Layout Manager. I have already tried to use:
.getPreferredSize(): this results in the Preferred Size that has been set by me, not the actual size that is drawn on the JPanel in the frame (if frame get's resized, the element will expand horizontally; which is not seen in the values).
.getSize(): it returns 0.
.getHeight(): it returns 0.
.getWidth(): it returns 0.
Maybe the positioning of the code is relevant, but it is executed AFTER shown on screen so it should not matter.
To force it to do that after it is shown on screen, maybe I can use EventQueue, but I'm not sure how.
Thank you for your answers!
You can get the "correct" size of the component only after it has been rendered, either by calling pack or setVisible(true) on the top level container.
Maybe the positioning of the code is relevant, but it is executed AFTER shown on screen so it should not matter.
Then something's not right. Are you sure that you're calling these methods on the visible components and not some variables that shadow them? Without code it's hard to tell where your error lies.
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().