System.Timers.Timer

[Lou]

Do these run on a separate thread?

I created a COM .NET class and use the timer in this class to call a private
function of the class.
If I use this COM dll in a VB6 app, does the function called from the timers
"Elapsed" callback
run on a different thread than the VB6 app that instantiates the COM dll?

Or should I use the "Thread" class to create a new thread in the .NET dll?

-lou

[ceshaver61@aol.com]

Re: System.Timers.T imer

On Oct 3, 5:35 pm, "Lou" <lou.gar...@com cast.netwrote:

Do these run on a separate thread?
>
I created a COM .NET class and use the timer in this class to call a private
function of the class.
If I use this COM dll in a VB6 app, does the function called from the timers
"Elapsed" callback
run on a different thread than the VB6 app that instantiates the COM dll?
>
Or should I use the "Thread" class to create a new thread in the .NET dll?
>
-lou

Within VB.Net, the system timer definitely creates a new thread to
handle the elapsed event and any code called by the event handler will
run on that new thread. You can watch the new thread be created and
then destroyed in the VB.Net environment. Running the event handler
code on a different thread can have numerous unintended consequences.

I was using the vb5 serial comm control in vb.net and using the system
timer to periodically do some communications. The comm control would
work for a while and then die. Pulled my hair out trying to figure
out where my error was. Turns out that there was a bug somewhere in
the version of VB.Net that I had that caused this. Bill had a patch
but I was out of support so he wanted to charge a lot for
reinstatement of support. Ultimately, I figured out that this only
happened when the comm control class instance was accessed from a new
thread. I made some test code to verify that the forms timer does not
spawn a new thread, got rid of the system timer and everything worked
fine after that.