tdf#111994 WIN workaround PostMessage delays
Fixes the "Multiple timers in queue" assertion by effectively removing it. When debugging it became obvious, that PostMessage returns, even if the message was not yet added to the message queue. The assert happens, because we start the timer in the Scheduler before Invoke(), so it fires, if we block in Invoke(), and then reset the timer after Invoke, if there were changes to the Task list. In this case it fires during Invoke(), the message is added. We restart the timer, first by stopping it (we wait in DeleteTimerQueueTimer, to be sure the timer function has either finished or was not run). And the try to remove the message with PeekMessageW, which doesn't remove the posted message. Then the timer is restarted, and when the event is processed, we end up with an additional timer event, which was asserted. As a fix this adds a (microsecond) timestamp to the timer message, which is validated in the WinProc function. So if we stop the timer too fast, the event is ignored based on the timestamp. And while at it, the patch moves timer related variables from SalData into WinSalTimer. Change-Id: Ib840a421e8bd040d40f39473e1d44491e5b332bd Reviewed-on: https://gerrit.libreoffice.org/42575Tested-by:Jenkins <ci@libreoffice.org> Reviewed-by:
Jan-Marek Glogowski <glogow@fbihome.de>
Showing
Please
register
or
sign in
to comment