Re: [Bug-XBoard] The clock stops if the board window is moved with stickyWindows on

[h.g. muller]

> If I move the board window during a game while the stickyWindows option is 
> actice, the clock for the player who has the move will most often - but 
> not always - stop.

Yes, I can reproduce that in Two-Machines mode.

> The same happens if the window is iconified and deiconified.
>
> I tried to find the reason but failed. But I made the following 2 
> observations:
>
> 1) The window actions will trigger the function DelayedDrag() if 
> stickyWindows is active, and DelayedDrag() uses XtAppAddTimeOut() like 
> also the clock does. Could it really be that no more than one timer can be 
> active?

I am pretty sure that is not the case. ScheduleDeayedEvent uses 
XtAppAddTimeOut, and some scheduled events (e.g. for the -keepAlive option) 
also run in parallel with the clock. And I remember that for some delays I 
could not use ScheduleDelayedEvent because it would erase another event. 
(ScheduleDelayedEvent can indeed only be used once.) These then started to 
work without problems when I made them call XtAppAddTimeOut directly. 
Finally, like you say, the clock does not always stop, while in a clocked 
game there should always be one clock-tick event pending.

So it seems we unreliably lose events or commands from/to the X-server. I 
guess this could in principle be caused by improper XSync or XSynchronize 
calls: it seems the second argument of those can cause clearing of the 
event queue?


> 2) The function ClockTimerRunning() is defined, but never called. I 
> suppose it should be deleted.

I guess we could. But it small, and you never know if it could be useful in 
the future. So why bother.