By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,376 Members | 1,599 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,376 IT Pros & Developers. It's quick & easy.

timer not being enabled by thread

P: n/a
Unaccountably, I cannot re-enable a timer from an background thread. The
disable works fine, I just cannot get it to start back up. There is no
method "InvokeRequired" like there is for windows.forms.controls and I get
no error message about cross thread so I am not sure where the problem is.

I have a "SerialPoll_timer" that every second requests status from a device
on an RS232 port. I use this to determine if the device is on line. There
is a mutex "BusyWriting" associated with the serial port handler to allow
this timer task and other threads to all send info out the same serial port.
This all works fine.

Occassionally, I need to send a long series of initialization commands to
the device. These commands are sent from a background worker thread. Since
there is a long list of commands I thought I would have the background work
disable the serial poll timer, send out all the commands, then re-enable the
serial poll timer.

If I click on a button which does the initialization (ie: the bw thread is
not used) the timer thread gets disabled and re-enabled just fine. When I
started using the background worker to send the initialization commands the
timer never starts back up. This is all I do to the timer. I threw in the
"start" but that didnt help. I can even step thru this code in the debugger
and the timer will not start up. I have to quit the program to get it to
work again.

public void RemoteTimerEnable(bool bEnable)
{
SerialPoll_timer.Enabled = bEnable;
if (bEnable) SerialPoll_timer.Start();
}

So, if I call the above routine from a "button" it works but from a
background task things seem to go wrong. Maybe there is some other
problem? If the timer thread is in the mutex BusyWriteing.WaitOne() when
the disable occures, can this be why it cannot be re-enabled?
--
================================================== ====================
Joseph "Beemer Biker" Stateson
http://ResearchRiders.org Ask about my 99'R1100RT
================================================== ====================
Jun 20 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
On Wed, 20 Jun 2007 08:31:54 -0700, Beemer Biker <js*******@swri.edu>
wrote:
Unaccountably, I cannot re-enable a timer from an background thread.
The disable works fine, I just cannot get it to start back up. There is
no method "InvokeRequired" like there is for windows.forms.controls and
I get no error message about cross thread so I am not sure where the
problem is.
Just because there's no Invoke() on the timer itself, that doesn't mean
that you can't use Invoke(). Just use it on the form to which the timer
belongs instead.

Pete
Jun 20 '07 #2

P: n/a
"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...
On Wed, 20 Jun 2007 08:31:54 -0700, Beemer Biker <js*******@swri.edu>
wrote:
>Unaccountably, I cannot re-enable a timer from an background thread.
The disable works fine, I just cannot get it to start back up. There is
no method "InvokeRequired" like there is for windows.forms.controls and
I get no error message about cross thread so I am not sure where the
problem is.

Just because there's no Invoke() on the timer itself, that doesn't mean
that you can't use Invoke(). Just use it on the form to which the timer
belongs instead.
Thanks, I was unaware those tools existed nor have I used them. OK, i
looked at

this.Invoke(Delegate method, params object[] args)
and
this.InvokeOnClick(Control toIinvoke, EventArgs e)

I have not coded anything up yet, just looked at them and have this
observation ...

If (as I mentioned on original post) I have a button object that can
correctly start and stop the timer, then I assume I can put that control
into the InvokeOnClick and quote "Raise the
System.Windows.Forms.Control.Click event for the specified control" If so,
I assume the controls "underlying thread" handles this as intellisense seems
to indicate.. If so, then I am certain the following problem will show up:
I have found that when I "click" on a button, and the code it calls includes
a "Thread.Sleep(1000);" [for example], the form is incapable of fireing any
callbacks during that one second wait or any other. Any timers, serial data
received, etc are never fired until the thread (from the button click) does
a final return. On the other hand, if the Thread.Sleep(1000); is executed
by a background worker process then all the other events seem to work just
fine on the form while that BW thread is sleeping.

The long initialization procedure I need to send to the serial device
includes a bunch of Thread.Sleep(mseconds) because some of the commands to
the device require a delay to allow hardware to perform a task.

So, I suspect I cannot use the InvokeOnClick

However, you mentioned Invoke as used on the form. So maybe I can have a
delegate routine handle turning on and off the enable boolean on the timer?
I am not sure how to set that up. I will look at it and see what it does
(ie: poke around). Can you point me to any example code where someone used
"this.invoke(..)" with a delegate? One would think a cross thread error
message would show up if an invoke was required but I have not seen one. All
I have seen is the timer does stop but never gets re-enabled.

...thanks..
--
================================================== ====================
Joseph "Beemer Biker" Stateson
http://ResearchRiders.org Ask about my 99'R1100RT
================================================== ====================

Jun 20 '07 #3

P: n/a
On Wed, 20 Jun 2007 11:29:51 -0700, Beemer Biker <js*******@swri.edu>
wrote:
>Just because there's no Invoke() on the timer itself, that doesn't mean
that you can't use Invoke(). Just use it on the form to which the
timer belongs instead.

Thanks, I was unaware those tools existed nor have I used them. OK, i
looked at

this.Invoke(Delegate method, params object[] args)
and
this.InvokeOnClick(Control toIinvoke, EventArgs e)
Just one more example of where .NET carelessly uses the same word for very
different things. Please don't mix up Invoke() with InvokeOnClick(). The
latter simply raises an event, while the former has a specific behavior
with respect to the control's owning thread's message pump. The two
methods are not related at all in functionality.
[...]
So, I suspect I cannot use the InvokeOnClick
That is correct. It has nothing to do with the issue you've described.
However, you mentioned Invoke as used on the form. So maybe I can have
a delegate routine handle turning on and off the enable boolean on the
timer?
Yes, this is what I was suggesting.
I am not sure how to set that up. I will look at it and see what it
does (ie: poke around). Can you point me to any example code where
someone used "this.invoke(..)" with a delegate?
There is an example here:
http://msdn2.microsoft.com/en-us/library/zyzhdc6b.aspx

You can only use Invoke() with a delegate, so any example code you find
that uses Invoke() will be an example of code that uses Invoke() with a
delegate.
One would think a cross thread error message would show up if an invoke
was required but I have not seen one. All I have seen is the timer does
stop but never gets re-enabled.
I agree that a cross-thread MDA should occur, but note that the Timer
class itself is not actually the form. It's possible that the way that
the MDA exception is set up, it only detects cross-thread calls within the
actual Control class, rather than the more general case.

I don't actually know how the MDA works, so I can't comment on why it
wouldn't fire in this case. I also can't guarantee you that you're
running into a cross-thread issue. I just know that it stands to reason
that you might be, since the Forms.Timer class does use the underlying
WM_TIMER mechanism, and I think it likely that does require that calls be
made on the correct thread.

It's very easy to do your work on the correct thread, using Invoke(), so
it seems to me that's the first thing to try. That may or may not fix
it. If it does, great. If not, then you can pursue other possibilities.

Pete
Jun 20 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.