Community
Participate
Working Groups
The UI thread should not idle between firing an asyncExec and it being executed. This is important e.g. to prevent the user from clicking around between an update to the model and the corresponding asyncExec'd update to the UI. See attached failing test.
Created attachment 45840 [details] Failing test
We can't change this behavior even if we wanted to. Application code relies on it.
There was a bug report that was very similar to this one. It eventually resolved to the general agreement that it would be nice to have the ability to let the programmer specify that a particular runnable should run as soon as possible, rather than when the UI is idle. This involved new API. I can't find the bug report but Randy Hudson was on it. Randy?
bug 104851 requests that a runnable get added somehow to the event queue, with equal priority to paint events, etc.. But, it would still only run after whatever events are already on the queue. So, if there is a pile of mouse events or key events already posted, you still have the possibility of the user doing something before your Runnable is run().
I found that one. It's not the same thing. There was one that you and Stefan Xenos were one. Stefan?
Perhaps it is the bug referenced in the bug I mentioned.
See bug 103863. In my case, I don't need to prevent the user from clicking around - I just want my code to run before the next repaint. Basically, if a model change affects more than one bit of UI, I want the next repaint to reflect the latest state of the model and I don't want to trigger more than one repaint no matter how much stuff has changed. I believe that my case is quite similar to Randy's. Note: I've tried to use a global paint filter for this purpose, but there appear to be some JFace (or perhaps SWT) classes that don't like being modified during paint events. Right now, I'm using a utility that maintains a list of Runnables, and executes them all during the same asyncExec. This is not a bad compromise, but it still doesn't guarantee that all my model changes will show up in the next repaint. It would be very nice if this could be addressed.
We tried to have repaints just paint the current state, and our "updates" occur normally when the async occurred. But, now we have a bug because stuff tries to paint before it's been "validated", and it is in an invalid state, and can't paint properly. So, we'll have to do a pre-check on paint, and then request another paint if we need a bigger damage region.
I no longer agree with comment 0, since the current asyncExec behaviour is important for deferring listeners. I think what I actually wanted was something similar to comment 7, which I have since implemented, but I don't remember exactly. The only remaining issue for me is that asyncExec is poorly documented. Is it deterministic or not? The current javadoc does not make a commitment either way.
What would you like the Javadoc to say? It runs at the "next reasonable opportunity".
WONTFIX
