Swing Programming Question

Thread view:

Angus - 09 Feb 2005 03:30 GMT

Hi, and thanks for reading this.

I have a simple Swing application. When launching the application,
it displays a "JFrame" that contains a "JButton". When activating the
"JButton", a custom "JDialog" is opened. The custom "JDialog" is a
class that I wrote that extends "JDialog". The constructor for this
custom "JDialog" builds the dialog and displays it. Currently, the
"actionPerformed()" method (of the "JButton", in the "JFrame") invokes
the custom "JDialog"'s constructor (no, not every time, but the
constructor has to be called sometime, right?). My question is, should
the constructor invocation be wrapped in a
"SwingUtilities.invokeLater()" or "SwingUtilities.invokeAndWait()",
or not?

Thanks (in advance),
Avi.

Reply to this Message

Babu Kalakrishnan - 09 Feb 2005 04:53 GMT

> Hi, and thanks for reading this.
>
[quoted text clipped - 9 lines]
> "SwingUtilities.invokeLater()" or "SwingUtilities.invokeAndWait()",
> or not?

If the constructor is being called from the actionPerformed method,
there is no need to wrap it in either. This is because the ActionEvent
on the JButton always occurs in the Event Dispatch Thread - so you're
already in the EDT when the constructor is being called.

BK

Reply to this Message

hiwa - 09 Feb 2005 08:56 GMT

> Hi, and thanks for reading this.
>
[quoted text clipped - 12 lines]
> Thanks (in advance),
> Avi.

No. Instantiation of your custom dialog shoud be done in the
constructor of your main app class because GUI component instantiation
is an expensive task. In the event handler,
update only the state of that dialog, typically visiblity on/off.

If you do a lengthy task in the event handler, then do it in
another thread. And, again if, you have to update GUI from
within the thread, wrap it with the invokeLater() or
invokeAndWait().

Reply to this Message

Babu Kalakrishnan - 09 Feb 2005 13:12 GMT

>>Hi, and thanks for reading this.
>>
[quoted text clipped - 17 lines]
> is an expensive task. In the event handler,
> update only the state of that dialog, typically visiblity on/off.

I would generally disagree with this advice.

One of the main problems with Swing based applications is its slow
startup time. If one were to create (and force a validation of - without
which it would be pointless) all possible dialogues that the application
may create in the Main app's constructor, it would only add to that, and
twiddling one's thumbs after clicking on the Application start icon is
one thing that any user really really hates.

In addition, most dialogues are generally built based on some specific
context in the application. This would normally require (a) the parent
of the dialog to be a specific frame in the application and/or (b) the
contents of the dialog to be chosen based on the context. If one has
requirement (a), you can never create such a dialog ahead of time
because the parent needs to be specified at construct time. If you have
a requirement for (b), this would necessitate a revalidation of the
dialog (by calling pack()) once again which would negate any advantage
that you had gained by constructiong it ahead of time.

When a user clicks a button, he would normally expect a small delay in
the response - In my experience a delay of upto say half a sec. is
generally not preceived by the user as a real irritant. So keeping your
dialogs simple enough as to be able to become visible within that delay
is probably the better solution.

BK

Reply to this Message

Swing Programming Question

Free Magazines