I’m terminating a small app for auditory testing and I’m having issue in delayed repainting of a component.
I know that in event-driven UI you can’t be sure that your repaint occurs a specific time. However I think there may be a way to solve my problem…
I created custom button class (derivated from button) which run in a different thread than the other components of my main windows because it make some computing…
At certain point, my Button/thread is doing nothing until the main windows (who have a keypress listener) triggers one of the button’s method (calles "receiveResponse becauseit collects answers from the user).
In receiveResponse, I change the String that will be drawn on the button,
then I call repaint() to have the change displayed and then I call a wait(2000) (or sleep(2000)) be launching OneTrial (another method).
in onetrial, I play 2 sounds (it plays nicely and nothing until a new call from the main windows to receive response…
to be clearer here is a piece of my receive response :
ok the problem is that, on some trial (quite irregular) the display of the word “WRONG” is delayed until the end of the sounds (played by onetrial), i.e about 3s after the call to repaint(); However it is sometime refreshed immediatly.
I have tried to insert some dispatchpendingMessage in several places but without great results…
Why is it so long to refresh the button since just before calling repaint, nothing is done by the app (just waiting for a key event or else) ?
One hypothesis is that for some reason, there’s a lot of messages in the queue to be processed before the repaint… strange but why not… is there a way to give some priority to mine ? of to clear the message queue ?
I think that the wait(2000) could be par of the problem since it blocks everything for 2s… What would be the best way to wait keeping the messages processed (a starttimer(2000) with a timer callback ? not elegant) a while with wait(100) in it an a test for a timecounter reached ?)…
Any ideas are welcome