I am using JPanels to simulate a print preview and just printing the content panel, however I have ran into a problem whereby if I try to print multiple panels that are essentially the same document, only the the one currently being displayed on screen will print.
Is there a way I can force the JPanel to repaint even if it is not currently on screen?
I have tried:
Disabling double buffering via:
JComponent.setDoubleBuffered()
RepaintManager.setDoubleBufferingEnabled()
Painting Twice
Painting through paint()
Painting through repaint()
Painting through print()
I couldn't get it to paint off screen and I felt like I was wasting my time battling the Swing API so I just cheated and made the panels display on screen as they are being printed; now I have a new "feature" that shows you the page being printed.
I'll leave the question open incase someone knows how to do this as I would prefer not to shove all the pages in the user's face.
Update
Turns out the problem was with components that had extended java.awt.Container, the Swing components must override certain AWT methods that deal with this sort of rendering.
Related
I am making something that resembles a subtitle player that will go over a video.
I would like to make the background transparent so that the box that the text is in will not interfere with the movie/TV show playing behind it. I have tried 2 ways to do this and each way results in the same problem. The text does not disappear when the next sentence appears. If the background is a color (Eg: Color.red), then this works fine. After a certain time, I call text.setText("next sentence"), but this does not work with a transparent background. The relevant code is as follows. text is a JTextField
I should mention the video is not in this program. This program is ONLY subtitles.
First way:
text.setBackground(new Color(0,0,0,0));
Second way: (using a transparent image)
Graphics c = myPicture.getGraphics();
text.paintAll(c);
I update the text like this.
Thread.sleep(Graphix.subtitles.get(counter).getStart());
text.setText(Graphix.subtitles.get(counter).getText());
This also makes it overlap.
text.setForeground(Color.blue);
text.setBackground(new Color(0,0,0,0));
text.setOpaque(false);
The relevant code from Main is as follows.
final JFrame JFwindow = new JFrame("Subtitles");
JFwindow.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
JFwindow.getContentPane().add(new Subtitles());
JFwindow.setSize(1300, 150);
JFwindow.setUndecorated(true);
JFwindow.setBackground(new Color(0,0,0,0f));
JFwindow.pack();
JFwindow.setVisible(true);
Transparency is achieved by calling JPanel#setOpaque and passing it false.
You should NEVER be calling getGraphics. getGraphics and return null and is, at best, only as snap shot. Once the RepaintManager starts a new paint cycle, the results of painting to it will be overridden.
Using a tarnsparent color will only confuse the RepaintManager as it won't know that it needs to paint under the component
Sleeping within the Event Dispatching Thread (EDT) will stop Swing from performing any updates (as well as process any events). Instead I'd recommend using a javax.swing.Timer. See Concurrency in Swing for more details.
If you're using the VLC bindings, then it can't be achieved
Don't forget to make all the parent containers that the sub titles are contained in transparent as well
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
I've created an applet which has one large panel to display data surrounded by several controls (buttons, textfields, etc.). The large panel contains several layers of labels which I render myself.
The controls all have tooltips associated with them, and some of these tooltips overlap the main panel. When they disappear, they leave a hole in the main panel image until the main panel is repainted.
Now mind you, this does not always happen. It only occurs when the cursor is in a certain range. If you get far enough to either the left or right (no difference noted for changes along the Y axis), the holes are painted over when the tooltip disappears.
I'm not well-versed on how tooltips and repainting are supposed to work, and if this is a sign that there's something dreadfully wrong with my program, but if I can just call repaint on the main panel whenever the tooltip disappears, I should be fine. Is there something I can override in tooltip to make this happen?
I'm using Swing
Thanks.
To answer your question (after you found a solution by the comments): Swing has some quite elaborate repaint management built in. When a tooltip disappears, the rectangle below it is repainted.
Now, which components have to be repainted? All those who overlap with the given rectangle, and are not themselves hidden (in the region in question) by other components - but only opaque components count here. (This is the whole reason we need the opaque property on JComponent - to optimize repainting.)
Your label declared itself being opaque, but did not really paint its whole area on a paintComponent, and such the region of the tooltip which should have been covered by the label stayed unpainted.
Declaring your label to be partly transparent caused also the concerning region of the component behind it to be repainted.
For a school project I'm writing a BlackJack card game in JAVA.
After a few steps within the program, my whole computer system slows down/stutters and some areas within the JFrame turn black. No repainting seems te be happening.
I will give you some program details in words rather then submitting the code.
I have done some extensive extending of almost every GUI component to give it the look and feel that I want. Almost every child of JComponent that I use has got its paintComponent rewriten with custom image backgrounds and anti-aliasing where applicable.
In my (custom) JFrame I load an extended version of JPanel. This panel holds all the GUI components for that screen. When I want to switch screen (go to a different part of the program), I switch to another extended version of JPanel. I do this by removing all elements from the JFrame and add the new panel. These different panels implements ActionListeners and FocusListeners.
At this point my thoughts are leaning towards a thread handling issue. My theory for the moment is this: When a panel is constructed for display in the JFrame (each on different stages within te program), the previous constructed panels aren't realy 'destroyed', and the Listeners of those panels remain active.
My question for you people is, wether this theory holds ground... And in that case, is there a way to 'kill' these panels or at least stop the listening?
If my theory doesn't make sense, what else could be causing these symptoms? Could it be the extensive overwriting of the paintComponent methods?
Any ideas would be highly appriciated!
Regards Wilco
When a panel is constructed for display in the JFrame (each on different stages within te program), the previous constructed panels aren't realy 'destroyed', and the Listeners of those panels remain active.
No. Events are only dispatched to the component that has focus. It a comonents doesn't have focus then it won't received system generated events like KeyEvents and MouseEvents. So if a panel isn't visible then it won't receive events.
I switch to another extended version of JPanel. I do this by removing all elements from the JFrame and add the new panel.
This is not the best design. It is better to use a Card Layout which was designed for this purpose.
Almost every child of JComponent that I use has got its paintComponent rewriten with custom image backgrounds and anti-aliasing where applicable
Then you probably have problems with your custom painting. What happens when you just use the standard components without custom painting?
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().