I have the following code snippets. Both has a method call to
addWindowListener
It is my understanding that BookOrderFrame is using a callback method
to implement the interface for WindowListener. Am I correct?
LoanCalculatorFrame otoh, does it substantially different and does not
even state "implements WindowListener".
So can anyone please explain what LoanCalculatorFrame does and whether
and how it is better/worse than what BookOrderFrame is doing?
Thanks.
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import java.text.*;
public class LoanCalculatorFrame extends JFrame
{
public LoanCalculatorFrame()
{
setTitle("Loan Calculator");
Toolkit tk = Toolkit.getDefaultToolkit();
Dimension d = tk.getScreenSize();
System.out.println("Screen:" + d.width + " by " + d.height + "
pixels");
int height = 200;
int width = 267;
setBounds((d.width-width)/2, (d.height-height)/2, width, height);
setResizable(false);
addWindowListener(new WindowAdapter()
{
public void windowClosing(WindowEvent e)
{
System.exit(0);
}
}
);
Container contentPane = getContentPane();
JPanel panel = new JPanel();
contentPane.add(panel);
}
}
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import java.text.*;
public class BookOrderFrame extends JFrame implements WindowListener
{
public BookOrderFrame()
{
setTitle("Book Order");
setBounds(267, 200, 267, 200);
addWindowListener(this);
}
public void windowDeactivated(WindowEvent e)
{
}
public void windowActivated(WindowEvent e)
{
}
public void windowDeiconified(WindowEvent e)
{
}
public void windowIconified(WindowEvent e)
{
}
public void windowClosed(WindowEvent e)
{
}
public void windowClosing(WindowEvent e)
{
System.exit(0);
}
public void windowOpened(WindowEvent e)
{
}
}
IchBin - 31 Dec 2005 05:39 GMT
> I have the following code snippets. Both has a method call to
> addWindowListener
[quoted text clipped - 86 lines]
> }
> }
The Docs for WindowListener Interface I think explains it.
The listener interface for receiving window events. The class that is
interested in processing a window event either implements this interface
(*and all the methods it contains*) or extends the abstract
WindowAdapter class (*overriding only the methods of interest*).

Signature
Thanks in Advance...
IchBin, Pocono Lake, Pa, USA
http://weconsultants.servebeer.com/JHackerAppManager
__________________________________________________________________________
'If there is one, Knowledge is the "Fountain of Youth"'
-William E. Taylor, Regular Guy (1952-)
Mike - 31 Dec 2005 06:00 GMT
> > I have the following code snippets. Both has a method call to
> > addWindowListener
[quoted text clipped - 7 lines]
> > So can anyone please explain what LoanCalculatorFrame does and whether
> > and how it is better/worse than what BookOrderFrame is doing?
<snipped code >
> The Docs for WindowListener Interface I think explains it.
>
> The listener interface for receiving window events. The class that is
> interested in processing a window event either implements this interface
> (*and all the methods it contains*) or extends the abstract
> WindowAdapter class (*overriding only the methods of interest*).
I am sorry if I didn't explain myself very well. I understand (I think)
what WindowListener interface does. What I don't understand is the
differences in the implementation between the two example classes that
I posted.
Ricky Clarkson - 31 Dec 2005 12:50 GMT
The second one is implementing an anonymous inner class in these lines:
addWindowListener
(
new WindowAdapter()
{
public void windowClosing(WindowEvent e)
{
System.exit(0);
}
}
);
The outermost { and } above are the boundaries of the class, and the
class extends WindowAdapter. I personally don't like this syntax, and
always make it a separate top-level class, but many like it, because
it's brief. However, it isn't simple. An anonymous inner class always
maintains a reference to the enclosing instance, which can affect
garbage collection. It can access private members of its enclosing
class (which is implemented in terms of generated accessor methods),
which you might see as a break of encapsulation.
It can access local variables from the enclosing
method/constructor/initialiser, which have to be final (don't worry,
you'll get a compiler error telling you about this).
Because the class is anonymous, it does not promote reuse, i.e., you
can't easily refer to it again later to use the same thing somewhere
else.
There is more on this subject here:
http://java.sun.com/docs/books/tutorial/java/javaOO/innerclasses.html
Thomas Hawtin - 31 Dec 2005 14:40 GMT
> I have the following code snippets. Both has a method call to
> addWindowListener
[quoted text clipped - 4 lines]
> LoanCalculatorFrame otoh, does it substantially different and does not
> even state "implements WindowListener".
WindowListener is a callback interface. A callback is where lower level
code calls higher level code. It doesn't matter how the interface is
implemented. However, anonymous inner classes are a handy, if verbose,
language feature for this kind of work.
Neither LoanCalculatorFrame or BookOrderFrame need extend JFrame as they
do not override any methods.
It doesn't make sense for the outer class to publicly implement the
interface. So, we can safely say that is wrong.
Java doesn't allow multiple inheritance (of implementation). So as you
can see by all the blanks methods in your second example, we lose the
ability to make use of abstract implementations.
For simple cases anonymous inner classes are an easy, concise solution.
You want to add a window listener that when the window is closing, does
something. All nicely together without having to hunt stuff down. The
anonymous inner class still gets access to the outer class and final
variables of the enclosing method, so you don't need to go into some
horrible complication to share common state.
If your problem gets more complex, you can create the anonymous inner
class or make it a local inner class. More complex and a member inner
class may be more appropriate. Further complexity might result in a
static nested class, then on to a full outer class.
Closing the application (or disposing of the window) are such common
operations for trivial programs, that JFrame has a convenient method to
handle the situation.
frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
> Toolkit tk = Toolkit.getDefaultToolkit();
> Dimension d = tk.getScreenSize();
If you use frame.getGraphicsConfiguration, you can cope with multiple
screens.
Tom Hawtin

Signature
Unemployed English Java programmer
http://jroller.com/page/tackline/
Roedy Green - 03 Jan 2006 03:08 GMT
>addWindowListener(new WindowAdapter()
> {
[quoted text clipped - 4 lines]
> }
> );
This is setting up an instance of an anonymous class and passing it to
addWindowListener.
This way the Window can later invoke the callback method
windowClosing.
These are not usually thought of as callbacks, but rather as Listeners
since there can be an arbitrary number of listeners, all of whom get
their windowClosing methods called.
see http://mindprod.com/jgloss/callback.html
http://mindprod.com/jgloss/delegate.html

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Roedy Green - 03 Jan 2006 03:09 GMT
>addWindowListener(new WindowAdapter()
> {
[quoted text clipped - 4 lines]
> }
> );
WindowAdapter implements the WindowListener interface, thus so does
your anonymous class that extends WindowAdapter.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Roedy Green - 03 Jan 2006 03:11 GMT
>public class BookOrderFrame extends JFrame implements WindowListener
>{
[quoted text clipped - 8 lines]
> {
> }
Is this case you are having the component itself implement the
WindowListener interface. It must implement all the methods, whether
it is interested in them or not. With WindowAdapter, the unused
methods are automatically filled in with dummies.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.