Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
Sheriffs:
  • Devaka Cooray
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Tim Holloway
  • Claude Moore
  • Stephan van Hulst
Bartenders:
  • Winston Gutkowski
  • Carey Brown
  • Frits Walraven

JAVA GUI closing frame and opening exactly the same one (resetting)  RSS feed

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Hi all, Im working on a simple Java GUI game (please check the link) Ive created 4 classes, 3 classes create 3 different panels (red, green and yellow) and 4th class joins them together into one frame. Now, I need after pressing the button "Play a Game" to reset, re open the whole frame, making new session for a player. At the moment I manage to create new MainFrame frame, but the old stays, is there any chance to fix it without completely changing my GUI code structure? Ive tried different methods, but as I lack experience, none of them did work.

Screenshot of GUI: https://photos.app.goo.gl/FbpZUpGX125j7R3c9

main frame code:



And the PanelB class with button listener:





panel.JPG
[Thumbnail for panel.JPG]
 
Marshal
Posts: 63454
207
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch

You need to call setVisible() after adding all the Components (makeFrame()), or you would need a revalidate() call. Don't make your class a subclass JFrame. It HAS‑A JFrame and it ISN'T‑A JFrame. I think there is something dangerous about a Listener which creates a new instance of the class. And avoid using System.exit().
 
Justin Dot
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:Welcome to the Ranch

You need to call setVisible() after adding all the Components (makeFrame()), or you would need a revalidate() call. Don't make your class a subclass JFrame. It HAS‑A JFrame and it ISN'T‑A JFrame. I think there is something dangerous about a Listener which creates a new instance of the class. And avoid using System.exit().



Hi, this was fixed by introducing a new code line:

 
Campbell Ritchie
Marshal
Posts: 63454
207
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It still seems strange that you are creating a new frame every time you play the game. It also strikes me as iffy design that you are not separating the “business logic” of your app (the game) from the display. I think you should have the Game classes completely separate, so they can be played without any GUI at all, and you can start a new game with something like:- playAgainButton.addActionListener(evt -> myGame.startAnew()); You would have to find a way to reset the display. If the game has an output you can display, you may be able to do that simply by displaying the starting positions.
 
Justin Dot
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:It still seems strange that you are creating a new frame every time you play the game. It also strikes me as iffy design that you are not separating the “business logic” of your app (the game) from the display. I think you should have the Game classes completely separate, so they can be played without any GUI at all, and you can start a new game with something like:- playAgainButton.addActionListener(evt -> myGame.startAnew()); You would have to find a way to reset the display. If the game has an output you can display, you may be able to do that simply by displaying the starting positions.



Ive never been coding before, so at the moment having 5months of JAVA experience (not fully dedicated) this code arrangement seems most logical way of dealing with given "challenge".
I can post full code if that would make more sense, Im always up for a good advice on how to code
 
Campbell Ritchie
Marshal
Posts: 63454
207
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you are permitted to post the whole code, go ahead
 
Justin Dot
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
--MainFrame Class--


--PanelA Class--



--PanelB Class--



--PanelC class--

 
Justin Dot
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
any advice how to improve current code?
 
Campbell Ritchie
Marshal
Posts: 63454
207
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry I have been busy and couldn't look at your code earlier.
Let's have a look at your first class.How many classes do you think you will write? If it is more than about a dozen, I think you should give them package names.
I don't like *s in import declarations. I would prefer to see named classes imported, and it is easier to read imports if they are in alphabetical order, so java.awt comes first and javax.swing comes last.
Why have you called your class MainFrams; as I said yesterday it isn't a frame, but has a frame. Also, as I said before, I don't think you should make it inherit from JFrame.
Why have you given your frame protected access? Has somebody told you that makes it accessible iin subclasses? That isn't quite true, but it is also accessible to every other class iin the same package; if you don't use a package name that means a protected member won't behave any differently from a public member. At least give the frame private access. You can still access it from the panels with a method called somethng like getParent() or getAncester(). IIt may be possible to make the frame a local variable in the constructor.
Why are you using the no‑args constructor for GridLayout rather than specifying the numbers of rows and columns?
Do you really want EXIT_ON_CLOSE? That means the JVM will stop abruptly when you click the  ×⃞  button and you won't be able to do anything like saving game state or scores.
As  said yesterday, put setVieible() after makeFrame().
The makeFrame() method is dangerous. You should mark any method called from the construtor private or final but you don't need both. Also, because it has public access, it can be called by any code causing your display to revert to its original format just like that.
Why are you making a static call to the set label method? I think you may have things marked static which shouldn't be.
Have you come across Swing's threading policy? You&#a0;should start the program like this:-That assumes you have all the code to start the app executing from the constructor.
 
It is difficult to free fools from the chains they revere - Voltaire. tiny ad:
Become a Java guru with IntelliJ IDEA
https://www.jetbrains.com/idea/
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!