How do I get all three of my panels to be visible at once?

Question

I'm trying to create a game and I'm currently designing my GUI. I have 3 panels, mapPanel (which will eventually have my loaded map in), controlPanel (for the game controls: play, pause and stop) and I'm now trying to add another panel which will display the info on the players. My issue is that the program only shows whichever panel is added last, what am I doing wrong/missing? Thanks in advance!
//package vrc20.programming.coursework.java.DiamondMine;
import javax.swing.*;
import java.awt.*;
import java.awt.Color.*;
import java.awt.event.*;
public class DiamondMineGUI extends JFrame {
        DiamondMineGUI(int numberOfPlayers, String mapFilename) {
                super("Diamond Mine: The game that plays itself..");
                setSize(800,600);
                setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
                setLayout(new BorderLayout(10, 10));
                // PANEL 1
                //create a panel for the maps to be shown in
                JPanel mapPanel = new JPanel();
                add(mapPanel, BorderLayout.WEST);
                // PANEL 2
                //create a panel for the game control buttons to go in and set the layout
                JPanel controlPanel = new JPanel(new GridLayout(1, 3, 2, 2));
                // create buttons for playing, pausing and stopping the game
                JButton playButton = new JButton("PLAY");
                JButton pauseButton = new JButton("PAUSE / CONTINUE");
                JButton stopButton = new JButton("STOP");
                // associate them with appropriate listeners
                ActionListener playListener = new PlayListener();
                ActionListener pauseListener = new PauseListener();
                ActionListener stopListener = new StopListener();
                playButton.addActionListener(playListener);
                pauseButton.addActionListener(pauseListener);
                stopButton.addActionListener(stopListener);
                //add them to the panel, then add the panel to the frame
                controlPanel.add(playButton);
                controlPanel.add(pauseButton);
                controlPanel.add(stopButton);
                add(controlPanel);
                // PANEL 3
                // create the panel which shows the players and their statistics
                JPanel playersPanel = new JPanel(new GridLayout(1, 1, 1, 1));
                for (int i = 1; i <= numberOfPlayers; i++) {
                        playersPanel.add(new JLabel("Player " + i + ":"));
                //add(playersPanel);
                //set the frame to be visible
                setVisible(true);
        public static void main(String[] args) {
                System.out.println("Loading..");
                DiamondMineGUI myDiamondMineGUI = new DiamondMineGUI(5, "MAP");
class PlayListener implements ActionListener {
        public void actionPerformed(ActionEvent e) {
                System.out.println("The user pressed play!");
class PauseListener implements ActionListener {
        public void actionPerformed(ActionEvent e) {
        System.out.println("The user pressed pause.");
class StopListener implements ActionListener {
        public void actionPerformed(ActionEvent e) {
                System.out.println("STOP!");
}

Answer 1

JustSomeGuy wrote:
"Better" is subjective, and I meant to use it as such.By which, I presume you mean that "better" is context dependent. You're absolutely correct. My interpretation of you're comment, however, was that you felt that BorderLayout was inadequate, and since I don't think there was enough context given to make that judgement, I thought perhaps you were prejudiced againsted BorderLayout for some reason. Obviously, if BorderLayout was not up to the task, then that would be grounds for saying that other layout managers are "better" under the circumstances. But if it is up to the task, than I find it difficult to qualify "better".
>
Obviously in your opinion Borderlayout is the best thing since sliced bread. No, actually. My preferred layout is GridBagLayout. I rarely get to use BorderLayout, except in the simplest of UI's, because I do often find it inadequate for the task at hand. But, in my opinion, the simplest layout manager that will do the job is often the best choice, so even though I can do everything with GridBagLayout (my preferred layout manager) that I can do with BorderLayout, if I find a situation in which BorderLayout is sufficient, then I will always pick BorderLayout, because it's simpler, and more maintainable for my colleagues that find GridBagLayout difficult. I consider BorderLayout superior to GridBagLayout in any case where either one would be sufficient.
But if the OP went with a layout that better suited his/her needs then it would be the "better layout".Absolutely, but that presupposes that BorderLayout did not suite the OP's needs. It would appear that you jumped to the conclusion that BorderLayout was insufficient when there was no indication from the OP that this was the case, and AFAIC, there was every indication that BorderLayout was sufficeint, given that it was the layout selected by the OP, and only three panels were being added.
Did the op figure out how to use border layout or choose a layout that better met his/her needs is exactly what I was inquiring about.That's a fair question, but since "better" requires some context, perhaps a more appropriate term would have been "more flexible", or simply "alternative".
>
But I will argue against your arguement. I agree that borderlayout is most often used, possible due to it being default but more likely because of it's simplicity. If it is something simple you are working on, the borderlayout is absolutely the way to go.
However, I have written many games in java, and borderlayout never works for the main layout of a game. It is fine nested in other layouts, but its simplicity makes it unworkable for the main layout.I disagree. Obviously, you and I have had different experiences developing GUIs, then. I have written a few where BorderLayout worked perfectly. Very often in a game, you would have a control panel at the bottom with a fixed height, as it would ideally be as small as possible while still accomodating the icons & controls it needed to contain, and perhaps another similar control panel on the left hand size, and then a large central space that would fill the remainder of the window, and be the main visualization area of the game. BorderLayout works very well for this sort of thing.
And don't under-estimate the value of nested panels. Sometimes you really do need the complex relationships you can get with more flexible layout managers, but most of the time, if you've got a group of related components that can be thought of as a single group, then you can, and probably should, put them in a nested panel, both for accessibility reasons and for complexity management.
The primary reason for this is people are funny about games, if you write a game that can not be resized ever people will hate it even if the game itself is even better than sliced bread or in your case borderlayout. Some want to play their games in full screen mode, some will settle for a decorative window filling the screen, others want the game to be playable in various sizes and shapes. If shrinking your game window causes things to get cut-off players aren't happy. Similarly if growing your game window just adds a bunch of useless blank space players aren't happy. border layout is just to simple to handle window resizing efficiently, therefore it is not the best layout for games. This is the statement I disagree with the most, of anything you've said. Border layout is perfectly capable of handling resizing of windows. It does so by resizing the components within it, so the real question is how those components cope with being larger or smaller than they expected. AFAIC, the way BorderLayout handles resizing is exactly the behavior you want in many games that have a layout similar to what I described above.
More importantly, I think perhaps you're worrying about resize behavior a bit too soon. First off, the OP is tripping over a more important, and frankly more basic, issue of simply putting components in the desired relative positions. I would recommend getting that down pat, first, before worrying about how resizing is going to effect things. AFAIC, changing the layout managers in order to change the resize behavior, while maintaining the relative positioning of components is one of the easiest refactorings done in a UI.
>
The OP is writing a game.
Just saying.
JSG