«

o.k.

on the sun website they have these cryptic words:
To avoid the possibility of deadlock, you must take extreme care that
Swing components and models are created, modified, and queried only from
the event-dispatching thread.

and they give this sample code:
javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
createAndShowGUI();
}
});

my question is this.
"create and modify" means just that ... even creating.

i had thought of making a class, having it extend JFrame and implement
Runnable, like so:

class MyGUI extends JFrame implements Runnable {
MyGUI()
...

public void run()
...
}

then do:
javax.swing.SwingUtilities.invokeLater(new MyGUI());

but in fact, that wouldn't be following Sun's advice to the letter i
guess, would it ?

Because the JFrame object (MyGUI) would be created, and then the handle
to this object would be passed to invokeLater().
So in fact, part of the GUI would have already been created in the
"main" thread.

So I guess I need to create my MyGUI object from within a method, say
createGUI(), as opposed to "on-the-fly" like this ?

electric sheep wrote:
> on the sun website they have these cryptic words:
> To avoid the possibility of deadlock, you must take extreme care that
> Swing components and models are created, modified, and queried only from
> the event-dispatching thread.
>
> and they give this sample code:
> javax.swing.SwingUtilities.invokeLater(new Runnable() {
> public void run() {
> createAndShowGUI();
> }
> });
>
> my question is this.
> "create and modify" means just that ... even creating.

Yes, apparently so. Initially, the advice from Sun was to avoid
accessing a component from the event dispatch thread after it's
realized. It seems Sun has recently begun advising to do all method
calls on GUI components in the event dispatch thread, however... even if
they do not have peers at the time.

I'm not aware of the precise motivation for this switch (i.e., I don't
know of a test case that fails when non-realized components are accessed
from a non-event thread.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

In article <eJOqc.4845372$>,
electric sheep <> wrote:

>.k.
>:
>n the sun website they have these cryptic words:
>:To avoid the possibility of deadlock, you must take extreme care that
>:Swing components and models are created, modified, and queried only from
>:the event-dispatching thread.
>:
>:and they give this sample code:
>: javax.swing.SwingUtilities.invokeLater(new Runnable() {
>: public void run() {
>: createAndShowGUI();
>: }
>: });
>:
>:my question is this.
>:"create and modify" means just that ... even creating.
>:
>:i had thought of making a class, having it extend JFrame and implement
>:Runnable, like so:
>:
>:class MyGUI extends JFrame implements Runnable {
>: MyGUI()
>: ...
>:
>: public void run()
>: ...
>:}
>:
>:then do:
>:javax.swing.SwingUtilities.invokeLater(new MyGUI());
>:
>:but in fact, that wouldn't be following Sun's advice to the letter i
>:guess, would it ?
>:
>:Because the JFrame object (MyGUI) would be created, and then the handle
>:to this object would be passed to invokeLater().
>:So in fact, part of the GUI would have already been created in the
>:"main" thread.
>:
>:So I guess I need to create my MyGUI object from within a method, say
>:createGUI(), as opposed to "on-the-fly" like this ?

If Sun's really saying "create and modify" then they're confusing the
issue more than is needed. It's perfectly OK to create GUI components
outside the EDT (as in JPanel panel = new JPanel(), for instance). What
you must not do is cause them to be shown, hidden, added to visible
components, or otherwise have their state changed in a way that would
result in painting and some other actions. So it's just fine to
instantiate your GUI class, but do NOT call pack, or setVisible(true),
or a variety of other things which cause the component hierarchy to be
"realized".

= Steve =
--
Steve W. Jackson
Montgomery, Alabama

Steve W. Jackson wrote:

> If Sun's really saying "create and modify" then they're confusing the
> issue more than is needed. It's perfectly OK to create GUI components
> outside the EDT (as in JPanel panel = new JPanel(), for instance). What
> you must not do is cause them to be shown, hidden, added to visible
> components, or otherwise have their state changed in a way that would
> result in painting and some other actions. So it's just fine to
> instantiate your GUI class, but do NOT call pack, or setVisible(true),
> or a variety of other things which cause the component hierarchy to be
> "realized".

They're saying this for a reason:

read
<http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html>
for the explanation.

--
Kind regards,
Christophe Vanfleteren

In article <grQqc.118044$>,
Christophe Vanfleteren <> wrote:

>:Steve W. Jackson wrote:
>:
>:> If Sun's really saying "create and modify" then they're confusing the
>:> issue more than is needed. It's perfectly OK to create GUI components
>:> outside the EDT (as in JPanel panel = new JPanel(), for instance). What
>:> you must not do is cause them to be shown, hidden, added to visible
>:> components, or otherwise have their state changed in a way that would
>:> result in painting and some other actions. So it's just fine to
>:> instantiate your GUI class, but do NOT call pack, or setVisible(true),
>:> or a variety of other things which cause the component hierarchy to be
>:> "realized".
>:
>:They're saying this for a reason:
>:
>:read
>:<http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html>
>:for the explanation.

I've already read that. And there's nothing in their so-called
explanation that indicates why creating components can be problematic so
long as nothing in the hierarchy has been realized. I have always
adhered to the rule that I build my component hierarchy completely but
never do anything else to it that's not on the EDT -- except once, when
I learned the hard way that I actually had displayed a JWindow on the
main thread.

= Steve =
--
Steve W. Jackson
Montgomery, Alabama