Hello,
Actually, the timeout works fine on Linux and on Mac OS, it is only with
Windows that I have problems.
But as I said in a previous message, the problem seems to occur only if the
main FLTK loop is run from within a thread.
From, what I could see inyour code, the timers seem to be properly cleaned when
the main window is killed, in delete_timer. I followed in a Visual debugger how
the timer is gotten rid of and everything seems Ok.
The way the timer is implemented is through the creation of a window
(CreateWindowEx). When the main loop is stopped, remove_timeout is then called
to clean everything. However, the "timer window" is not deleted, but kept for
further utilization.
However, since I launch the main loop within a thread, I guess the removal of
this "timer object", which also occurs within the thread, is done so thoroughly
that its handle (which is stored in s_TimerWnd) can no longer be used, hence
the necessity to recreate a "timer window" again.
> On 02.01.2013 12:12, claude roux wrote:
>
> [please see also Ian's post about Fl::repeat_timeout() and others]
>
> > 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.
> >
> > 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.
> >
> > For the moment, I have implemented a small function, which does that (the
> > variable is static)
> >
> > void FlResetTimer() {
> > if (s_TimerWnd)
> > s_TimerWnd=0;
> > }
> >
> > I suppose there is a better way to have this variable reset in a different
> > place, but for the moment, it seems to suffice.
>
> Setting s_TimerWnd to 0 means asking for Windows resource leaks,
> since the next add_timeout() call would create a new (hidden)
> window w/o destroying the former. Bad idea...
>
> What kind of reentrance do you mean? Are there different timers
> overlapping each other, or is this one time that needs to be
> adjusted somehow? With "different" I mean logically different
> cases - if it is so, then the callback argument to add_timeout
> *should* be different, since this is the timer's *id* in the
> timer queue.
>
> If you have logically the *same* timer function occurring
> overlapped in a reentrant way (i.e. with the same callback
> argument), then it will probably get more complicated. If
> you want all timers to trigger independently, then I assume
> that you'd have to manage timer events by yourself somehow.
>
> That said, if you still believe that the Windows timeout
> mechanism has a bug (after considering your use case and
> maybe using remove_timeout, repeat_timeout etc.), then please
> try to post a simple(?), self-contained demo source file so
> that we can try it and test.
>
> Important question: you wrote "in the way add_timeout is used
> on Windows". Does this mean that it works for you on other
> platforms as expected, or did you only test on Windows?
>
> BTW: Once I tested Fl::repeat_timeout() and it seemed that
> the Windows version doesn't work as specified (and as the
> linux version DOES), because timers aren't scheduled correctly
> in the intervals given (elapsed time differences are not
> calculated correctly, or something like this). So, there
> *may* be issues with the Windows timer code...
>
> Albrecht
>
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
