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?
Related
I am now writing code simple GUI that's for start the game window. I only need Do you want to start game message and start button on the window. But I have a confusing concepts for the JFrame and JPanel. Actually, I thought I need to add JPanel to JFrame to add the other components such as JLabel, JButton,...etc. But I realized I don't actually need JPanel. I can just add the components simply use add(button), add(label) to JFrame. So why I need JPanel. And I think JFrame doesn't need JPanel but JPanel need JFrame. Am I understand correctly?
No, not always. A simple graphical user interface may be implemented by just adding components "directly" to a JFrame. But in order to get more flexibility, you would always use JPanels. For example, to employ different layouts in different parts of the GUI, to group certain components together, etc.
A JFrame is backed by a JRootPane, a part of which is a contentPane.
(image from Oracle Javadoc)
When you add components to a JFrame, you are really adding them to the content pane, e.g.: frame.getContentPane().add(Component).
A JFrame is a common starting scene of a Swing GUI application, while a JPanel is intended to be put in another scene (container). Since both content pane and a JPanel inherit from the same class (Container) you may use them in a similar manner, as far as adding components to them goes.
Do I need JPanel always?
No. Well, unless you need a Swing GUI. Then yes.
Another answer replied words to the effect. "No, you can add components direct to a frame" What they missed was that components added to a JFrame are added to the content pane (automatically). The content pane is a JPanel.
Having said that:
I (and many others) would recommend designing an app based around a main content panel, then adding that panel to a top-level container as needed. The top level container might be a JFrame, JWindow, JDialog, JOptionPane ..
What prompted the question? A JPanel is a very 'light weight' container (in more ways than one). A GUI can contain 1000s and not be burdened by doing so. Of course, that's a rare requirement, but just saying .. use panels as needed and don't worry about it.
I have a JFrame as my main class and made it focusable, given it a MouseListener and added some JPanels.
In the JPanels I have Environment classes that display images. Each JPanel only covers a part of the JFrame, and the Environments likewise cover a part of their parent JPanel.
I need to know how to properly capture MouseEvents and pass them down through the chain to the correct Environment so they can be dealt with properly and update the corresponding image associated with that area
Are there methods built into the JFrame and JPanel that can at least get me as deep as the JPanels or would I have to implement them myself?
I don't want to have to implement handlers for all the different MouseEvents, just pass the object down so that it can be handled at the lowest level.
Any suggestions would be appreciated
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 LayeredPane with two JPanels, all in a JFrame. Both JPanels are set to be transparent with setOpaque(false). However, I would like to capture mouse events on the (top, if it makes a difference) transparent panel. Is this possible, or should I just do it from the underlying JFrame? (It would definitely work to capture from the JFrame; it just makes more logical sense to capture the events from the transparent frame).
You can capture mouse events on whichever JPanel has a MouseListener attached to it, and is not encumbered by components that also have MouseListeners added, and who are laying on or above the original JPanel. This looks like a situation perfect for creating a small test class that is the most simple of GUI's, that has none of the bells and whistles of your GUI, but that illustrates your problem and hopeful solution.
Also, please know that the transparency does not play into any of this at all except as a distraction.
I read that JFrame is made of several panes ..what are panes and why is Jframe made of panes ?
And why there is a JPanel while it seems that the JFrame looks exactly like the JPanel but with a menu bar and a close button so what's the need for a JPanel ? Can anybody explain to me clearly the definition and use of those 3 components ?
There are top level containers such as JFrame. These can serve as the main window in which a GUI is built.
Then there are intermediate level containers. These must be placed in other containers, they cannot exist by themselves. They either help you organize components or they add functionality. A JPanel is a very simple container that helps you to organize other components. While a JSplitPane adds the functionality of having two panes that are variable sized.
When you have a complex GUI you may want to use JPanels to organize various areas of your GUI and then add each of the panels to your JFrame.
In Java the Swing API makes use of the Composite Design Pattern. This means that you can compose very complex objects from other objects and still treat the composite objects the same way as the simple objects. So you can put a JPanel into a JPanel and it still behaves like a JPanel.
Think of it like a tackle box (or sewing kit). It is made of a big container. But rather than put many small objects into this big container and make it difficult to manage later you can place some smaller compartments inside the big box. Then hooks and sinkers etc go in the compartments. Its easier to manage. The big box is the JFrame and the compartments are the JPanels.