Hello,
Actually, I tried remove_timeout as a first solution, but it did not work.
However, after reading your response, I came to realize that one specificity of
my implementation is that the FLTK main loop is launched within a thread, which
is usually OK for most things, except as it appears for the timeout (and also
as I have recently discovered for "awake", which is no longer invoked if
Fl::run is not in the main thread, which is pretty logical, actually)...
So, I have recompiled my program in order to test how my system behaves if
Fl::run is launched in the main thread: in that case, add_timeout works fine.
In contrast, if I run Fl::run, within a thread, the timeout does not reset
anymore, except if I force s_TimerWnd to 0.
Again, I'm using your library in a way that it was not intended to (I mean
running the main loop in a thread), so I guess it is up to me to find a better
way to deal with this problem.
Thank you very much for your help...
>
> On 2 Jan 2013, at 11:12, claude roux wrote:
>
> > Hello,
> >=20
> > The way I use FLTK encompasses some level of re-entrance. However, I =
> discovered a little problem in the way add_timeout is used on Windows. =
> If I initialize a first timeout, it works like a charm... If I try to =
> relaunch a new timeout within the same application, then it does not =
> work anymore.
> >=20
> > I have investigated a little bit, and I have discovered that in order =
> to re-use a timer in the same application, I needed to reset the value =
> of s_TimerWnd to 0 in fl_win32.cxx.
> >=20
> > For the moment, I have implemented a small function, which does that =
> (the variable is static)
> >=20
> > void FlResetTimer() {
> > if (s_TimerWnd)
> > s_TimerWnd=3D0;
> > }
> >=20
> > I suppose there is a better way to have this variable reset in a =
> different place, but for the moment, it seems to suffice.
>
> Hm, I'm not keen on that approach - it looks to me as if it is =
> "cancelling" the timer, but not clearing out the action associated with =
> timer, which may be messy down the line.
>
> I think the preferred approach, if you may have reentrancy on your =
> timers, is just to call Fl::remove_timeout() first, before you re-add =
> it. Note that calling Fl::remove_timeout() on a "not-added" timer is =
> harmless.
>
> Though, to be honest, where I've hit this issue, I've just had a state =
> variable that I check before doing the add call; if it is clear I add =
> the timer and set the flag. If it is already set, I can decide whether =
> to remove it, or to allow the extant timer event to occur.
> The flag is of course cleared by the function that runs when the timer =
> fires. Since the code is pretty much single threaded, this is more or =
> less safe...!
>
>
>
>
>
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
