I'm using libgdx (com.badlogic.gdx.Game and Screens and that stuff) to make a game. I have the following problem: on desktop, when I close the window (from the cross on top), of course the application closes. But I would like to go back to menu screen and dispose there, since I do disposing of resources there (via asset manager). I have buttons for exiting in the game and if exiting is done that way, it's fine. The trouble is that the red cross can be pressed. So how could I handle disposing properly in that case?
On the android version, I catch the back key and handle leaving different parts of the game and the whole game in my own way. And there it works OK.
Another related question I have:
On desktop the application cannot get stopped and then disposed (on it's own, without user explicitly exiting it) like the android version can (the android life cycle), right? So is it a good idea, if I do a temporary save on pause() and restore game state from that on resume(), that I don't restore on desktop (since the restoring isn't a complete restore and I don't want restoring to happen if, on desktop, the window is just minimized (as I noticed, pause()/resume() gets called when minimizing/restoring window )).
Hope this wasn't too unclear :D. I've tried to google for answers but don't seem to find anything. Any help is much appreciated.
I suggest using the libgdx life-cycle methods
To dispose you should use the dispose() method. You don't need to call dispose yourself! It will be called automatically when the application gets destroyed, see documentation:
dispose () Called when the application is destroyed. It is preceded by a call to pause().
So just implement the dispose method in your Screens:
#Override
public void dispose () {
//your code needs to get added here, like for example:
stage.dispose();
texture.dispose();
//etc..
}
Update: Note that dispose() of AppliacationListener gets called automatically, not dispose() of Screen, see comment of Springrbua
You can call dispose() of your Screen by calling it explicitly from your Game Class dispose() like this
MyScreen Class:
public class MyScreen implements Screen {
// Not going to write all other methods that need to be overridden
#Override
public void dispose() {
// Clear you Screen Resources here
}
}
MyGame Class:
public class MyGame extends Game {
// Not going to write all other methods that need to be overridden
#Override
public void create() {
setScreen(new MyScreen());
}
#Override
public void dispose() {
// Clear you Screen Explicitly
getScreen().dispose();
}
}
Hope this helps
As mentioned above, the Screen interface contains a dispose method. Additionally, the dispose method of Game can be overridden to dispose of the current screen automatically. However, there is a reason this is not the default. Let's say you have multiple Screens - Screen1and Screen2. Screen1 was active, then changed the screen to 2. The game is then exited, and the dispose method is called, which calls the current screen's dispose method - leaving screen 1 alone.
My preferred method is to have the game keep track of screens set by overriding the setScreen method and adding a Screen[] screens, a boolean[] scrDiss, and an index. When dispose is called on Game, it checks through all screens set, checks if previously disposed, and disposes if not. Additionally, the Screen dispose methods should call a method on the Game that finds it in the array, and marks it disposed. This way, screens can be disposed before the end of the Game, but when Game is disposed, all Screens will be as well.
Call dispose on all your screens when your application is disposed.
Related
I understand that the show() method is used to bring the screen back to the front when the user re-opens the app or brings it to the foreground.
However, what should go here?
Lets say I have a bunch of objects, with textures attached and actively being rendered and constantly moving position.
If I say, hit the pause button, the hide() function gets called and I the initiate a new screen. Say I come back to the GameScreen, does libGDX/Box2d automatically take care of everything for me or do I have to make sure that I have some sort of code in the show() method?
Anything that needs to be stopped in hide() should be restarted if needed in show(). This could include music, background threads, etc. I use show() to refresh the data behind the screen, since I keep instances around to avoud garbage collection.
There's no need for you to do anything, unless you want to put here some specific initializations. For instance, show() method is a good place to start playing a background music for the recently showed scene.
I've made a game in Java which works without any problem when I run it in Eclipse. Everything looks great and it is effectively done (at least until I come up with something else to do with it). So I've been trying to put it on my website, but whenever I run the game in browser I simply get a white screen, though checking the Java console shows no errors. I've managed to narrow the problem down to the painting of the screen. I have a timer which runs the game and makes stuff happen. At the end of it, it calls the repaint() method. In Eclipse, that works fine, but in the browser, nothing happens.
Here's the relevant code (All of which is inside the main class called FinalProject):
public class FinalProject extends JApplet implements ActionListener,
KeyListener, MouseListener, MouseMotionListener {
public void init(){
//...initialize program
System.out.println("game started");
}
/**
* A method called every so often by a timer to control the game world.
* Mainly calls other functions to control objects directly, but this
* is used as the only timer, which also calls repaint() at it's end.
*/
private void runGame(){
//...Run game and do important stuff
//This Draws The Screen
System.out.println("about to paint");
repaint();
}
public void paint(Graphics g){
System.out.println("painting");
//...paint screen
}
public void update(Graphics gr){
System.out.println("updating");
paint(gr);
}
}
runGame() is called by a timer. In Eclipse the output is:
game started
painting
painting
about to paint
painting
about to paint
painting
about to paint
painting
...
When doing this in a browser (Running offline directly on my machine. All browsers have the same problem as well), the console shows:
...(loading stuff)
game started
basic: Applet initialized
basic: Starting applet
basic: completed perf rollup
basic: Applet made visible
basic: Applet started
basic: Told clients applet is started
about to paint
about to paint
about to paint
...
I don't know what else to try at this point. Despite my efforts I still don't fully understand exactly what repaint() does, all I know is that it ultimately calls update() and paint(). Except that doesn't seem to be happening in the browser. I'm using Windows 7 64x with Java Version 7 Update 5. Thanks in advance for any help.
Turns out, the problem was in removing the menu bar. I had found some code a while ago which would remove the menu bar from the program and it worked without any problems. However it seems that it prevented it from repainting when placed in a browser. I have no idea why repainting broke because of removing the menu bar, but apparently it does.
The code I had used (in init()):
Frame[] frames = Frame.getFrames();
for (Frame frame : frames){
frame.setMenuBar(null);
frame.pack();
}
This code did remove the menu bar as desired, but also exploded the program whenever it was put online. Removing this fixed the issue. Fortunately, the menu bars don't show up online anyways, so you aren't losing much by removing this bit of code.
I know this is sort of a vague question, but I will try to make it as clear as possible. When my Java app launches for the first time, it does some checking to see if files and directories exist and checks for an internet connection.
The app then allows the user to move on to the dashboard, which requires loading and adding many Swing components to the Background Panel. This takes time.
I was wondering how I could make it so that during the loading process at the start, the app loads all of the Swing components Images etc. so that they appear instantly when the user executes the command to do so.
I can load all of the components like this:
JButton = new JButton("blah");
but I'm not sure that's enough to make the components appear instantly, wouldn't adding several image filled Swing components at the same time still lag the UI thread, even if it was already "loaded" as seen above?
Thanks!
on the components use
setVisible(false)
for example
public class myParentPanel extends JPanel{
public myParentPanel{
//add all the child components
//Do what ever takes along time
setVisible(false); //this then makes in invisible but still
//allows all the set up code to run
}
public void showParent(){
setVisible(true);
invalidate();
}
}
and then create a method to make them visible when required. Hence all your setting in the constructors ca be called then when you call your method say:
drawWindow()
it then only has to call setVisible(true) and invalidate the screen to call their painting methods :).
An advancement on this would be to *run your setups i.e your checking and loading the panels methods on a separate threads*so you don't have to wait for a sequential loading. So on your loading you may to use an anonymous class
SwingUtilities.invokeLater(new Runnable(){ public void run(){
//do my display set up
}});
I have a closeWindow() method which uses dispose() for the current JFrame to close down. When I show the window again, the controls (textboxes, lists, tables etc.) still have their previous values in place that were there when I dispose():d the frame... Why is that? Is there another way to completley close and clear a frame?
This is the code that another JFrame uses to show the other window, am I doing something wrong here?
#Action
public void showAddProductToOrderView() {
if (addProductToOrderView == null) addProductToOrderView = new AddProductToOrderView(this);
addProductToOrderView.setVisible(true);
}
Disposing a window will not clear its child text components. Dispose will release native resources. The javadoc for java.awt.Window also states:
The Window and its subcomponents can be made displayable again by rebuilding the native resources with a subsequent call to pack or show. The states of the recreated Window and its subcomponents will be identical to the states of these objects at the point where the Window was disposed (not accounting for additional modifications between those actions).
As suggested by others, create a new instance each time instead. If that's to expensive I believe your best option is to clear sub components when the view becomes visible, e.g. by overriding setVisible.
EDIT:
Remove the null check to create a new frame each time.
#Action
public void showAddProductToOrderView() {
addProductToOrderView = new AddProductToOrderView(this);
addProductToOrderView.setVisible(true);
}
I don't know about the rest of your code, if there's something else depending on the frame being reused. For example, if you have attached listeners, ensure they are unregistered to not leak them.
The simplest thing to do would be to re-create the whole frame (using its constructor) before using show() to show it again. That will give you a whole new set of components, assuming that the constructor creates and places them.
I'm creating an application in Swing using NetBeans. I would like to be able to manipulate some components during its startup (just once), after the window's made visible, for example update a progress bar. To this end, I have the app's main class, called MainWindow:
public class MainWindow extends JFrame
{
public MainWindow()
{
initComponents(); // NetBeans GUI builder-generated function for setting
// up the window components
}
public void Init()
{
loadLabel.setText("Loading....");
loadProgressBar.setValue(20);
doSomething();
loadProgressBar.setValue(40);
doSomething();
loadProgressBar.setValue(80);
doSomething();
loadProgressBar.setValue(100);
loadLabel.setVisible(false);
loadProgressBar.setVisible(false);
}
/* .... */
public static void main(String args[])
{
java.awt.EventQueue.invokeLater(new Runnable()
{
public void run()
{
mainHandle = new MainWindow();
mainHandle.setVisible(true);
mainHandle.Init();
}
});
}
}
The problem is that the effect of the statements for updating the progress bar (or manipulating any other GUI component) within the Init() function can't be observed. If the Init() function is called from within main() as shown above, the window appears, but is empty, the Init() function executes and returns, only afterwards the window draws its contents but any changes made by Init() aren't visible because the window was empty and inactive the whole time. I also tried calling init from the windowOpened() AWT event, which executes after the window is fully drawn, but amazingly putting any statements for manipulating components there seems to have no effect, or rather they are put in a queue, and executed rapidly at some point in succession, so only the effect of the last one (hiding of the elements) can be observed. The only way I managed to get it working was to remove the whole invokeLater(new Runnable()...) mantra and put the new MainWindow(), setVisible(), Init() sequence directly in main(), which I guess is very ugly and breaks the concept of the gui running in a threaded manner. What is the right way to do this? Where do I put code to be executed first thing when the gui is ready to be manipulated, execute the statements once and return control to the main event loop?
I guess at the moment this is working in such a way, that while the Init() function is operating, any operations on the gui components are suspended (the drawing thread isn't separate and waits for Init() to finish before the manipulations are executed). Maybe I should make Init() a new thread... only how and what kind?
Thanks.
You could change the EventQueue.invokeLater() to invokeAndWait(), and move the call to init() out to a second EventQueue.invokeLater() call.
If (as looks to be the case) doSomething() takes a noticable amount of time, a better idea is to move the Init code into the body of a SwingWorker. This could be executed from the MainWindow() constructor or after the setVisible() call in main and is the idiomatic way to have a responsive GUI (in case the user gets bored waiting and wants to quit) and display some visible signs of progress.
See the process and publish methods for details on how to update the progress bar between doSomething() calls.
You may also want to look into ProgressMonitors for another alternative that would deal with the dialog box etc for you.
There are several things you can do:
For windows (such as JFrame or JDialog) you can attach WindowListener and do your manipulations in windowOpened method.
Override addNotify method and do your control manipulations there.
Attach HierarchyListener and do your manipulations whenever displayability of component changed.
Always make sure your do your component manipulations on EDT. Use SwingUtilities.invokeLater for simple UI updates or SwingWorker for long running tasks