views:

146

answers:

3

I have created a panel on which a set of objects is drawn. Each of the object is added as a mouse event listener to the panel. As I know, after an event occurs the listeners are notified and the code might be (or is?) executed in several threads. Is it possible to attach a custom code that will be executed after all listeners finish executing their code?

A: 

I believe that what you will want is to use the SwingUtilities.invokeLater() method which will invoke a Runnable instance on the Event Dispatch Thread after all other GUI events have been processed.

BryanD
+3  A: 

Is executed in the same thread ( the event dispatcher thread ) .

To do what you want you just have to add an extra listener and have that listener invoke "executeLater" method of SwingUtilities class.

What is does, is wait for the EDT thread finish the notifications and then invoke the your code.

To test it, add this listener and see what it does:

 class MouseListener extends MouseAdapter {
     public void mouseClicked(MouseEvent e)  {
           // System.out.println("If uncommented this would be invoked with the rest of the listners");
           SwingUtilities.invokeLater( new Runnable() {
                public void run() {
                    System.out.println("Invoked after all the listeners were notified");
                }
            }
     }
 }

Granted, it is a mouse listener what you've got. The concept is the same for all the other listeners.

OscarRyz
@czuk: A concern that this technique might trip on is if a particular listener implementation returns a notification early, and executes work "out-of-band" on a separate thread. In that case, the end of the notification call does not actually mark the end of the listener's execution.If this is an actual concern (i.e, you're aware of and concerned with other user-defined, elaborate listeners that do this sort of thing, you might want to refine and revisit the problem.
Noel Ang
@Noel: That's a good point. Although the fact that the listener uses a different thread for a long running task ( which is desirable ) means that it should mark him self as "ready for more" and thus the listener code would be actually ready. An alternative is to use share a flag and that flag is not set until all the code is ready... mmm let me see if I can code something to better explain this.
OscarRyz
@Noel: Do you mean a situation where the jvm starts executing the listeners code in different threads or when I decide to run some of my code in another thread? If you mean the second case, it is not the problem because I am not going to use other threads. If not, it is indeed a problem ;-)
czuk
@czuk: Is the later, when you actually perform the listener work in a new thread. For that situation, I added the "other" answer. If you are not in that situation, disregard that answer. :)
OscarRyz
+1  A: 

As for Noel comment:

A concern that this technique might trip on is if a particular listener implementation returns a notification early, and executes work "out-of-band" on a separate thread. In that case, the end of the notification call does not actually mark the end of the listener's execution. If this is an actual concern (i.e, you're aware of and concerned with other user-defined, elaborate listeners that do this sort of thing, you might want to refine and revisit the problem.

Using the SwingUtilities.invokeLater() you are sure the code is executed after all the listener were notified. But one of these listeners may perform it's job in a separated thread.

If you need to execute your code after all the listeners not only were notified but they finished their job you could do something like this:

pseudocode:

Listener implements MouseListener 
    +mouseClicked( event: MouseEvent ) 
        SwingUtilities.invokeLater( // returns immediately 
              someTask() 
        )

    -someTask()
        // perform some long task.

If you have your listeners as

 addListener( new Listener() )
 addListener( new Listener() )
 addListener( new Listener() )
 addListener( new ExecuteAtTheEnd() )

If all ( or some ) of your listeners perform their job in a different thread. Your ExecuteAtTheEnd may be executing it's code at the end of the notification, but not at the end of the execution of the listeners code.

So, what you do?

You have to synchronize the usage of some lock flag and execute your code until that flag is not used.

It may be a counter that is incremented when the listener is executing and decremented when is not:

 Listener implements MouseListener 
    +mouseClicked( event: MouseEvent )
        lockFlagCount++ 
        SwingUtilities.invokeLater( 
              someTask() 
        )

    -someTask()
        // perform some long task.
        lockFlag--

And then you just proceed until this flag is false:

  ExecuteAtTheEndListener implements MouseListener 

       + mouseClicked( event: MouseEvent ) 
        SwingUtilities.invokeLater( 
              executeAtTheEnd() 
        )
       - executeAtTheEnd() 
            while( logFlagCount > 0 ) 
                wait()

             if( logFlagCount == 0 ) 
                 // continue with the task.

Of course it is much more complicated as I put it in the pseudo-code, but it should work, if you are in this kind of circumstance.

OscarRyz
Thank you for your response! It must take you some time to write it ;-) However, can I be sure that the `ExecuteAtTheEnd()` will be start being executed before other listeners are? Is it possible, that it will be notified as the last one but executed before the counter is incremented by other listener?
czuk
Yes it is. You have to use a good lock mechanism for that. I know how to do it using `wait` and `notifyAll` mechanisms used on the threads, but it is a bit long to write down, that's why I used pseudo code. I think if you are in this situation, you can take a look at the java.util.concurrent API which I've heard it easier in this cases ( and you can always create a new question on SO to learn about it ) **BUT** Before that you have to be sure tha you need it. Judging by your original question, you don't need that and my original answer should be enough.
OscarRyz
I will use the combination of both solutions because on one hand the list of listeners may change in time and on the other some of the computation might be quite long.
czuk