This blog contains some snippets of code that I tend to use in Java. I acknowledge that somebody else writing this blog might include different code. Except for a short course at Sun Educational Services, most of my Java programming skills are self-taught. I’m unsure if people with formal backgrounds in computer science might have different styles and conventions. Mine have been shaped primarily by my needs.
Creating a Graphical User Interface (GUI)
In this blog, I use the term “interface” to describe a screen that the user uses in order to interact with the program; this is also known as a GUI. I faintly recall that the term “interface” from a coding standpoint on Java has a more specific meaning; but I am invoking the vernacular sense of the term. I am a fairly lazy user-interface developer these days. I tend to use whatever fields, buttons, panels, and text fields are available on the platform. Perhaps as a further sign of my lack of discipline, I don’t even bother documenting or memorizing the mandatory lines required by Java to enable its interface components. I literally allow the compiler to give me error messages until all of the necessary lines have been added. Below, as the image of a particular interface I created shows, the user is free to construct his or her components. Alternatively, there are platform-independent components available from Java itself.
In general – except maybe for content or entry validation purposes – no calculations should be done on the code for the interface. If lengthy calculations are performed from the GUI, it might struggle to update or refresh; and it might stop responding to user input completely. This problem should be of particular concern to data scientists. Below I share the code simply to close the window. It is the implementation of WindowListener (the interface) that creates the need for the methods like windowClosed(), windowDeactivated(), and windowDeiconified. At some point during the construction of the user interface, it is necessary to invoke “addWindowListener(this)”; this will cause the program to actually listen to the window.
import java.awt.*;
import java.awt.event.*;
public class Facade extends Frame implements WindowListener {
public Facade() {}
public void windowClosed(WindowEvent e) {}
public void windowActivated(WindowEvent e) {}
public void windowDeactivated(WindowEvent e) {}
public void windowDeiconified(WindowEvent e) {}
public void windowIconified(WindowEvent e) {}
public void windowOpened(WindowEvent e) {}
public void windowClosing(WindowEvent e) {}
}
During the early years of Java, there was a completely different way of causing the GUI to respond to the user. I remember that mixing the two methods caused my programs to crash hard. However, since the change, I have personally found the GUIs exceptionally stable. The only problem might be forgetting to handle user input: e.g. actually closing the window after the user clicks a button that says “Close Window.” Then I have to use Taskmaster to close the program.
Executing a System Command During Runtime
I routinely invoke Notepad on Windows to open a file containing text. It is possible I just generated the file; or perhaps I recently updated it. During diagnostics, I normally have my programs retain one or several runtime logs, which I sometimes cause to open automatically after the program has finished running or in the event of questionable events. Also rather frequently, I make Windows open spreadsheets and HTML files after they are compiled.
public void notepad(String s) {
command(“Notepad \”” + s + “”\””””);
}
public void send(String s) {
command(“”Explorer \”””” + s + “”\””””);
}
public void command(String s) {
try {
System.out.println(“”Command sent: “” + s);
(Runtime.getRuntime()).exec(s);
}
catch(IOException x) {
System.out.println(“”Exception raised””);
}
}
So using the above
