Timer Dispose?

[Zenerdiode]

Although .Dispose is not documented for timers, it seems to work. (Not in the IDE, but I don't mind that.)

Can this be relied upon? I have a program which in theory may run for several months and I dynamically create timers. If I call Dispose; I'd like the GC to eventually collect the resources.

 

[agraham]

I wouldn't, it looks OK in the compiled code but I'm not sure about it. Dispose and AddObject do work for library objects but I'd steer clear doing it with intrinsic controls because they are handled differently.

Can you use a Timer pool and reuse old timers, only creating a new one when required when all in the pool are in use?

 

[Zenerdiode]

There's probably a couple of problems to sort here then. The timers are dynamically created along with library objects. The timers and objects are 'grouped' by using the time in ticks (from Now) as a suffix. The timers are then wired to the same sub and the Sender keyword used to ascertain which timer fired the event sub.

This is because I was looking for a solution to fire an event when something expected hasn't happened within a certain time. For example a form needs to lock if there has not been any activity after a certain time. I'd use a Keypress and MouseDown sub to stop then immediately start a timer. This way the timer's interval is refreshed and when the timer eventually ticks the code will be executed.

So when I dynamically create the Library objects, I want to dynamically create an associated timer that is wired to a common timer sub. If an action doesn't happen within an envelope, the timer will fire and use the Sender to ascertain which timer fired; disposing of associated objects and the timer itself, so resources are released.

 

[agraham]

I don't know how many library objects you would have active at one time as this will determine the maximum size a timer pool would grow to.

As all the timers are wired to a common sub it seems to me that you only have to know which object a timer is presently allocated to which you could do by maintaining a Hashtable with the timer names as keys and the present objects as values. You then just have to track the timers that exist by adding them to an Arraylist or Hashtable when you need one and keeping track of whether it is allocated or free by another Arraylist or Hashtable.

Or you could just hope that Disposing Timers behaves properly in a compiled application. I've looked at the generated C# code again and it does seem that the added Timers are probably properly disposed but for something that may sit there for months I am not going to say that for sure. It's your call whether a definite maybe is adequate for the intended application or whether you want to code it rock solidly. If it was me, for what I guess is an industrial application and depending upon the impact of it failing after a couple of months at whatever cost in time/money, I would look at coding it statically if at all possible reusing both timers and library objects.

 

[RandomCoder]

My approach to a problem like this would be to have just one timer that fired at whatever interval you felt nessecary and use global variables to keep track of when events needed to occur, such as a form being locked.
You already mention the use of an ArrayList so why not just use this to store the variables?

Regards,
RandomCoder