We Keep Coding

Refresh java program with Button

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.

Java Frame can't close When using certain input method

Below is 2 simple java ui application, I found if the current IME is google pinyin When I click the right-upper close button of this Frame in Windows 7 and Windows XP OS, the frame can be closed but the EDT thread doesn't terminate.
the google pinyin IME download address is http://dl.google.com/pinyin/v2/GooglePinyinInstaller.exe.
And recently I found this situation also occurs when using Baidu Pinyin IME(another chinese input method). Diffrently, it occurs only when using swing, randomly(the EDT thread can't terminate for a period of time, and become normal later).
I've read a article blaming the same problem similar to me long ago, and the author didn't come out with a solution too. I thought this is a bug in Google IME.
I know most people view this question may not be Chinese and may be unable to install these 2 IME and try my samples, but it's just too ridiculous for me, how can these two things have relations??? do anybody have some idea to explain it based on your knowledge? I'll appreciate very much!
// AWT
EventQueue.invokeLater(new Runnable() {
#Override
public void run() {
final Frame frame = new Frame("test");
frame.addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent we) {
frame.dispose();
}
});
frame.setSize(400, 400);
frame.setVisible(true);
}
});
Below is Swing
// Swing
EventQueue.invokeLater(new Runnable() {
#Override
public void run() {
JFrame frame = new JFrame("swing");
frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
frame.setSize(400, 400);
frame.setVisible(true);
}
});
As #MadProgrammer mentioned. I changed my code, using System.exit(0) in AWT and frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE) in swing, the result is I can't close the frame, when I click the close button, nothing happens.

You should try using an exit listener, for example:
this.addWindowListener(new MyExitListener());
And the exit listener class:
public class MyExitListener extends WindowAdapter {
#Override
public void windowClosing(WindowEvent e) {
System.exit(0);
}
}
This is what I usually do, and it always works.

JFrame looks different depending on how its loaded

I have a JFrame:
public class Help extends JFrame {
private JPanel contentPane;
/**
* Launch the application.
*/
public static void main(String[] args) {
try {
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
} catch (Throwable e) {
e.printStackTrace();
}
EventQueue.invokeLater(new Runnable() {
public void run() {
try {
Help frame = new Help();
frame.setVisible(true);
} catch (Exception e) {
e.printStackTrace();
}
}
});
}
/**
* Create the frame.
*/
public Help() {
setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
setBounds(100, 100, 450, 300);
contentPane = new JPanel();
contentPane.setBorder(new EmptyBorder(5, 5, 5, 5));
contentPane.setLayout(new BorderLayout(0, 0));
setContentPane(contentPane);
}
}
If i run this in Eclipse i get the following:
Now if call this from the ActionListener of a JButton within another JFrame using:
btnHelp.addActionListener(new ActionListener(){
#Override
public void actionPerformed(ActionEvent arg0) {
EventQueue.invokeLater(new Runnable() {
public void run() {
try {
Help frame = new Help();
frame.setVisible(true);
} catch (Exception e) {
e.printStackTrace();
}
}
});
}
});
Then the JFrame loads looking like this:
This looks ugly to me. Why isn't the first style loading when i initialize the JFrame from within another JFrames JButton ActionListener? It seems to me like i'm running exactly the same code with both methods of loading it.

This particular segment of code:
try {
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
} catch (Throwable e) {
e.printStackTrace();
}
Changes what we call the look & feel of the JFrame. This includes everything from button graphics, animations to sizes and proportions of default sized components in the frame. The look and feel must be set before the JFrame is drawn onto the screen and changing it around mid-program can be quite tricky. As such, I believe your second invocation from the actionListener happens either without the presence of the look at feel code or happens before the setting of the look and feel.
Since it is a "global" attribute (that is, it affects all frames in the running program) I personally put it as the first statement in my main() method as to protect against any sort of potential accidental creations of frames before the statement is invoked.
Please note though, without setting the look and feel, java assumes a default cross-platform view which stays constant across all operating systems. UIManager.getSystemLookAndFeelClassName() changes this behavior to allow for a system-specific L&F. You may need to take this in mind when distributing the program across OSes as with a system-specific L&F, fine-tuned layouts may be destroyed due to differing component sizes.

In your second example, the new JFrame will have the same look and feel as the other JFrames in the application.
Your comments indicate that you are not setting the look and feel for that application.
Use a line similar to the one in your first example to do this.

JFrame question

What code is called when a JFrame is minimized? Is it hooked up to a listener? I just want to know what happens internally when the frame is minimized.
EDIT:
Im actually looking for the code that is called when the frame is minimized. For example, the code for the actual windowListener. Ive been searching through JFrame, Frame, and Window searching for windowIconified but have been unable to find the actual code.
Reason being, when my program runs, it has a small defect with one of the Panels, but when I minimize and maximize the JFrame, the problem goes away. I wanted to see what was going on so that I can apply whatever is going on to my Panel so it paints right.

you can listening by using WindowListener
for example
import java.awt.event.WindowEvent;
import java.awt.event.WindowListener;
import javax.swing.JFrame;
public class WinStateListener implements WindowListener {
static JFrame window = new JFrame("Window State Listener");
public WinStateListener() {
window.setBounds(30, 30, 300, 300);
window.addWindowListener(this);
window.setVisible(true);
}
public static void main(String[] args) {
WinStateListener winStateListener = new WinStateListener();
}
public void windowClosing(WindowEvent e) {
System.out.println("Closing");
window.dispose();
System.exit(0);
}
public void windowOpened(WindowEvent e) {
System.out.println("Opened");
}
public void windowClosed(WindowEvent e) {
System.out.println("Closed");
}
public void windowIconified(WindowEvent e) {
System.out.println("Iconified");
}
public void windowDeiconified(WindowEvent e) {
System.out.println("Deiconified");
}
public void windowActivated(WindowEvent e) {
System.out.println("Activated");
}
public void windowDeactivated(WindowEvent e) {
System.out.println("Deactivated");
}
}

You want to read about WindowListeners and WindowEvents. The event you are talking about is called Iconifying the window. Read more here:
http://download.oracle.com/javase/tutorial/uiswing/events/windowlistener.html
EDIT:
Use revalidate() then repaint() on the JPanel that is acting up.

When minimizing the JFrame application a window event windowIconified is called. If you want to process such window events by your own then either implement WindowListener interface or use WindowAdapter abstract class.

What code is called when a JFrame is minimized?
As noted in How to Make Frames: Specifying Window Decorations, "window decorations are supplied by the native window system." The article goes on to describe some changes you can make to the host platform's default.
Addendum: Reading your update, note that restoring an iconified window repaints it. As #Andrew Thompson points out, you may need to verify that you're building on the event dispatch thread. You may also need to schedule a repaint(). An sscce might clarify things.

Keyboard input in Java Applet

What is the best way to listen for keyboard input in a Java Applet?
I have an applet which opens a JFrame and I am using a KeyListener to listen for keyboard input. This works fine in my development environment (eclipse), but when I run the applet through a browser (I have tried Firefox and IE) it does not respond to keyboard events.
However, if I run the applet and then minimize and maximize the frame, it works.
I have tried setting focus to the JFrame in many different ways and also programmatically minimizing and maximizing it, but to no effect.
I have also tried key bindings, but with the same problem.
I have trimmed my code down to the barest essentials of the problem and pasted it below.
Can someone see what I am doing wrong or suggest a better solution?
public class AppletTest extends Applet
{
private GuiTest guiTest;
public void init() {
guiTest = new GuiTest();
final AppletTest at = this;
guiTest.addKeyListener(new KeyListener() {
public void keyPressed(KeyEvent ke) {
at.keyPressed(ke);
}
public void keyReleased(KeyEvent ke) {}
public void keyTyped(KeyEvent e) {}
});
}
private void keyPressed(KeyEvent ke)
{
System.out.println("keyPressed "+KeyEvent.getKeyText(ke.getKeyCode()));
getGuiTest().test(KeyEvent.getKeyText(ke.getKeyCode()));
}
}
public class GuiTest extends JFrame {
String teststring = "?";
public GuiTest()
{
setSize(100,100);
setEnabled(true);
setVisible(true);
setFocusable(true);
requestFocus();
requestFocusInWindow();
toFront();
}
public void test(String t)
{
teststring = t;
repaint();
}
public void paint(Graphics g)
{
g.setColor(Color.white);
g.fillRect(0, 0, getWidth(), getHeight());
g.setColor(Color.black);
g.drawString(teststring, 50, 50);
}
}

I solved the problem. If I create the JFrame following a button press or mouse event on the applet, the key listener on the JFrame works. Apparently, creating the frame from Applet.init() means that key listeners do not function correctly when opened through a browser.
However, the question remains - why? If someone can explain this, I would greatly appreciate it.
I thought it might be because the frame should be created on the event dispatch thread, but using SwingUtilities.invokeLater or invokeAndWait did not work.

I think you are running into the plugin focus issue: in many modern browser a plugin only gains focus through either the user clicking on it or using Javascript. This typically affects Flash but it might be that it also affects applets. Try Adobe's recommendations at http://kb2.adobe.com/cps/155/tn_15586.html.
Let me know if that works for you.