How to gather frequent update/redraw/layout/refresh operations in SWT/Swing? - java

I am doing some frequent operations, which require GUI refresh (adding some children to a control).
I can't control the moment when the entire bunch of additions finished, so I can't do update/redraw/layout/refresh at the end and need do it each step.
Simultaneously I need nod do it very frequent, because user need not see each change.
Also each update/redraw/layout/refresh slows the process.
So, I need to decide whether to update/redraw/layout/refresh by time.
I wrote the following general class for SWT, but similar also applicable to Swing.
Is it's logic complete and correct? Especially, will the check delayedMap.get(doRun) == timer work correctly in multithreading? It's purpose is to cancel delayed operation in the case if entering the invokeOnceDelayed() method is occured between enterings into TimerTask.run() and inner synchronized block?
public class SWTUtilities {
private static HashMap<Runnable, Timer> delayedMap = new HashMap<Runnable, Timer>();
public static void invokeLater(Runnable doRun) {
Display.getDefault().asyncExec(doRun);
}
public static void invokeAndWait(Runnable doRun) {
Display.getDefault().syncExec(doRun);
}
public static synchronized void invokeOnceDelayed(final Runnable doRun, long delay) {
final Timer timer = new Timer(true);
Timer oldTimer = delayedMap.put(doRun, timer);
if( oldTimer != null ) {
oldTimer.cancel();
}
timer.schedule(new TimerTask() {
#Override
public void run() {
synchronized(SWTUtilities.class) {
if( delayedMap.get(doRun) == timer ) {
invokeLater(doRun);
}
}
}}, delay);
}
}

You can probably just delegate to Display.timerExec for the implementation of invokeOnceDelayed() method.

Related

Run on EDT after delay

I want to close a dialog after a specified timeout. So far I have the following method:
public static void addTimeout(final Component c, long timeout) {
Timer t = new Timer(c.getName() + "-TimeoutTimer");
t.schedule(new TimerTask() {
#Override
public void run() {
if (c.isVisible()) {
SwingUtilities.invokeLater(new Runnable() {
#Override
public void run() {
c.setVisible(false);
}
});
}
}
}, timeout);
}
However, I would like to know if there is a more compact way to write it. For example, avoiding to set a timer and just calling a method to run code on EDT with a specified delay. Is that possible?
Not really. If you switch to using the (more modern) java.util.concurrent way of doing things, you can use two lambdas and do it like this:
public static void addTimeout(final Component c, long timeout) {
Executors.newSingleThreadScheduledExecutor().schedule(() -> {
if (c.isVisible()) {
SwingUtilities.invokeLater(() -> {
c.setVisible(false);
});
}
return null;
}, timeout, TimeUnit.MILLISECONDS);
}
...which is more compact. But aside from switching to a scheduled thread executor, it's really just syntactic sugar on what you have above.
(Side note: If actually using the above code, it'd probably be better to store the result of Executors.newSingleThreadScheduledExecutor() for future invocations.)

Reseting a timer if particular condition is met?

I have an event listener which detects when the mouse is being moved in a certain pane of my program. From this, I want to be able to perform some action if the mouse stays idle for too long.
I have looked all over earlier today, to try and find an explanation and example which details how to start, stop/cancel and reset a timer but have been bombarded with different ways to try and do this, which has left me quite confused.
I'm following a timer example from here and implementing for my own situation
When this code below is run, it will output "A" every time the mouse stops. This is incorrect, as if I stop the mouse, move it quickly then stop it again, 2 sets of "A" are produced.
This carries on for however many times the stop is produced.
I believe I am missing a 'reset timer' function that will called when the mouse changes to a moving state.
How can I implement this?/Is that even the problem?
public class SomeClass{
//...some fancy code...
if (! isNowMoving) {
System.out.println("Mouse stopped!");
//Start Timer
new PrintingA(5);
} else if (isNowMoving){
System.out.println("MouseMoving");
//cancel timer & reset ready to start
}
public class PrintingA {
Timer timer;
public PrintingA(int seconds) {
timer = new Timer();
timer.schedule(new PrintingTask(), seconds * 1000);
}
class PrintingTask extends TimerTask{
#Override
public void run() {
System.out.println("A");
timer.cancel();
}
}
}
}
I'm not sure this can be useful for your requirement, Timer is a facility for threads to schedule tasks for future execution in a background thread. Tasks may be scheduled for one-time execution, or for repeated execution at regular intervals. Read java document : java.util.Timer
I perfer to have a thread for IdleMonitor and use Apache Stopwatch to monitor idle time.
import org.apache.commons.lang3.time.StopWatch;
public class IdleMonitor implements Runnable {
StopWatch stopWatch;
private final Object monitorObj = new Object();
private boolean isActive;
private long waitTime = 6000; //in milliseconds, put appropriate time to wait
public IdleMonitor() {
isActive = true;
stopWatch = new StopWatch();
}
public void reset() { // call this during MouseMoving event
synchronized (monitorObj) {
stopWatch.reset();
monitorObj.notify();
}
}
public void finish() { // finish idle mointor operation once your operation ends, this will stop the thread
isActive = false;
reset();
}
public void start() { // start monitoring
Thread t = new Thread(IdleMonitor.this);
t.start();
}
#Override
public void run() {
synchronized (monitorObj) {
stopWatch.start();
while (isActive) {
try {
monitorObj.wait(waitTime);
} catch (InterruptedException ex) {
}
long idleTime = stopWatch.getTime();
System.out.println("Idle time " + idleTime);
// do something if idle time beyond your expected idle time.
// you could set isActive=false; if you want to stop monitoring
}
}
}
}
}

One thread timing is faster than other

I have a thread which repeats an action each second (shooting):
long lasttime;
Creature owner;
public Attacker(Creature actor)
{
super("Attacker - "+actor.getClass().getSimpleName());
lasttime=System.currentTimeMillis();
owner=actor;
owner.lockedon=true;
}
#Override
public void run() {
super.run();
while(!owner.dead && owner.lockedon)
{
List pl=TVS.getGameScreen().projectiles;
synchronized (pl)
{
//here
long curtime=System.currentTimeMillis();
if(curtime-lasttime>1000)
{
owner.attack();
lasttime=curtime;
}
}
}
}
But when the main program thread slows down, this thread executes faster than main and shooting becomes too frequent relatively to the main thread. What should I do?
You are busy waiting, holding a lock which is likely to either consume a lot of CPU, or lock out other threads trying to use the same lock. I suggest something like
while(!owner.dead && owner.lockedon) {
List pl=TVS.getGameScreen().projectiles;
long curtime=System.currentTimeMillis();
long remaining = 1000 - (curtime-lasttime);
if(remaining <= 0) {
synchronized (pl) { // only lock when needed.
owner.attack();
lasttime=curtime;
}
} else {
// when not doing something useful, give up the CPU to another thread.
Thread.sleep(remaining);
}
}
I'd rather use Timers as they're easier to maintain and tends to be more accurate:
Timer shooterTimer = new Timer();
shooterTimer.scheduleAtFixedRate(
new TimerTask() {
#Override
public void run() {
if (!owner.dead && owner.lockedon) {
List pl = TVS.getGameScreen().projectiles;
synchronized (pl) {
onwer.attack();
}
}
}
},
0, // Start the timer now
1000); // Execute the task every second

Waiting for all Runnables submitted to SWT UI thread with Display::asyncExec() to finish

Is there a way to wait for all Runnables submitted to the SWT UI Thread via asyncExec(...) to finish?
Background:
I have a long-running operation, which among other things is triggering events that in turn submit Runnables to the SWT UI thread via the asyncExec(...) instance method of Display.
The progress of the long-running operation is shown in a ProgressMonitorDialog, and I would like to close the dialog only after the UI thread has finished executing the Runnables.
Changing the calls from asyncExec(...) to syncExec(...) is not an option, as the latter is not desired when the events are triggered from other contexts.
org.eclipse.swt.widgets.Display.readAndDispatch() will process an event from the event queue and return false if there are no more events to process. But you probably don't want to use this as it processes an event.
asyncExec(*) is a FIFO queue (although OS graphics events supersede the asyncExecs), so you could do most of your long-running op processing and then place a final asyncExec in the queue:
final boolean[] done = new boolean[1];
Runnable r = new Runnable() {
public void run() {
done[0] = true;
}
};
// now wait for the event somehow. The brute force method:
while (!done[0]) {
Thread.sleep(200);
}
In theory, all of the other asyncExecs spawned from your long running op will be finished by the time you get to the last one.
EDIT: potential other option
Create your own org.eclipse.core.runtime.jobs.Job and then join() it at the end:
public static class RefCountJob extends Job {
public RefCountJob() {
super("REF_COUNT");
}
int count = 0;
public void increment() {
count++;
}
public void decrement() {
count--;
}
#Override
protected IStatus run(IProgressMonitor monitor) {
monitor.beginTask("WAITING", IProgressMonitor.UNKNOWN);
while (count > 0) {
Thread.sleep(200);
monitor.worked(1);
}
monitor.done();
return Status.OK_STATUS;
}
}
To use it, increment() it every time you are going to fire off events, and have them decrement it when they're done (You have to make sure they decrement it no matter what exception is thrown :-)
RefCountJob ref = new RefCountJob();
// ... do stuff, everybody increments and decrements ref
ref.increment();
// ... do more stuff
ref.increment();
// at the end of your long-running job
ref.schedule();
ref.join();
Thanks, I ended up with the following. I think it is a pretty clean solution. By the way I would upvote your answer if I had enough reputation for that :)
public class SWTThreadingUtils
{
public static void waitForAsyncExecsToFinish(Display display)
{
Object waitObj = new Object();
display.asyncExec(new DummyRunnable(waitObj));
synchronized (waitObj)
{
try {
waitObj.wait();
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
}
}
private static class DummyRunnable implements Runnable
{
private Object waitObj;
public DummyRunnable(Object waitObj)
{
this.waitObj = waitObj;
}
#Override
public void run()
{
synchronized (waitObj)
{
waitObj.notify();
}
}
}
}

SwingUtilites: how to return values from another thread in Java?

I am trying to make an application in Java.
To make Swing work correctly, I did this:
public static void main(String[] array){
String outerInput;
SwingUtilities.invokeLater(new Runnable(){
#Override
public void run() {
// I want this string input.
String input = JOptionPane.showInputDialog(
null,"Stop ?", JOptionPane.QUESTION_MESSAGE);
});
// How can I get this input value in String outerInput?
}
How would I get this input string in my main body?
You can use AtomicReference<String> for passing values between threads in a thread-safe manner.
As noted by Hemal, you'll need some synchronization between two threads to make sure it was already executed. For example, you can use CountDownLatch or use SwingUtilities.invokeAndWait (make sure you don't call it from Swing thread!)
Update: here is the complete example using AtomicReference and CountDownLatch
public class Main {
public static void main(String[] args) throws InterruptedException {
final AtomicReference<String> result = new AtomicReference<String>();
final CountDownLatch latch = new CountDownLatch(1);
SwingUtilities.invokeLater(new Runnable() {
public void run() {
String input = JOptionPane.showInputDialog(null, "Stop?", "Stop?", JOptionPane.QUESTION_MESSAGE);
result.set(input);
// Signal main thread that we're done and result is set.
// Note that this doesn't block. We never call blocking methods
// from Swing Thread!
latch.countDown();
}
});
// Here we need to wait until result is set. For demonstration purposes,
// we use latch in this code. Using SwingUtilities.invokeAndWait() would
// be slightly better in this case.
latch.await();
System.out.println(result.get());
}
}
Also read this answer about general design of GUI (and Swing) applications.
How would I get this input string in my main body?
You wouldn't. The idea that your "main" would invoke a Swing dialog box and then do something with the results is contrary to the entire idea of a graphical user interface.
In a GUI, you design your program to deal with a series of user-initiated events. Those events may be completely asynchronous, such as the keystrokes, selection, and menu choices of your typical word processor. Or they may be scripted, such as the question-answer format of a "wizard."
Assuming that you want to do something like the latter, you would implement it using the following sequence:
The user initiates some action, perhaps selecting a menu choice. This is turned into an invocation of an ActionListener, which decides that it needs more input from the user.
The ActionListener, which is executed on the event dispatch thread, is permitted to do anything that it wants to the UI, such as displaying a dialog. That dialog may be modal or non-modal; in one case the output is available to the original listener, in the other you need to write a new listener to take subsequent action.
Once you have enough information, you may choose to invoke a background operation. You would typically have a thread-pool to service these requests. You would not attempt to perform the request on the "main" thread; in fact, for all intents the main thread is no longer running.
When your operation completes running, it would push data back to the event dispatch thread using SwingUtilities.invokeLater(). While you could use invokeAndWait() to send results to Swing in the middle of your background operation, that's rarely a good idea. Instead, create a sequence of operations, preferably one that is easily canceled by the user.
The "standard" way to initiate operations on a background thread is via SwingWorker. There are alternatives; for example, you could use a BlockingQueue to send operations to a single long-running background thread, and use invokeLater() to return the results.
Regardless, there's one rule that you do not want to break: never, ever, perform a blocking operation on the event dispatch thread. If you do that, then your application is broken.
Right now you have two threads going: the main thread and the EDT (event dispatch thread). I assume you know that SwingUtilities.invokeLater(runnable) is running a task on the EDT.
To share data between threads, you just need some variable that is in the scope of both threads. The easiest way to accomplish that is to declare a volatile data member or AtomicReference in the class containing the main method.
In order to ensure that you read the value after it is returned by the JOptionPane, the simplest thing you can do here is to change the invokeLater call to an invokeAndWait call. This will cause your main thread to stop executing until what you have put onto the EDT has completed.
Ex:
public class MyClass {
private static volatile String mySharedData;
public static void main(String[] args) throws InterruptedException {
SwingUtilities.invokeAndWait(new Runnable() {
public void run() {
mySharedData = JOptionPane.showInputDialog(null, "Stop ?", JOptionPane.QUESTION_MESSAGE);
}
});
// main thread is blocked, waiting for the runnable to complete.
System.out.println(mySharedData);
}
}
If your main thread is executing some task that shouldn't be stopped while the option pane is present, then in the main thread you can periodically check (i.e., in the outer part of the loop that is running your task) whether or not mySharedData has been set. If your task doesn't loop and is instead doing some I/O or waiting, you can make use of Thread.interrupt and check mySharedData in the InterruptedExecption handlers.
I suggest using the observer/observable pattern for this, perhaps with a PropertyChangeListener. Then your Swing app will be able to notify any and all listeners if the critical variable(s) state changes.
For example:
import java.awt.*;
import java.beans.*;
import javax.swing.*;
import javax.swing.event.*;
public class ListenToSwing {
public static final String STATE = "state";
private static final int STATE_MAX = 10;
private static final int STATE_MIN = -10;
private JPanel mainPanel = new JPanel();
private int state = 0;
private JSlider slider = new JSlider(STATE_MIN, STATE_MAX, 0);
public ListenToSwing() {
mainPanel.add(slider);
slider.setPaintLabels(true);
slider.setPaintTicks(true);
slider.setMajorTickSpacing(5);
slider.setMinorTickSpacing(1);
slider.addChangeListener(new ChangeListener() {
#Override
public void stateChanged(ChangeEvent e) {
setState(slider.getValue());
}
});
}
public void addPropertyChangeListener(PropertyChangeListener listener) {
mainPanel.addPropertyChangeListener(listener);
}
public Component getMainPanel() {
return mainPanel;
}
public void setState(int state) {
if (state > STATE_MAX || state < STATE_MIN) {
throw new IllegalArgumentException("state: " + state);
}
int oldState = this.state;
this.state = state;
mainPanel.firePropertyChange(STATE, oldState, this.state);
}
public int getState() {
return state;
}
public static void main(String[] args) {
final ListenToSwing listenToSwing = new ListenToSwing();
SwingUtilities.invokeLater(new Runnable() {
public void run() {
JFrame frame = new JFrame("ListenToSwing");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.getContentPane().add(listenToSwing.getMainPanel());
frame.pack();
frame.setLocationRelativeTo(null);
frame.setVisible(true);
}
});
listenToSwing.addPropertyChangeListener(new PropertyChangeListener() {
#Override
public void propertyChange(PropertyChangeEvent evt) {
if (evt.getPropertyName().equals(ListenToSwing.STATE)) {
System.out.println("New state: " + listenToSwing.getState());
}
}
});
}
}
You can use an AtomicReference and invokeAndWait.
public static void main(String[] array){
AtomicReference<String> outerInput = new AtomicReference<String>();
SwingUtilities.invokeAndWait(new Runnable(){
#Override
public void run() {
String input = JOptionPane.showInputDialog(
null,"Stop ?", JOptionPane.QUESTION_MESSAGE);
outerInput.set(input);
});
outerInput.get(); //Here input is returned.
}
You can trivially expose it to the outer class by declaring a String[] in which the runnable sets the value. But note that you will need some synchronization mechanism to know whether it has been assigned by the Runnable.
The following code will do what you want. I have done something similar except I was launching a JFileChooser instead of an input dialog. I found it more convenient than hard coding a bunch of paths into my application or accepting a command line argument, at least for testing purposes. I would like to add that one could modify the prompt() method to return the FutureTask instance for added flexibility.
public class Question {
public static void main(String[] args) {
Question question = new Question();
String message = "Stop?";
System.out.println(message);
// blocks until input dialog returns
String answer = question.ask(message);
System.out.println(answer);
}
public Question() {
}
public String ask(String message) {
try {
return new Prompt(message).prompt();
} catch (InterruptedException e) {
e.printStackTrace();
} catch (ExecutionException e) {
e.printStackTrace();
}
return null;
}
private class Prompt implements Callable<String> {
private final String message;
public Prompt(String message) {
this.message = message;
}
/**
* This will be called from the Event Dispatch Thread a.k.a. the Swing
* Thread.
*/
#Override
public String call() throws Exception {
return JOptionPane.showInputDialog(message);
}
public String prompt() throws InterruptedException, ExecutionException {
FutureTask<String> task = new FutureTask<>(this);
SwingUtilities.invokeLater(task);
return task.get();
}
}
}

Categories