I have a noobie question about GUI designing in Java: should we use more methods or more objects? Take a very simple example: dialogs.
For a dialog, I can use a method or use an object:
Using Method:
public static void MakeDialog() {
final JFrame frame = new JFrame();
String help = "";//Reader.readhelp();
JTextArea contentArea = new JTextArea(help, 60, 60);
JScrollPane scroller = new JScrollPane(contentArea);
scroller.setPreferredSize(new Dimension (650,650));
JButton close = new JButton("Close");
close.addActionListener(new ActionListener() {
#Override
public void actionPerformed(ActionEvent a) {
frame.dispose();
}
});
JPanel panel = new JPanel();
panel.add(scroller);
panel.add(close);
frame.add(panel);
frame.setTitle("Help");
frame.setSize(700, 700);
frame.setVisible(true);
frame.setResizable(false);
frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
}
Then I will just need to call this method need this dialog to show up.
However, I can have another approach: make a class of dialog:
public class MyDialog {
public MyDialog() {
final JFrame frame = new JFrame();
String help = "";//Reader.readhelp();
JTextArea contentArea = new JTextArea(help, 60, 60);
JScrollPane scroller = new JScrollPane(contentArea);
scroller.setPreferredSize(new Dimension (650,650));
JButton close = new JButton("Close");
close.addActionListener(new ActionListener() {
#Override
public void actionPerformed(ActionEvent a) {
frame.dispose();
}
});
JPanel panel = new JPanel();
panel.add(scroller);
panel.add(close);
frame.add(panel);
frame.setTitle("Help");
frame.setSize(700, 700);
frame.setVisible(true);
frame.setResizable(false);
frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
}
}
The problem that really bothers me is: which one uses memory more efficiently? For one or two dialogs in a software, this is probably not a problem at all. If I need to deals with hundreds of dialog, I need to think about the memory resources that I might consume. According what I have learned so far, calling that method is better than creating MyDialog object, since memory will be released when once the method is processed. However, the object MyObject will be remained in memory if I don't take any action on it. The problem that I am facing is: after a few hours of developing, I found out that I only have a few MB of memory left and I have to quit Eclipse and restart my computer to release the memory.
Therefore:
1) Which one is better?
2) If creating object is better, how can I remove that object from memory if I am not going to use it anymore?
Memory usage is irrelevant here. The difference will be around 20 bytes, that will be garbage collected.
What matters is correct design. An object's constructor is not meant to have side effects like showing a dialog box. The goal of a constructor is to create an object with a specific state, by initializing its fields, in order to use the object later.
Your example doesn't do anything like that. You would be creating a MyDialog instance, and do nothing with it. All the constructor would do is to have a huge side-effect: displaying a dialog box.
Another bad point in this design is that you're using an instance field to store a value that is in fact a constant, not tied to any specifu MyDialog instance, and only relevant to the constructor. There is no reason at all to have such a field.
And finally, your method doesn't respect the Java naming conventions: methods start with a lower-case letter. And it should be named showDialog() instead of makeDialog, since it doesn't create a dialog box, but shows one.
I'm afraid this question is a bit too general to answer, since you're asking about any and all use cases of GUI design.
Let me instead refer to the specific scenario you mention, which is a dialog.
It might come as a surprise, what's considered as a Swing best practice when it comes to dialogs, is somewhere in between a method and a class.
When working with dialogs in Swing, on the one hand, it's considered a best practice to create a new class for the panel that contains all the GUI, and which will become the content pane of the dialog. On the other hand, you should create a method that will create (and possibly also display) the dialog. In that method, you'll do the following:
Create an instance of JDialog (usually, there's no need to subclass)
Create an instance of your custom panel class (e.g. MyDialogContentPaneClass)
Set the panel as the content pane of the dialog
Display and/or return the dialog
Related
"This method creates an object but does not assign this object to any variable or field. This implies that the class operates through side effects in the constructor, which is a bad pattern to use, as it adds unnecessary coupling. Consider pulling the side effect out of the constructor, into a separate method, or into the calling method."
This short test program runs as I expected, but I don't know how to address this checkstyle error. Most of the examples of using javax.swing seem to have this structure.
There is also a error causes by EXIT_ON_CLOSE, but without it the process lingers after I close the window and must be force quit.
public class GUI implements ActionListener {
private int clicks = 0;
private JLabel label = new JLabel("Clicks= " + clicks);
private JFrame frame = new JFrame();
public GUI() {
// make a Jbutton named button
JButton button = new JButton("Click Me");
button.addActionListener(this);
// arrange the button and label
JPanel panel = new JPanel();
panel.add(button);
panel.add(label);
// put the panel in a frame
frame.add(panel, BorderLayout.CENTER);
// EXIT_ON_CLOSE has a style error too.
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setTitle("Graphical User Interface");
frame.pack();
frame.setVisible(true);
}
// update label and number of clicks when button is clicked
public void actionPerformed(ActionEvent e) {
clicks++;
label.setText("Clicks= " + clicks);
}
// This is the code that InteliJ says has bad form.
public static void main(String[] args) {
new GUI();
} }
One bad pattern here is that you are not creating your GUI on Event Dispatch Thread. Not sure if this is related to your problem.. but you should always use EDT to create the GUI in Swing.
EDIT: take a look here. In the main method you just have "new GUI()" without a reference variable. Writing your app like this example you are not going to use the constructor to create all :)
I am writing the back end code for my java project which is implementing a fitness logger. For some reason when I put the actionListener function to a button in my Border Layout then the button disappears.
I tried setting the function in different places in the constructor.
public class Buttons extends JFrame implements ActionListener {
JFrame frame = new JFrame("Menu");
JPanel MyPanel= new JPanel();
JButton b1= new JButton("Daily Logger");
JButton b2= new JButton("View Weekly Logs");
JButton b3= new JButton("Weight Calculator");
JButton b4= new JButton("BMI Calculator");
JButton b5= new JButton("Log Out");
public Buttons(){
MyPanel.setLayout(new BorderLayout());
MyPanel.add(b1, "North");
MyPanel.add(b2, "Center");
MyPanel.add(b3, "East");
MyPanel.add(b4, "West");
MyPanel.add(b5, "South");
b1.addActionListener(this);
add(b1);
frame.getContentPane().add(MyPanel, "North");
frame.setSize(500,115);
frame.setVisible(true);
}
public static void main(String[] args) {
new Buttons();
}
#Override
public void actionPerformed(ActionEvent e) {
String command = e.getActionCommand();
if(command.equals("Daily Logger"))
myMethod();
}
public void myMethod() {
JOptionPane.showMessageDialog(this,"Onto the next step");
}
}
I expected the button to show up in the border layout when I add the actionListener function but it disappears. If the button did work as it should it should implement the myMethod() function. My main goal is to show my JTable that I created in another class to show up when the button is pressed.
add(b1);
Should be removed. The code has already added it via:
MyPanel.add(b1, "North");
A BorderLayout accommodates up to five components, each in a separate layout constraint. If a component is added twice, in different areas, it faces two problems:
A component can only appear in one place.
The component 'overwrites' the original component added to that area of the layout.
More general tips:
Please learn common Java nomenclature (naming conventions - e.g. EachWordUpperCaseClass, firstWordLowerCaseMethod(), firstWordLowerCaseAttribute unless it is an UPPER_CASE_CONSTANT) and use it consistently.
For better help sooner, add a minimal reproducible example or Short, Self Contained, Correct Example. Note: The posted code only needed appropriate import statements to be an MRE / SSCCE.
MyPanel.add(b3, "East"); re East
There are constants for this. E.G. BorderLayout.EAST. always use the constants for compile time checking.
But BorderLayout.LINE_END is sensitive to the locale. It will appear on the RHS for left to right languages, and the left for right to left languages.
All Swing & AWT GUIs should be created & updated on the EDT (Event Dispatch Thread).
The code both extends and keeps a reference to, JFrame. Keep the latter, ditch the former.
Be sure to add the java (language) and swing (GUI toolkit) tags to questions! The only reason I saw this was because I (extraordinarily) checked the question listing for the jframe tag! To the best of my recollection, it's the first time I've ever checked that tag's question listing. Even more ironic, it did not make the list of 5 tags I saw as being most relevant to this question.
frame.getContentPane().add(.. can be shortened to frame.add(.. since Java 1.5.
frame.setSize(500,115); should better be frame.pack();, since 500 x 115 is no better than a guess, and will be 'wrong' for different OS' (the size of the content pane will change due to different frame decorations per system).
I am trying to make a refresh button that will essentially restart the program when ever I click the button. I don't know how I should go about doing this.
I've place the Graphical User Interface i decided to use do complete this action. Any and all help would be greatly appreciated.
package pdfView;
import javax.swing.*;
import java.awt.*;
public class View extends JFrame {
public View() {
super("PDF Viewer");
setLookAndFeel();
setSize(500, 125);
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
FlowLayout flo = new FlowLayout();
setLayout(flo);
JTextField Search = new JTextField ("Search", 29);
JButton Search1 = new JButton("Search");
//this is where i have the button
JButton ReFresh = new JButton("ReFresh");
add(Search);
add(Search1);
add(ReFresh);
setVisible(true);
}
private void setLookAndFeel() {
try {
UIManager.setLookAndFeel(
"com.sun.java.squing.plaf.nimbus.NimbusLookAndFeel"
);
} catch (Exception exc){
}
}
public static void main(String[] args) {
View pdf = new View();
}
}
What do you mean by refresh or restart?
Do you mean:
Let the application be as it is, just update what it's showing?
Really restart the application?
Updating what the application is showing
You first need to decide what actually should cause your application to refresh. You already talked about a Button. The mechanism for activating something like a button is called Action. You can do that stuff manually, using an ActionListener, or you could extend AbstractAction, which is what I recommend. Extending AbstractAction allows you to use the same logical action something in more than one location on the UI. Look at typical applications, they offer Cut/Copy/Paste through menu, toolbar, popupmenu and keyboard shortcuts. The simplest way to achieve this in Java is using Action by extending AbstractAction.
The methods you need to call to update your application are invalidate(), validate() or repaint().
Restarting an application
So you want to run through main() again? That should actually not be required, unless you have an application that supports updating itself. Even then it can sometimes be avoided by smart usage of a ClassLoader.
Some more notes on your code
Usage by extension anti-pattern
I wouldn't extend JFrame just to display a window on the screen. Usage by extension is an anti-pattern. You don't need to extend JFrame to get a JFrame displayed on the screen and do what you want.
Referring static members
I would refer to constants via their original declaration. I.e. I'd refer to EXIT_ON_CLOSE via WindowConstants.EXIT_ON_CLOSE, not JFrame.EXIT_ON_CLOSE.
Typo
You have a typo in your UIManager.setLookAndFeel() code. Search for swing and you will see the typo.
Exception information
You might actually want to print the exception to stderr using exc.printStackTrace() instead of ignoring it completely, because when you have a typo in the LaF class name, as you do, and you don't print the exception, you might actually not come to know what's going wrong.
Sequence of widget construction and UIManager.setLookAndFeel()
The sequence of UIManager.setLookAndFeel() and the effective new JFrame() via super(...) does not guarantee you that the whole UI will be in Nimbus, parts of it might still be in Metal. I recommend to set the LaF before even constructing the first widget, to be on the safe side. As far as I remember, it's not guaranteed that changing the LaF after component construction has an effect, unless you tell the UIManager to update the LaF. See also this quote from the documentation of UIManager:
Once the look and feel has been changed it is imperative to invoke updateUI on all JComponents. The method SwingUtilities.updateComponentTreeUI(java.awt.Component) makes it easy to apply updateUI to a containment hierarchy. Refer to it for details. The exact behavior of not invoking updateUI after changing the look and feel is unspecified. It is very possible to receive unexpected exceptions, painting problems, or worse.
http://docs.oracle.com/javase/8/docs/api/javax/swing/UIManager.html
setSize() vs. pack() with a little help of Insets and Border
Instead of setting the size manually, you might want to play with Insets or Border and JFrame.pack() in order to get a decent layout of your window. Setting the size manually assumes that you know a lot about the screen resolution and the font size of the user.
The pack() method performs automatic size calculation based on the contents. Insets and Border allow you to create some space and borders, even with some designs or labels, around components so they wouldn't be cramped tightly in a window but be nicely spaced.
First you have to assign an actionListener to the ReFresh Jbutton.
You can either implement the interface ActionListener to the class, and override the actionPerformed() method like this
public class View extends JFrame implements ActionListener{
private JButton ReFresh;
public View() {
super("PDF Viewer");
setLookAndFeel();
setSize(500, 125);
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
FlowLayout flo = new FlowLayout();
setLayout(flo);
JTextField Search = new JTextField ("Search", 29);
JButton Search1 = new JButton("Search");
//this is where i have the button
ReFresh = new JButton("ReFresh");
ReFresh.addActionListener(this);
add(Search);
add(Search1);
add(ReFresh);
setVisible(true);
}
private void setLookAndFeel() { //right way for nimbus: http://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/nimbus.html
try {
for (LookAndFeelInfo info : UIManager.getInstalledLookAndFeels()) {
if ("Nimbus".equals(info.getName())) {
UIManager.setLookAndFeel(info.getClassName());
break;
}
}
}
catch (Exception e) {
e.printStackTrace();
}
}
#Override
public void actionPerformed(ActionEvent e)
{
if(e.equals(ReFresh))
{
super.repaint();
}
}}
public static void main(String[] args) {
View pdf = new View();
}
Or you can do inline assignment to addActionListener, like this
ReFresh.addActionListener(new ActionListener()
{
#Override
public void actionPerformed(ActionEvent e)
{
super.repaint();
}
});
You can try these methods to refresh/reload the JFrame,
invalidate();
validate();
repaint();
you can also use dispose(); and then new View(); to create the new JFrame, but in this sequence it will close the window and create new one.
or you can even try setVisible(false); then setVisible(true);
I recommend the first 3.
I am programming a menu to be used with a formerly all text based game. I am trying to use addActionListener to print a line of text when a button is clicked, so I can figure out how to implement my main code in the future. The issue I am having is with the addActionListener method on my JButton. I am performing all of this with a JFrame. From what others say, I have used this as the argument but am getting a "non-static variable this cannot be referenced from a static context" error. Here is my code:
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
public class Menu
{
public static void Menu()
{
JButton button = new JButton("Click to enter");
button.setBounds(125, 140, 150, 20);
JFrame frame = new JFrame("Casino");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.add(button);
button.addActionListener(this);
JLabel emptyLabel = new JLabel("");
emptyLabel.setPreferredSize(new Dimension(400, 300));
frame.getContentPane().add(emptyLabel, BorderLayout.CENTER);
frame.pack();
frame.setVisible(true);
}
public void actionPerformed(ActionEvent e)
{
#Override
String s = "Welcome!";
System.out.println(s);
}
}
Currently your program is nothing more than a single static method with everything trying to be shoehorned into this method. This would be fine if you were creating the most basic console program, such as one that asks the user for 2 numbers, then adds the numbers and returns the answer, but you are no longer trying to do this. Instead you're trying to create a Swing GUI program, one whose state you wish to change if the user interacts with it in an event-driven way, in other words you want it to change state if the user presses a button or selects a menu item.
Your problem is that you're trying to mesh this simple static world with the "instance" world, but in static land, there is no this.
Since your needs and requirements are becoming more complex, your program structure will need to change to reflect this. Is this an absolute requirement that you do this? No -- something called Turing Equivalence tells that it is possible to write most complex program imaginable inside of a single static main method, but due to the increased complexity, the program would become very difficult to understand and almost impossible to debug.
What I recommend specifically is that you create one or more well behaved object-orient classes, classes with non-static variables and non-static methods, and use these to build your GUI and its model (the non-GUI nucleus that GUI programs should have). Again the main method should be short, very short, and should only involve itself in creating the above classes, and setting the GUI visible, and that's about it.
What you want to do is to study the basic concepts of Java, and in particular that on how to create Java classes. The Java tutorials can help you with this.
There are a number of issues with this class.
It does not implement ActionListener so it can't be used as parameter to JButton
The static modifier on the Menu method means you can even use this anyway
public static void Main is not a constructor, so beware
#Override should appear before the method declaration, not in it.
Something like...
public class Menu implements ActionListener
{
public Menu()
{
JButton button = new JButton("Click to enter");
button.setBounds(125, 140, 150, 20);
JFrame frame = new JFrame("Casino");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.add(button);
button.addActionListener(this);
JLabel emptyLabel = new JLabel("");
emptyLabel.setPreferredSize(new Dimension(400, 300));
frame.getContentPane().add(emptyLabel, BorderLayout.CENTER);
frame.pack();
frame.setVisible(true);
}
#Override
public void actionPerformed(ActionEvent e)
{
String s = "Welcome!";
System.out.println(s);
}
}
Might be a better approach, but I'd be worried about creating a JFrame within the class, but that's just me...
I've looked at other JLabel threads and though similar, a few just don't seem to apply to what I'm experiencing. First, I want to say I am a novice when it comes to Java. Next, I am trying to follow tutorials and demos at the docs.oracle.com site. Now, I can update the label when I type something into a JTextField and there is an ActionListener on that...
But I also have a Menu, and when I select a Menu Item, that Action does not want to update the label.
Questions -
How do I have action listeners on both JTextFields and JMenuItems? Are there two ActionEvent methods or do I use one method and somehow identify each type of action?
If I use the same basic code in the JTextField ActionEvent and JMenuItem ActionEvent, the JLabel updates correctly with the JTextField event but not JMenuItem event. They both use the messageField.setText property. Could the JMenuItem action be doing something to block the setText?
I can easily copy code in here, but it's pretty spaghetti-like at the moment, so if you want to see anything, let me know specifically and I'll post it.
I would appreciate any assistance that anyone would be able to provide.
---edit---
Wow!! Thanks for all of the comments and suggestions.
1 - I know it has to be my code. As I mentioned, I am really just cobbling stuff together from demos and tutorials, and trying to learn Java along the way. I've just never gotten the hang of object oriented....
2 - I do know the individual Listeners are working. I'm using System.out.println to validate, as well as inspecting those labels in debug mode to see they have indeed changed.
3 - I will look at the various links and code posted here and see if I can figure out what's wrong with my code.
Really, thanks again!
---edit---
Here is what I originally had in my createAndShowGUI method....
private static void createAndShowGUI()
{
JFrame frame = new JFrame("Create XML for Photo Gallery");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
CreateGalleryXML window = new CreateGalleryXML();
frame.setJMenuBar(window.createMenuBar());
frame.add(new CreateGalleryXML());
frame.pack();
frame.setVisible(true);
}
Seems like you yourself are doing something wrong, in your code. Without a proper SSCCE it's hard to say what thing you doing wrong, since it works perfectly, using same ActionListener for both JMenuItem and JTextField.
Here is a sample program to match with yours :
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
public class UpdateLabel
{
private JLabel label;
private String labelText;
private ActionListener action = new ActionListener()
{
public void actionPerformed(ActionEvent ae)
{
setLabelText((String) ae.getActionCommand());
label.setText(getLabelText());
}
};
private void setLabelText(String text)
{
labelText = text;
}
private String getLabelText()
{
return labelText;
}
private void createAndDisplayGUI()
{
final JFrame frame = new JFrame("Update Label");
frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
frame.setLocationByPlatform(true);
JMenuBar menuBar = new JMenuBar();
JMenu programMenu = new JMenu("Program");
JMenuItem exitMenuItem = new JMenuItem("Exit");
exitMenuItem.addActionListener(new ActionListener()
{
public void actionPerformed(ActionEvent ae)
{
frame.dispose();
}
});
JMenu labelMenu = new JMenu("Label");
JMenuItem updateMenuItem = new JMenuItem("Update Label");
updateMenuItem.setActionCommand("Updated by JMenuItem");
updateMenuItem.addActionListener(action);
programMenu.add(exitMenuItem);
labelMenu.add(updateMenuItem);
menuBar.add(programMenu);
menuBar.add(labelMenu);
frame.setJMenuBar(menuBar);
JPanel contentPane = new JPanel();
label = new JLabel("I am the LABEL which will be updated!!");
contentPane.add(label);
JTextField tfield = new JTextField(10);
tfield.setActionCommand("Updated by JTextField");
tfield.addActionListener(action);
frame.add(contentPane, BorderLayout.CENTER);
frame.add(tfield, BorderLayout.PAGE_END);
frame.pack();
frame.setVisible(true);
}
public static void main(String... args)
{
SwingUtilities.invokeLater(new Runnable()
{
public void run()
{
new UpdateLabel().createAndDisplayGUI();
}
});
}
}
And here is the output in both the cases :
and
Do check out the main method, might be you had failed to put your code inside EDT - Event Dispatcher Thread, that can lead to such issues too. All updates on the Swing GUI, must be done on the Event Dispatcher Thread.
LATEST EDIT
It seems to me that CreateGalleryXML extends JPanel by the look of it. See at Line 3 of this below code taken from your update, here you are initializing a new Object of CreateGalleryXML inside, when you already had one Object window created at Line 1:
CreateGalleryXML window = new CreateGalleryXML();
frame.setJMenuBar(window.createMenuBar());
frame.add(new CreateGalleryXML());
So try to change the above thingy to this
CreateGalleryXML window = new CreateGalleryXML();
frame.setJMenuBar(window.createMenuBar());
frame.add(window);
and see what happens and Please do revert back again :-)
Use Action to encapsulate common functionality that must be shared by menus and related components. See this example that extends AbstractAction.
Pretty much everything you could need to know is in the Java tutorials. Down the bottom they have demo's on how to do both menu's and text fields. They include source code to look at as well.
There's not much more I can say that they don't say better, but in answer to your questions:
Both, you can have separate listener's on each component, or one that figures out what component is responsible for causing the action event. I would suggest you use separate ones for each thing.
Can't really say with out seeing the code, are you sure that the action on the JMenu is even firing? Does it print something to the console etc if you use System.out.println somewhere?