I've spent the last few days putting together a game that runs as an Applet, but I would also like to have it available as an Application.
I've tried placing the applet in a frame, but I only get a black screen (and the occasional menu screen) when doing so. The applet still runs and the sound still plays, but there is nothing else.
I would like to not have to break down the code and rewrite it for a standalone application, as it's time consuming, but if there's no other way, then I'll do what I have to do. The program is a little complex in that the "main" class (containing all the media information, game related events, etc.) is an extension of an Applet class (containing the KeyListener, init() event, run() event, etc.) so maybe I am just trying to place the wrong thing in a frame?
Here is a link to the src folder for the game. I have tried putting both the AWPASG class and the Game class in a frame and seen the same results for both.
Any help would be greatly appreciated.
Source Code/Media
http://www.mediafire.com/?4eslqqr4aoh33j1
That's because your class design is not very good. You've bunched everything together in 2 classses, isntead of separating at least the UI Widgets (panels, etc, etc) from the UI Container.
Also you're using the old style AWT Applet and Panel. You should use the new Swing JApplet and JPanel (and all opthers JXxx components)
In short, try isolating your GUI building (painting) into a class that extends JPanel (or contains a JPanel). Then you can have 2 separate startup classes, one that puts your game JPanel inside a JApplet and one that puts it into a JFrame (and thus gives you the possibility to start it as a Desktop application).
Also you might want to separate your GAME init logic from the Applet init lifecycle, your game should be able to initialize without caring about the underlieing GUI technology.
Related
I have an application that is a Maths Game for kids. Since I'm in college, I've usually only had a god object for all my past projects but for this applciation I've split my code into multiple classes:
MathsGame.java: main class which initialises components and constructs and controls the UI.
DiffScreen.java: contains methods for use on the difficulty selection screen.
GameScreen.java: contains methods for use on the game screen.
EndGameScreen.java: contains methods for use on the end game screen.
MigJPanel.java: extends JPanel and sets layout to MigLayout and adds a matte border.
Each screen that the 3 XScreen classes control is simply an instance of MigJPanel and screens are switched to using a CardPanel container JPanel.
I'm wondering how I can divide my code to each class so that they are properly abstracted but I'm not entirely sure how to approach this.
Should my 3 screen classes be extending from my MigJPanel so these then can be instantiated?
So instead of having my DiffScreen, GameScreen, and EndGameScreen classes solely containing methods related to each screen which are then called from MathsGame, each screen will control itself within its own class.
If yes to the previous question, should the UI components for each screen be made inside that screen's class?
At the moment, all components for each of the three screens are created in my MathsGame constructor. This makes the connection between a screen and the class which 'controls' (I use this word very lightly at the moment) it even further apart. So each screen is just an instance of MigJPanel whose components are constructed in MathsGame. The only relation the EndGameScreen class—for example—has to the End Game screen is that when the MathsGame causes the End Game Screen to be displayed, anything done there makes a method in EndGameScreen be called from MathsGame.
I hope I explained myself well. If not, leave a comment and I'll clarify. Any help would be greatly appreciated!
Yes
Yes.
Focus on self containment and maintain areas of responsibility. It is the responsibility of each UI screen to manage it's content, no one else, in fact, you should guard against allowing unrestricted modification to these components and provide access only through managed methods indirectly (setters and getters), which allow the modification of the properties you want to be changed, and not simply providing the component via a getter, this prevents problems with people removing components you don't want removed, for example.
You could also use interfaces to maintain common functionality if required, so if the MathsGame really only wants to deal with a certain amount of the information/functionality, you can use an interface that all the other screens use which will simplify the process, as the MathsGame only needs to know about the class that implement the interface and not EVERY thing else that might be going on...as a suggestion..
Also, where should I put the code for switching between screens?
From my perspective, it's the responsibility of the MathsGame game to determine when and to which screen should be shown. What I would normally do, is provide some kind of notification process that the current screen can ask the MathsGame to switch screens, maybe via a listener or other agreeded interface. This would mean that each screen would need reference to MathsGame.
Instead of passing it (MathsGame) directly, I'd create an interface that MathsGame would implement (say NavigationController), which defined the calls/contract that each sub screen could use (nextScreen/previousScreen) for example.
Take a look at Model-View-Controller for more ideas
I'm sorry this is probably way too basic to be on here, but it's a subject I've been struggling with for about a month now and I don't know where else to go (as far as I know there is no "noob overflow", lol).
I'm trying to create a class that would:
1. put an image on a window (a JFrame, JPanel or other container)
2. be able to support keyboard and mouse listeners
3. could have multiple instances in the same container
So anyway I've tried all the usual places - Google, YouTube, the official Java site (sorry forgot the URL) and of course here on Stack Overflow - but haven't been able to find anything even remotely similar to what I'm trying to do.
Of course, I've also considered the possiblity that maybe it can't be done at all. There doesn't seem to be any kind of standard "JImage" or "JGraphic" that works like JButton or JLabel, and for whatever reason graphics requires a completely different list of (extremely involved) processes and procedures. As an example, in this post: How to "really" draw images in a Java app - it took me 60+ lines of code and 2 classes to just come close. That project didn't work in the end because for some reason it would only let me create one instance (even it you created 2-4 in the main method, it would only display the last one you told it to add).
But anyway, assuming that I'm not trying to "re-invent the wheel" here and it is actually possible (in Java), does anyone have an idea as to how (or at least know of a better site to study it)? Unfortunately most of the sites I've visited tend to assume you know all the inner workings of images (I know what a pixel is but that's about it - Buffers, Rastars etc. are still beyond me). It would be absolutely outstanding if there were a site that would explain it in layman's terms, if such a site exists. Thanks in advance.
Just use a plain old JLabel.
Regarding your requirements:
put an image on a window (a JFrame, JPanel or other container).
You can give a JLabel an ImageIcon of the image of interest and it will display it. This can then be easily placed in any other container such as a JPanel or JFrame.
be able to support keyboard and mouse listeners
Any component that extends JComponent, such as a JLabel allows for use of MouseListener, MouseMotionListener and can listen for keyboard input via Key Bindings.
could have multiple instances in the same container
You can add as many as you'd like to any container. Just be cognizant and respectful of the layout managers in use.
I've created a new Java project without main class in NetBeans and then I've added a jApplet Form (let's call it MainWindow.java) to my project package. After that, I've added few other jApplet Forms that represent different "pages" of my applet application to my package using the GUI builder of NetBeans.
When I run my applet, I can see the MainWindow form with some buttons, label, etc. on the AppletViewer just fine.
Now, I want to make an event when one of my buttons on my MainWindow is pressed, to show another jApplet Form that I've created earlier and show that form instead of the MainWindow form. I'm trying to create a simple navigation system in my jApplet, and I don't know how to make it efficiently!
Can anyone help me with the code that I should write in the MouseClicked event of my button to make it show another form?
Basically, you can't (or shouldn't) design applets like this. There is no effective means to switch from one applet to another.
Instead, you should create one master applet and using something like CardLayout, design separate forms using one thing like JPanel
You'd then able to switch the forms using the CardLayout manager as needed
I am working on an application that uses Swing. I have successfully created a main GUI for the user to work from. However, I would like to allow the user to change his/her settings. How should I go about creating the settings window? Would using a new JFrame called 'Settings' be the best way to handle this, or is there something better to use than a second JFrame?
(Note: The settings JFrame, on exit, will not close the main GUI, it will use the DISPOSE method)
I would like to handle this in a way that consumes the least amount of memory, but maintaining a professionalized look to the application.
Have you considered a CardLayout? http://docs.oracle.com/javase/tutorial/uiswing/layout/card.html
Personally, I find the use of a separate dialogue to be a bit dated for configuration settings. I prefer tabbed layouts, which are card layouts decorated with a tab bar across the top.
You could easily wrap your application in a near-top-level card layout and add a menu action to switch to the configuration card, with the "acknowledgement" or "cancel" buttons switching back to the main application card.
In the end, it is really about what your users prefer, but remember a lot of them might prefer what they know, even if it is not a better solution. You have to find a balance, and if your implementation rocks, then eventually they will want your approach to the problem to be used in other applications.
A perfect example of this is tabbed browsing, as opposed to multiple windows. Personally, I can't imagine going back to multiple-window browsing now that I have become accustomed to browsing tabs, but at one point in time, multiple windows was the only game in town.
In the end, if you find out you made the wrong choice, keep you code clean enough to easily implement with either solution. As long as your configuration screen is just a plain JPanel (or wrapped in just a JPanel), it shouldn't be very hard to do.
here is a class that does just this kind of thing:
http://tus.svn.sourceforge.net/viewvc/tus/tjacobs/ui/dialogs/ParamDialog.java?view=log
you have to look at the ApplicationListener interface, especially at the 'handlePreferences' method of that interface.
I have a weird issue... I'm a relatively new "enthusiast" Java programmer (I used to make my living hacking Perl, in a previous career), working on my first semi-real application. "Main-Class" is the MyApp class, which creates a UserInputDialog instance.
UserInputDialog is a class I wrote that extends JFrame, implements ActionListener and KeyListener, uses FlowLayout, and presents the user with a JLabel, JTextField, and Cancel/OK JButtons. When the JTextField generates a KeyEvent where keyReleased() == KeyEvent.VK_ENTER, or when the "OK" JButton generates an ActionEvent, UserInputDialog does some input validation, calls setVisible(false), and then calls MyApp.doSomething( JTextFieldInstance.getText() ).
That all works perfectly. But now I'm trying to add a progress window to MyApp, as doSomething() can occasionally take a fair amount of time to complete.
I created the ProgressWindow class, which extends JFrame, uses BorderLayout, and tosses a JProgressBar in .NORTH and a JScrollPane (wrapping a JTextArea) in .CENTER. ProgressWindow works perfectly when instantiated from ProgressWindowTester and fed test data. It also works fine if I copy-and-paste the test for loops from ProgressWindowTester into MyApp and don't have MyApp instantiate UserInputDialog (i.e., there's nothing inherent in MyApp that's causing this behavior; it seems to be some sort of interaction I'm not understanding, between UserInputDialog and ProgressWindow).
But when I try to use ProgressWindow in MyApp as intended, i.e., ProgressWindow setVisible(true), I get a blank Swing window (of the proper size, and with the title bar set properly). The JProgressBar and JScrollPane / JTextArea components don't appear. The ProgressWindow methods are being called by MyApp properly (System.err.println() messages show proper interaction), everything appears to be working fine, just, the components that should be visible in ProgressWindow ... aren't.
I can post code snippets, but it's kind of convoluted, and I'm probably just missing something obvious...
I'm familiar with the concept of separating UI and business logic generally (e.g., I used HTML::Template and Class::DBI and CGI::Application when building Perl applications), but I'm not sure I'm "doing it right" in Java...
Thanks in advance!
Oh, I get exactly the same behavior on the two environments I've tried the code in: javac 1.6.0_29 on Mac OS X 10.6.8 ("Snow Leopard"); and javac 1.7.0_02[1] on the Fedora 15 Linux distribution, kernel 2.6.31.10-3, LXDE desktop environment.
[1] Downloaded directly from oracle.com; I;m not using OpenJDK (I know JDK 7 is based on OpenJDK) or gcj or anything like that
You've got a concurrency in Swing issue where you're trying to do a long running process on the Swing event thread or EDT. Since this thread is responsible for drawing all components and for processing user input, if it is tied down by your long-running process, your GUI will be effectively frozen until the process is complete. The key is to use a background thread such as that provided by a SwingWorker for long-running processes, so the event thread doesn't get locked. Check out Concurrency in Swing for more information on this. Also check out the JProgressBar Tutorial for other insights on how to use progress bars with background threads.
Also, you'll not want to use a JFrame where a dialog, such as a JDialog, is much more appropriate. Also, you'll want to avoid use of KeyListeners with Swing. Much better would be to simply add an ActionListener to your JTextField since its default behavior is to respond to presses of the key.
Oh, and welcome to StackOverflow.com!