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/42575
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

0 files changed, 0 insertions, 0 deletions