views:

367

answers:

5

Ok I've read an searched all over the web, and I've not found the solution to my problem yet, perhaps I'm missing something simple, hence here I am...

I've got a rather large project, that handles work orders for a repair business. It's all database connected, many many pages of code, and classes. But i just added a short bit of code to the front end that essentially checks for new messages in our notes area.

Anyway, I display a simple JFrame with two JLabels while a separate thread queries the database. This all happens at the start of the program. The problem is my little "please wait" Jframe comes up with its frame but no guts, no background, and no Jlabels, during the wait (which is the rest of the program loading, not the database thread), afterwords it displays, but by then its missing its point.

I wrote the following example program. It displays a simple JFrame (CheckingMessagesGUI: a JFrame with two JLabels, nothing more) sleeps for 5 sec then displays the Example (main program) JFrame, then instantly closes (System.exit(0)) in this example, of course my real program goes on to do a lot more. What I found is that InvokeLater seems to be causing the problem. Once the sleep timer runs out the window will display, but the code to display it was given before the Thread.sleep command, and should have been done in that order correct?

My question is why does InvokeLater cause my JFrame not to display correctly?

Its my understanding that the purpose of InvokeLater is so that the items run on the correct AWT event thread, which would make me think that this window would get painted correctly. Anyway I'm sure I'm missing something obvious. I commented out the InvokeLater part in the code below, and it runs correctly, if you put it back it doesn't...

Many thanks in advance.

package javaapplication6;

public class Example extends javax.swing.JFrame{

 public Example(){
      System.out.println("Example started");
      setBounds(100,100,200,200);

      System.out.println("cmGUI instantiated");
      CheckingMessagesGUI cmGUI = new CheckingMessagesGUI();
      System.out.println("Set cmGUI visible");
      cmGUI.setVisible(true);
      cmGUI.validate();
      try{
           System.out.println("timer started");
           Thread.sleep(5000);
           System.out.println("timer done");
      }catch(InterruptedException e){}
      System.exit(0);
 }

public static void main(String[] args) {
     /*java.awt.EventQueue.invokeLater(new Runnable() {
          @Override
        public void run() { */
                System.out.println("Started");
                System.out.println("example Instantiated");
                Example example = new Example();
                System.out.println("example visible");
                example.setVisible(true);
    /*      }
     });
     */
}

}

UPDATE: To clarify, i realize Thread.sleep() will block everything, but shouldn't my CheckingMessagesGUI already have been fully drawn before i call sleep? That is the issue.

+1  A: 

my understanding that the purpose of InvokeLater is so that the items run on the correct AWT event thread

That is correct.

However, that also means that Thread.sleep() is executing on the EDT, which means the GUI can't repaint itself, since you just told the EDT to sleep. You need to use a separate Thread for your long running task.

Read the section from the Swing tutorial on Concurrency for more information about the EDT.

but my point was that my "please wait" (CheckingMessagesGUI) should have already been drawn fully before i called sleep. Shouldn't this be true?

Here is my simplified understanding of the process. The frame is created and displayed because it is an OS native component. However, the contentPane and child component are lightweight components which means the Swing Repaint Manager schedules when they should be repainted. So before the repainting is scheduled, the EDT is put to sleep, and the repainting can't be done until the sleeping is finished.

You can find more infomation about the Repaint Manager in the article on Paintng in AWT and Swing.

camickr
+4  A: 

invokeLater runs the Runnable in the Event Dispatch Thread which also is used for updating the GUI.
Your sleep is blocking this Thread so the GUI also does not get serviced, no updates can be done till you return from the invokeLater code.
That's why you should not do any long (time consuming) computations in this Thread. They should be done in an different (new) Thread.

The Event Dispatch Queue states

Tasks on the event dispatch thread must finish quickly; if they don't, unhandled events back up and the user interface becomes unresponsive.

Your code could be changed to (not tested):

public Example(){
  System.out.println("Example started");
  setBounds(100,100,200,200);

  System.out.println("cmGUI instantiated");
  CheckingMessagesGUI cmGUI = new CheckingMessagesGUI();
  System.out.println("Set cmGUI visible");
  cmGUI.setVisible(true);
  cmGUI.validate();

  Thread thread = new Thread(new Runnable() {
      try{
           System.out.println("timer started");
           Thread.sleep(5000);
           System.out.println("timer done");
      }catch(InterruptedException e){}
      System.exit(0);
  });
  thread.start();
}

EDIT: let's go a bit "deeper" (and it's my view of the working of Swing/AWT).
I suppose the "please wait" (see comments) should be displayed in the CheckingMessagesGUI class, but isn't.
That's related to the way the GUI works. It does not directly change anything on the display if you call the corresponding (Swing) methods (draw, setText, setLocation, ...); it just queues an Event in the Event Queue. The Event Dispatch Thread is (should be) the only Thread that reads this queue and process the events. As long as it is being blocked - by the sleep in this case - no changes to the GUI will be displayed. The GUI is frozen.

EDIT2:
invokeLater the Runnable is appended to the end of the queue to be latter executed by the EDT after all pending events have been processed, the next command after the invokeLater call will be executed.
invokeAndWait same as above but the actual Thread blocks until the Runnable was executed (after pending events) by the EDT, that is, the command following the invokeAndWait will only get started after the submitted Runnable was executed.

Carlos Heuberger
@Marc: No it won't paint because the painting is a separate event which was posted to the event queue but never processes. Painting does not happen inline with GUI construction (since it needs to arise from a system request to paint to a specific graphics context).
Software Monkey
I think this might be the key "no updates can be done till you return from the invokeLater code.". I realize that Thread.sleep() blocks everything in my example, but my point was that my "please wait" (CheckingMessagesGUI) should have already been drawn fully before i called sleep. Shouldn't this be true?
Marc
@Software Monkey: But it works if you don't use InvokeLater? why?
Marc
I might have just thought up the answer to my own question. Without the InvokeLater call, the EDT is not tied up and can paint, because my code is running in the init Thread? is that right?
Marc
I'm thinking out loud... but if that's true then no paint operations happen when the code inside the InvokeLater is running? That probably should be mentioned somewhere.
Marc
So InvokeLater blocks paint from happening, is that not what InvokeAndWait is suppose to do?
Marc
Why did you accept the answer if you don't understand the solution? I sure you ignored my answer since I didn't provide code and now you are confused. Try reading the link I provided which explains everything. That why I post the link to the tutorial because it explains better than the code what happens.
camickr
First, I didn't ignore your answer, and i didn't really read Carlos's code (so the code didn't matter), my first comment stated the key. Second, I'm new to this site, and didn't really understand how the answer thing works (but his is still the best answer, so far) Also, I had already read that tutorial before i asked my original question (several times, and again just now), it doesn't go that deep or answer my question. I also knew that sleep was blocking (that wasn't the problem, just the example), and you were talking about repainting, I was saying that it never painted the first time.
Marc
It didn't occur to me that accepting his answer might block others from answering until just now, so for the time being if un-accepted his answer if that's the case. Perhaps that should be made more clear on this site.
Marc
Ahh a few manipulations of my example program later, and I've tested and worked out my answer (OF COURSE, THANKS TO EVERYONE OUT HERE). everything in the InvokeLater method get submitted to the EDT as a chunk, which holds up the paint which falls later in the queue. It does then return to the first line after the InvokeLater call and runs anything there, so it doesn't block entirely (as InvokeAndWait would do), as a previous comment/question of mine suggested.
Marc
So why did the "please wait" frame outline get painted but not the contents? Should the contents not be painted at the same time as the frame since a single method, setVisible(...) is used to show the frame. I'm not sure what your comment on invokeAndWait() is about. You would still have the same problem because you are causing the EDT to sleep.
camickr
setVisible() does not show the component; it just marks it as visible and quques an event for it to be (re)painted. The event will stay in the queue until the EDT gets to it and then the component will be painted. As long as the EDT is being blocked, the event will stay in the queue and the component will not be painted.
Carlos Heuberger
A: 

My answer was that when the GUI is constructed its not automatically painted at that time, instead a call to paint is placed in the EDT queue. If in the same method you construct a GUI object, and setVisible(true) then in the next few lines do something intensive, it blocks the future call to paint from occurring, because it will not get placed into the EDT queue until that method (with the intensive stuff) finishes. Also as was mentioned the frame or border is on the platform side of the equation (hence gets drawn), and the rest (Jlabel, container, background, etc) is on the java side and doesn't happen until paint is actually run (i.e. the EDT queue gets to it). My example code worked without the InvokeLater call, because that ran the intensive stuff in the init thread, and allowed the EDT thread to still paint.

Marc
Well, that is more or less the way I expained it for you.
camickr
A: 

Invisible components are not painted.

Rastislav Komara
A: 
Oyvind Kvalnes