Problems with Event Dispatching - Thread

[SpOoViC]

Hi Guys,

I'm working on a project coded by another student, which he created due his bachelor examination.


I started working at a programming faculty in our university two months ago...
The current task is to make automatited measures of the used algorithms, so I am using the onClick-Method to trigger the needed buttons.

The problem here is that 2 Buttons need to be pressed.
After triggering the first button, the second gets triggered too - as expected, but the second button does not wait for the actions (refering to the first button) to be completed.

I googled and found out, that "SwingUitlities.invokeLater(myThread)" would solve this and implemented it.
But it doesn't .

Without the for-loop my code works, but it should also work with it(?).


Please help me, I'm so desperated :'(.

P.S.: Sorry for this dirty english


This is how I coded it ...

public class AutoValidListener implements ActionListener {
	private Board board;
	private ContentPanel contPan;
	private AnalysePanel anaPan;
	private BoardPanel boardPan;
	private AlgoThread algoExec;
	private RefreshThread algoRefr;
	private SaveThread saveThr;
	private NoAlgoThread noAlgoThr;
 
	public AutoValidListener(Board board, ContentPanel contPan) {
		this.board = board;
		this.contPan = contPan;
		anaPan = contPan.getAnaPan();
		boardPan = contPan.getBoardPan();
 
		algoExec = new AlgoThread( board, contPan );
		algoRefr = new RefreshThread( board, contPan );
		saveThr = new SaveThread( board, contPan );
		noAlgoThr = new NoAlgoThread( board, contPan );
	}
 
	public void actionPerformed( ActionEvent e ) {
		for(int i = 0; i < 30; i++) {
			SwingUtilities.invokeLater(algoRefr);
 
			for(int j = 0; j < 4; j++) {
				SwingUtilities.invokeLater(algoExec);
				SwingUtilities.invokeLater(saveThr);
				SwingUtilities.invokeLater(noAlgoThr);
			}
		}
 
	}
 
}

[Cornix]

Are you sure that runnables that are queued to be invoked later will actually be invoked in the same order as they have been put onto the queue? Because I cant find anything about that in the officialy documentation.
The invokeLater method does only guarantee that the runnables will be run after all pending events have finished, but it does not say anything about other runnables that are queued.

By the way, are you really sure that you want your "Threads" to run on the EDT instead of actually multi-threading your application? The class names would suggest that these are actually independent threads rather then simple runnables.

[GregBrannon]

After triggering the first button, the second gets triggered too - as expected, but the second button does not wait for the actions (refering to the first button) to be completed.

The code you've posted is not helpful at framing the problem or showing the undesired behavior. It would be simple enough to post a short, runnable example of code that demonstrates the undesired behavior of two related buttons with an explanation how they should function. Please try to put that together and make it as relevant as possible to the actual problem.

[SpOoViC]

Are you sure that runnables that are queued to be invoked later will actually be invoked in the same order as they have been put onto the queue? Because I cant find anything about that in the officialy documentation.
The invokeLater method does only guarantee that the runnables will be run after all pending events have finished, but it does not say anything about other runnables that are queued.

By the way, are you really sure that you want your "Threads" to run on the EDT instead of actually multi-threading your application? The class names would suggest that these are actually independent threads rather then simple runnables.

That could be the problem...


Multithreading the application is much work to do, because I didn't wrote the code ... I'm looking for a simple method to trigger buttons after another. But it seem to only work with threads...


unfortunately I am not able to post the whole code, because of it's copyrights

--- Update ---

The code you've posted is not helpful at framing the problem or showing the undesired behavior. It would be simple enough to post a short, runnable example of code that demonstrates the undesired behavior of two related buttons with an explanation how they should function. Please try to put that together and make it as relevant as possible to the actual problem.

The program wasn't coded by me ... I'm only extending it. So I can post more code.

I will add a picture later to describe my problem exactly

[GregBrannon]

The picture may help, but what you describe - Two button presses, the action of the second one waiting for the action of the first to complete - is certainly possible and not even that hard, but how to accomplish that objective with the code you've posted would be nearly impossible to determine. That's why I suggested breaking the problem down into a simpler context:

Write a simple app with 2 buttons, each with their own simple action. The architecture of the simple app should approximate the architecture of the code you posted in the relationships between the buttons and their actions, including any threading that is being done. Once we can see the relationships between the buttons, their activation and actions, threading used, and better understand why the second action should wait for the first to complete, we can suggest possible solutions. We can't suggest fixes to the code you've posted, because we can't understand from what you've shown or told us what is broken in that code, if anything.