The EventQueue javadoc states that it is required that enqueued events are dispatched sequentially and in order.
Is it correct that Runnables enqueued with EventQueue.invokeLater are guaranteed to be dispatched before subsequent user events (e.g. a MouseEvent)? In other words can an event handler be executed before the enqueued Runnable, if the user event happend after EventQueue.invokeLater.
Thanks!
Probably it's best to explain what you're trying to do. In general, the event dispatch system is designed such that you shouldn't know or worry about its internals. If you are writing an event handler that directly updates the UI then it may make sense to not use a Runnable and perform your updates inline. However if your event handler performs some calculations or processing that takes an indeterminate amount of time, then you would want to use a thread which would eventually perform the UI update with a Runnable with the Swing.invokeLater call. Needing to know the sequence of events as they are dispatched means you are attempting to build assumptions in your logic that probably belong elsewhere.
For eg, consider a mouse click event handler that performs heavy processing (network downloads or DBMS queries) in a thread and later updates a text label in the UI. You probably want to ensure the processing and UI update happens before the user clicks elsewhere on the UI to avoid ambiguity in which clicks are processed. In such a case you would likely disable the UI or certain clickable parts of the UI immediately in the initial mouse click event so that the UI stays responsive but protects your onMouse handler from re-entry until the original click event is fully processed. (forgive the following snippet as it has been years since I've done Swing, it's more like pseudo-code.)
void setUIEnabled(boolean enable) {
for(Button eachUIButton : getAllClickableButtons()) {
eachUIButton.setEnabled(enable);
}
}
void onMouseClick(MouseEvent event) {
setUIEnabled(false);
new Thread(
new Runnable() {
public void run() {
final String result = doLengthyProcessing();
enableRunnable = new Runnable() {
public void run() {
setUIEnabled(true);
updateTextLabelFromLengthyProcess(result);
}
};
Swing.invokeLater(enableRunnable);
}
}
).start();
}
The idea here is that you write you logic such that it doesn't depend on the random order that events are dispatched, rather it acknowledges that the processing will likely take longer than the next incoming mouse event and makes provisions for such timing. A subtle improvement would be to also draw a progress indicator or progress spinner to indicate work is being done to the user.
The API docs state that events are
In the same order as they are enqueued.
But if you check the source code, you'll see that that isn't always the case although it is largely correct for most purposes.
postEvent and later dequeued and sent to dispatchEvent one at a time in the EDT. –
Photodisintegration Probably it's best to explain what you're trying to do. In general, the event dispatch system is designed such that you shouldn't know or worry about its internals. If you are writing an event handler that directly updates the UI then it may make sense to not use a Runnable and perform your updates inline. However if your event handler performs some calculations or processing that takes an indeterminate amount of time, then you would want to use a thread which would eventually perform the UI update with a Runnable with the Swing.invokeLater call. Needing to know the sequence of events as they are dispatched means you are attempting to build assumptions in your logic that probably belong elsewhere.
For eg, consider a mouse click event handler that performs heavy processing (network downloads or DBMS queries) in a thread and later updates a text label in the UI. You probably want to ensure the processing and UI update happens before the user clicks elsewhere on the UI to avoid ambiguity in which clicks are processed. In such a case you would likely disable the UI or certain clickable parts of the UI immediately in the initial mouse click event so that the UI stays responsive but protects your onMouse handler from re-entry until the original click event is fully processed. (forgive the following snippet as it has been years since I've done Swing, it's more like pseudo-code.)
void setUIEnabled(boolean enable) {
for(Button eachUIButton : getAllClickableButtons()) {
eachUIButton.setEnabled(enable);
}
}
void onMouseClick(MouseEvent event) {
setUIEnabled(false);
new Thread(
new Runnable() {
public void run() {
final String result = doLengthyProcessing();
enableRunnable = new Runnable() {
public void run() {
setUIEnabled(true);
updateTextLabelFromLengthyProcess(result);
}
};
Swing.invokeLater(enableRunnable);
}
}
).start();
}
The idea here is that you write you logic such that it doesn't depend on the random order that events are dispatched, rather it acknowledges that the processing will likely take longer than the next incoming mouse event and makes provisions for such timing. A subtle improvement would be to also draw a progress indicator or progress spinner to indicate work is being done to the user.
© 2022 - 2024 — McMap. All rights reserved.