Community
Participate
Working Groups
Created attachment 121401 [details] modified Display.java, as recommended in report org.eclipse.swt.widgets.Display should allow flushing of the asynchronous message queue, since a developer may have the desire (or need) to explicitly process all pending asynchronous messages. Although the javadoc for the readAndDispatch() method suggests that the method will flush the queue, it actually only processes the first pending message. Its clear that although the functionality was intended, the class just doesn't match the javadoc. The javadoc should be modified to make sure that developers don't mistakenly think this is the case, and the This can be accomplished by either: 1. adding a new public method which simply calls Display.runAsyncMessages(true) 2. making Display.runAsyncMessages(.) public. 3. modifying readAndDispatch() so that it runs all asynchronous messages (ie, calls Display.runAsyncMessages(true)). I've attached a new copy of Display.java that implements option (2).
I had a similar need on some unit tests I was writing since we were scheduling some UIJobs and/or asynchronous messages. I ended up putting the test in a loop to constantly check if there were any pending UIJobs and/or calling readAndDispatch() constantly. It wasn't very elegant but oh well...
After some additional thought I realized that the display class I included could potentially hang the display in the quite common case that one would continue spawning asynchronous messages as part of a loop. The correct implementation should actually move the current contents of the message queue to a temporary queue, process the temporary queue, and then return true if new messages have been generated in the temporary queue as a result of processing the existing asynchronous messages.
can't you call readAndDispatch in a loop ? while (display.readAndDispatch()); ?
Unfortunately line 3417 if (OS.PeekMessage (msg, 0, 0, 0, OS.PM_REMOVE)) { can prevent you from ever processing the asynchronous messages. If you have, for instance, a slider widget and would like to execute asynchronous messages while the user is dragging the slider, the asynchronous messages will not be processed because the body of the if statement (above) always returns true while the slider is selected, preventing the call to runAsyncMessages() from ever executing.
Do you have code that shows the slider problem? By definition, asynchronous messages run when the user interface is idle.
Unfortunately I can't release the code that I've generated this issue in, however, I'll see if I can reproduce it when I have some spare time.
See also: Bug 104851: DCR - Display.postEvent(Runnable) Bug 103863: Support encapsulation in SWT layout mechanism (talks about "runWithEvent(Runnable)") Bug 256469: Popup Outline Ctrl+O has non-deterministic behavior (chars are lost) Perhaps Display could have some new method with this behavior?: public void readAndDispatchEverything() { while ([stuff to do]) { [run OS events] [run deferred OS events?] if (nothing has been done yet) [run first async-ed Runnable] } } It's funny that a single call to readAndDispatch() sometimes sends multiple events, due to deferredEvents. I guess the argument is why not keep going and do more? Anyway, when someone calls asyncExec(Runnable) from the Display's thread, then what they really want is a way to execute a Runnable after the event currently being dispatched has completed (and sometimes all other pending OS events). The thread is already awake, so posting a bogus OS.WM_NULL Message wouldn't be necessary, which might fix 256469. Instead, Display could just push the Runnable onto its "asyncQueue", and not worry about waking the already awake thread.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
