Hi Cosmin, thanks for your reply. Hm, interesting suggestion I didn't think of yet.
However, the problem is that the code to be executed might be quite heavy, with quite some calculations. Also, it might not be, it depends on several circumstances in the application. So the calculations take different times to execute, which makes that the "timer" in your suggested code becomes irregular, because the next fire depends on how long the code takes to execute. Probably the thread pool seems to be the best sollution in this case. Allthough I would rather have the firing interval automatically resetting itself, in case the calculations take so long that the next timer event is allready happening before the calculations finish. On 7 Sep 2005 at 10:41, Cosmin Prund wrote: > If the code you put into the thread is quick and you're certain it will > finish by the time the new timer message arrives it's easy. If the code is > not that quick and at times the timer message might arrive before the last > started thread completed you'll need to create a "thread pool" - and that > might be a bit more difficult. > > If the code for your thread is quick and simple I've got an other idea for > you. How about skiping the timer and going with Sleep within the thread? > > Ex: > <code> > procedure TMyTimer.Execute; > begin > while not Terminated do > begin > try > // your code goes here > Sleep(1000); // after your code completes > // the thread goes idle for 1 second > // then repeates your code (unless > // the thread has been terminated) > except do ; > end; > end; > end; > </code> > > On the other hand - if you DO use lots of such timers in lots of different > applications it might be easyer to simply create a new TThreadTimer that > takes care of every thing. If this is for one application only, creating or > using a new TThreadedTimer is overkill. > > rinke hoekstra wrote: > > By the way: > > > > I see that you put the creation of the Thread in the OnTimer Event; > > so an instance of the thread object is created (and a thread is > > started and killed) every time the timer fires. > > > > I was wondering how much resources this takes. Isn't it better to > > have a thread property in a subclass of a timer, which will be > > started as soon as the timer is enabled? In this case, there is 1 > > thread associated with the timer, and it will never be stopped and > > restarted, and everytime when OnTimer fires, it will be executed in > > this single timer thread. > > > > I was wondering which approach is better. Would there be any > > difference in resources it takes? > > > > Rinke > > > > > > > > On 6 Sep 2005 at 14:18, Cosmin Prund wrote: > > > >> How about a timer that creates a new thread object from it's OnTimer > >> event? > >> All you need to do is drop a standard timer on your form and create > >> your > >> thread object from it's OnTimer event, something like this: > >> > >> <code> > >> procedrue Form1.OnTimer(Sender:TObject); > >> var Thread:TMyThread; > >> begin > >> Thread := TMyThread.Create(True); > >> Thread.FreeOnTerminate := True; > >> Thread.Resume; > >> end; > >> </code> > >> > >> Writing the code for TMyThread is not that hard: > >> > >> <code> > >> type > >> TMyThread = class(TThread) > >> public > >> procedure Execute;override; > >> end; > >> > >> procedure TMyThread.Execute; > >> begin > >> // Your code goes here! > >> end; > >> </code> > >> > > > > _______________________________________________ > > Delphi mailing list -> [email protected] > > http://www.elists.org/mailman/listinfo/delphi > > _______________________________________________ > Delphi mailing list -> [email protected] > http://www.elists.org/mailman/listinfo/delphi _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
