Re: thread differences from button_Click and timer_Elapsed

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Hi Pete,

Thanks a lot for your help... it just solved my problem!!!

I was using system.timers.timer and just changing that to forms.timer solved
the problem.


Thanks a lot,
Regards
Victor


"Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx> wrote in message
news:op.tsq71ka28jd0ej@xxxxxxxxxxxxxxxxxxxxxxx
On Tue, 22 May 2007 17:20:19 -0700, Victor Reboucas <vcreb@xxxxxxxxxxx>
wrote:

[...]
The question is: what is different in calling a method in a button click
routine and in a timer elapsed event (in threads meaning), is that the
"user interaction" (button click) that creates a new thread
automatically or sth like that?

If anything, it would be the timer that uses a different thread (it
wouldn't create it, but rather get one from the thread pool). Whether it
does that depends on which timer class you're using. The Forms.Timer
signals the timer event on the same thread as the form, but the other
timers don't. Your button's click event will run on the form's thread,
which is the main UI thread (unless you've done something specific to
change that).

That should be enough information to tell you what's going on, but if you
really want to check to see whether the two techniques wind up running on
different threads, you can get the Thread.ManagedThreadId property and
compare them between the two executions (in the same process, of course).
If the number is different, then one of the methods is using a different
thread than the other.

It does sound as though you're not using the Forms.Timer class, and that
the timer-based method does execute on a different thread. I suspect that
the main thing is that COM hasn't been initialized (or hasn't been
initialized properly for your use of DirectShow) on the timer thread, but
I don't have much in the way of specifics as to how you'd do that. If
you're using a timer that's using a thread pool thread, then you never
know which thread is actually going to be used. You are probably better
off either dedicating a thread to your timing somehow, or using Invoke()
to put the processing back on the main thread.

Pete


.

Relevant Pages

  • Re: EndInvoke still required?
    ... and there will never be another receive callback to ... You could put a timer on the Form, or run a dedicated consumer thread. ... And creating a consumer thread for this one purpose seems wasteful as ... A single extra consumer thread isn't really that big of a deal, and it's not like queuing something on the thread pool is completely cost-free wouldn't otherwise have to worry about). ...
    (microsoft.public.dotnet.framework)
  • Re: Damn you, FEDEX! or Nikon D40 lost in Springfield, MO blackhole.
    ... the 2 mp Mavica he had been using with a Nikon D40. ... After shopping around, he got me to order one for him. ... The shipper had it insured, but from what I have read it could take weeks to sort this crap out. ... You may get your insurance from FedEx and a couple weeks later they find it and deliver it. ...
    (alt.photography)
  • Re: Timer-queue timer callback proc and re-entrancy
    ... If you have a UI thread, you can use WM_TIMER, or you can use the thread pool (timer queue) and a sync object. ... the callback function can be called by different threads even if another callback is in progress. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Lahman, how ya doing?
    ... >> I'd started with a Timer class that keeps the total time separately in ... double event job I wound up rewriting a few member functions in the ... derived class identically except for different pointer types. ...
    (comp.object)
  • Re: In this specific example a null delegate give not a nullReferenceException
    ... In the .NET Framework version 2.0 and earlier, ... I knew enough to look for the general thread pool behavior, but it didn't occur to me that the Timer class would then override the exception handling ) of the thread pool. ...
    (microsoft.public.dotnet.languages.csharp)