I know I can specify one for each form, or for the root form and then it'll cascade through to all of the children forms, but I'd like to have a way of overriding the default Java Coffee Cup for all forms even those I might forget.
Any suggestions?
You can make the root form (by which I assume you mean JFrame) be your own subclass of JFrame, and put standard functionality in its constructor, such as:
this.setIconImage(STANDARD_ICON);
You can bundle other standard stuff in here too, such as memorizing the frame's window metrics as a user preference, managing splash panes, etc.
Any new frames spawned by this one would also be instances of this JFrame subclass. The only thing you have to remember is to instantiate your subclass, instead of JFrame. I don't think there's any substitute for remembering to do this, but at least now it's a matter of remembering a subclass instead of a setIconImage call (among possibly other features).
There is another way, but its more of a "hack" then a real fix....
If you are distributing the JRE with your Application, you could replace the coffee cup icon resource in the java exe/dll/rt.jar wherever that is with your own icon. It might not be very legit, but it is a possibility...
Also, if you have one "main" window, and set its icon properly, as long as you use that main window as the "parent" for any Dialog classes, they will inherit the icon. Any new Frames need to have the icon set on them, though.
as Paul/Andreas said, subclassing JFrame is going to be your best bet.
Extend the JDialog class (for example name it MyDialog) and set the icon in constructor. Then all dialogs should extend your implementation (MyDialog).
Related
I read that the window that appears using the JFrame class is a Container with the predefined features (minimize, closing), but I found people who were not using the JFrame class but other classes (one of them the Container) which was far more hard.
Why do they do it that way? Is it because the JFrame class always has a predefined window that you can manipulate some aspects of it but the Container and the other classes give you more freedom of how you can create a window?
For an example to my question (I don't know if its real or not) in the JFrame class the close button always go to right to corner of the window but if I do it the other way you can put it everywhere you like. (If it can be answered with a yes or no).
So my qusetion is why they do it that way
There are two "main" reasons why. First is about overall good programming.
We tend to recommend avoiding extending from classes to which we are not adding any new functionality or repeatable features. If the whole reason for extending from JFrame is just so you can display some components, then it's really not a good choice or starting point.
JFrame is also a complex, compound component. That is, it's actually made up of a number of other layered components which work together to provide an overall experience.
*From How to Use Root Panes
This means that there is a lot of added complexity you'd have to be willing to manage if you extended from this class, a lot of overhead just to display a few components.
In principle, it's better to use composition over inheritance, which leads into the second point.
Extending from any class locks you into that classes use case. In the case of JFrame, you can only ever display what ever is managed by the class via a JFrame, there is no flexibility or entry point for re-usablility.
If, instead, you started with a base class of, say JPanel, you can add that to what ever container you want when ever you want, it increases the flexibility and re-usability of the class over all.
For an exaple to my question(i dont know if its real or not) in the JFrame class the close button always go to right to corner of the window but if i do it the other way you can put it everywhere you like.(If it can be answered with a yes or no)
Yes and no. The frame border is defined by the look and feel delegate, so you're not actually starting at the right place to begin with anyway.
Most look and feel delegates delegate the frame border to the native platform, in the case of Windows, yes, the close button is on the right, on Mac it's on the left.
In any case, it's better to support user expectations, placing the close button in an unusual place might make the UI "pretty", but diminishes the user experience - as a general guide line, don't diminish the user experience, no matter how awesome your program or UI, user's won't like you for it - but that is a (very broad) question for another day
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 looking to build out a Java GUI with a table area and an area that will display the data of a selected row of the table. I've never tried a multi-frame set up before so before I venture to do this I wanted to check with others. Is it difficult to have two frames and have them passing data back and forth? The idea would be that I could move the details frame anywhere I like on the screen or to a second monitor and allow the table to go full-screen if the user wants. Any input or examples are appreciated.
don't to create two of more JFrames use JDialog instead,
reuse this JDialog for another action(s)
create one JFrame and one JDialog for displaying details
have to determine if and which of JTables row(s) is selected
better would be to set ListSelectionMode to the SingleSelection
maybe would be better to invoke (show that already exist) JDialog from JPopupMenu Action
You should have no problem in doing what you are after. You can have public methods in each frame which expose properties and/or structures and you then pass the instance of one JFrame to the other. This should allow you to pass data back and forth.
That being said however, I think that this scenario is valid only when you have one, two, or at most three JFrames. Having a lot of frames calling each other could result a maintenance nightmare.
there are several possibilities to do so:
you can add one of the jframes as a listener to anothe, or both to each other. For this, you have to implement a listener mechanism, like in java.awt. You can pass the information contained in the event objects - this would be the most clean alternative
you can pass the instance of the detailframe directly in the constructor of the main frame and call operations from main frame on detail frame. this is the simplest way, but you will need lot of code changes if you have some new features to add
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've got a custom window class that is a couple levels down extending a JDialog. We have windows that we create and sometimes we create new windows as children of existing windows using the constructor that takes a parent argument.
I need to put some code somewhere in our custom class that does something different depending on whether not the window has children. I know of getParent(), etc, and I can see that I can loop through the components of the window, but for the life of me, I can't seem to figure out how to determine whether or not my current window has any child windows.
Is there a way to do this? Any help is, as always, much appreciated.
See Window.getOwnedWindows().
will getOwnedWindows() do? It belongs to java.awt.Window which in JDialog's parent lineage.