0

I read this in an online sources:

setVisible(true) side-effect: Even if you didn't initialize the GUI on the EDT, a side-effect of calling setVisible(true) is to start the EDT thread, which continues to run and monitor the GUI.

If this is true, what is the effect of setVisible(false) on the EDT?

theButton.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e) {
System.out.println("Test 1");
System.out.println("Still Testing");
panel.remove(theButton);
panel.revalidate();
panel.repaint();
myFrame.dispose();
dothis();
myFrame.setVisible(true);
}});

Function dothis() :

    public void dothis()
{
    for (int i=0;i<9999999999;i++)
     {
        System.out.println("Test 1"+i);
     }
}

I am aware that actionPerformed() runs in the Event Dispatch thread.But in the above program,the JFrame reappears before actionPerformed() is completely executed (since dothis() is still printing),why is this happening?

  • Does myFrame.setVisible() run in a different thread?

    -Why isn't it following the event queue in this case?

    -If myFrame.setVisible initiates the EDT as said in the above statement I have added,what does myFrame.dispose() do?

I have posted similar questions before but I come up with more problems as I practise and I am not able to find online solutions for many of these.

  • Another problem which makes me believe myFrame.setVisible() runs in a different thread than EDT is that the frame reappears but the button is not removed yet.It reappears with the button in it and it reappears before actionPerformed() is completely executed.
  • I am also using the Eclipse Console,the dothis() is displaying stuff on the console,so I think dothis() must be running on a different thread than the EDT.Is this right?

Can someone give me a detailed explanation about this.Long answers are appreciated too.I couldn't find any specific issue related to my problem on the internet.Please help me.

dryairship
  • 6,022
  • 4
  • 28
  • 54
Mathews Mathai
  • 1,707
  • 13
  • 31
  • A key point here is in your first quote: "...if you didn't initialize the GUI on the EDT.." *\*IF\** If the EDT isn't started yet, then `setVisible()` will start it. Most of the time the EDT has already started, so `setVisible()` does NOT by default "run in a new thread." – markspace Jan 01 '16 at 03:41
  • @markspace Okay.I got that.Any idea about the other issue?...In my case,it seems like `setVisible()` is not running in the EDT since the frame reappears before the button disappears? – Mathews Mathai Jan 01 '16 at 03:58
  • `setVisible()` does not run in a new thread. It will run on the EDT if called from the EDT. Check here: `repaint()` "asynchronously request a paint operation" so your call to repaint might be processed after the new window is shown. http://www.oracle.com/technetwork/java/painting-140037.html – markspace Jan 01 '16 at 04:04
  • The initialization and realization of the native window don't need to happen on the EDT (because of the way that the native code works), but events from the window will passed into the Event Queue for the EDT to process, SO, it's possible for a Window to become visible before other events in the EDT have completed processing. Generally speaking, `setVisible` runs within the thread it was executed, but the action of creating a window and making it visible is handed off to the native system and the method will return while the OS completes the request and the event piping is put into place – MadProgrammer Jan 01 '16 at 04:05
  • You can sometimes run into race conditions between what the UI components want to do and the frame not yet been realised (connected to a native peer), you can see this when people try and use a `BufferStrategy` and try and create the buffer before the window is visible – MadProgrammer Jan 01 '16 at 04:07
  • The OP could try calling the final `setVisible()` method with `invokeLater()` That should defer the `setVisible()` call until all other internal events are handled, hopefully including the window repainting. C.f. the docs for `invokeLater()` https://docs.oracle.com/javase/7/docs/api/javax/swing/SwingUtilities.html#invokeLater%28java.lang.Runnable%29 – markspace Jan 01 '16 at 04:13
  • Okay.Thanks a lot.Can someone add an answer so that I can close the question by accepting it? – Mathews Mathai Jan 01 '16 at 04:44
  • @markspace's comment are correct; I'll defer to his answer. Do you have any reason _not_ to construct and manipulate GUI objects _only_ on the [event dispatch thread](http://docs.oracle.com/javase/tutorial/uiswing/concurrency/initial.html)? Also consider one of the approaches cited [here](http://stackoverflow.com/a/7788806/230513) to find violations. – trashgod Jan 01 '16 at 11:38
  • @trashgod It takes place on EDT by default..right?..I am not creating any new thread! – Mathews Mathai Jan 01 '16 at 12:55
  • @MathewsMathai: No, code executes on the [_initial thread_](http://docs.oracle.com/javase/tutorial/uiswing/concurrency/initial.html) until the _event dispatch thread‌​_ starts. If you are trying to defer lengthy initialization, do it like [this](http://stackoverflow.com/a/25526869/230513). – trashgod Jan 01 '16 at 23:49

0 Answers0