I want to use a System.Windows.Forms.Timer to ensure that an event fires on the UI thread of an excel addin I'm creating. I construct the timer as follows:
private System.Windows.Forms.Timer _timer;
private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
Debug.WriteLine("ThisAddIn_Startup:" + Thread.CurrentThread.ManagedThreadId);
_timer = new System.Windows.Forms.Timer();
_timer.Tick += new EventHandler(TimerEventHandler);
_timer.Interval = 500;
}
The timer is fired by a COM event from a library I am using:
private void OnEvent()
{
_timer.Start();
}
I then expect the _timer to call the following method when it ticks:
public void TimerEventHandler(object sender, EventArgs args)
{
_timer.Stop();
Debug.WriteLine("Tick: " + Thread.CurrentThread.ManagedThreadId);
}
As I understand, when I create the timer in the Addin thread, even though it is started from another thread (COM event in this case), it should fire on the thread that it was created on, i.e. the addin thread. However, this doesn't happen.
I have implemented this exact mechanism in an RTDServer I wrote in the past (as outlined by Kenny Kerr) and it works as expected but the _timer in this scenario never ticks.
I have also read other SO articles that point to the same behavior and can't figure out what is different about my addin setup?
EDIT:
The OnEvent() method is fired.
The winforms timer is a control and must be used by placing it on a form. You never add it to a control-collection, so I would not expect it to work properly. The documentation says the following
Implements a timer that raises an event at user-defined intervals. This timer is optimized for use in Windows Forms applications and must be used in a window.
Therefore, I would suggest that you use an instance of the System.Timers.Timer class. This class can be used anywhere.
Note that the Tick-event you use above, is called by another name in the System.Timer.Timer class, namely the Elapsed-event.
I initially meant to post this as comment, but it turned to be too long.
Firstly, your thread structure is a bit confusing to me, the way you described it. Put Debug.WriteLine("OnEvent:" + Thread.CurrentThread.ManagedThreadId) inside OnEvent and let us know all thread IDs you see from your debug output.
That said, the rules are:
You should create WinForms' Timer object on an STA thread, and the thread should be configured as STA before it starts.
This thread may or may not be the main UI thread (where your main form was created), but it still should execute a message loop (with Application.Run) for timer events to fire. There are other ways of pumping messages, but generally you do not control them from .NET code.
You should handle the events sourced by WinForms' Timer on the same thread it was created. You can then 'forward' these events to another thread context if you like (using SynchronizationContext Send or Post) but I can't think of any reasons for such complexity.
The answer by #Maarten actually suggests the right way of doing it, in my opinion.
I don't yet understand why the Forms.Timer doesn't operate as expected but the following excellent article explains in detail how to marshal work onto the UI thread: http://www.codeproject.com/Articles/31971/Understanding-SynchronizationContext-Part-I
Related
Two questions.
One: in a winforms application is it a good or bad idea to have a system.timers.timer be enabled and disabled inside of it's elapsed event so that the main UI thread can have access to variables and methods that were created on that main UI thread? So for example with code:
myElapsedTimerEvent(object sender, ElapsedEventArgs args)
{
timer.enabled = false;
/***Call some functions and manipulate some variables***/
timer.enabled = true;
}
Two: In anyone's experience, what are some precautions and dangers to be warned about the system.timers.timer in winform and c#? Are there any examples that you can provide about things that could happen with the hardware and/or software if a timer is not used properly?
Any suggestions for using system.timers.timer would be much appreciated.
Thanks for reading.
It is safe to set the Enabled property of a timer from inside the event handler, provided that the event handler is executed in the UI thread. Otherwise it is not safe, because the System.Timers.Timer class is not thread-safe. The make the handler execute in the UI thread you must set the SynchronizingObject property of the timer to the current Form. For example:
public Form1()
{
InitializeComponent();
timer = new Timers.Timer(5000);
timer.Elapsed += Timer_Elapsed;
timer.SynchronizingObject = this;
timer.AutoReset = true;
}
If I am not mistaken, this assignment happens automatically when you use the designer to add a Timer in a Form.
My suggestion though is to use the System.Windows.Forms.Timer, because it comes without thread-safety considerations. You are not restricted to only one timer. You can have as many of them as you want. Just keep in mind that their handlers are running in the UI thread, so you should avoid putting lengthy code in there, otherwise the responsiveness of the UI may suffer.
Long story short, I need a precise timer in .Net - with prescision in milliseconds - meaning, if I tell it to fire an event when 10ms passes, it must do so, +-1ms. The built-in .Net Timer class has a precision of +-16ms it seems, which is unacceptable for my application.
I found this article http://www.codeproject.com/Articles/98346/Microsecond-and-Millisecond-NET-Timer which provides a code for a timer that is exactly what I need (even more - that has precision in microseconds).
However, problem is, the OnTimer equivalent seems to be executed in another thread. So, if I add some code that does, say:
label1.Text = "Hello World";
I will get an exception, and thus I will have to actually write it like this:
Invoke( new MethodInvoker(() =>{label1.Text = "Hello World";}));
This is, from what I understand, because the OnTimer event is fired from the timer's thread - where time is passed until enough has passed to be over the Interval, and then next OnTimer event is fired. The .Net Timer does not have such a problem - in OnTimer of the .Net Timer, I can freely modify controls's members.
Question: What should I change so that my timer will run it's OnTimer event in the main thread? Is adding "Invoke" the only choice?
While there are several ways of going about it, the one that I would generally prefer is to have the timer capture the value of SynchronizationContext.Current when it is created. That value will, when in the UI thread, contain the current synchronization context which can be used to execute methods in the message loop when in a UI context. This will work for winforms, WPF, silverlight, etc. All of those paradigms set a synchronization context.
Just grab that value when the timer is created, assuming it's created in the UI thread. If you want have an optional constructor/property to set the value so that you can use it even if the timer isn't created in the UI thread you can, although that shouldn't be needed most of the time.
Then just use the Send method of that context to fire the event:
public class Timer
{
private SynchronizationContext syncContext;
public Timer()
{
syncContext = SynchronizationContext.Current;
}
public event EventHandler Tick;
private void OnTick()
{
syncContext.Send(state =>
{
if (Tick != null)
Tick(this, EventArgs.Empty);
}, null);
}
//TODO other stuff to actually fire the tick event
}
There's no way around dispatching UI Element access to the main thread. If updating a UI element is really the only thing that you intend to do in the timer callback then forget about about your timer precision requirement. The user won't see the difference between 16ms and 50ms.
Otherwise carry out the time critical work in your timer callback and dispatch the rest of the UI work to the main thread:
void OnTimer()
{
// time critical stuff here
Invoke( new MethodInvoker(() =>{label1.Text = "Hello World";}));
}
In wpf you can use the dispatcher class to dispatch messages in the UI thread:
Dispatcher.CurrentDispatcher.BeginInvoke(
new Action(()=> label1.Text = "Hello World"));
In winforms you need to call the invoke method:
this.Invoke(()=> label1.Text = "Hello World");
I'm really struggling with this. I'm creating a winforms application in visual studio and need a background timer that ticks once every half hour - the purpose of this is to pull down updates from a server.
I have tried a couple of different approaches but they have failed, either due to poor tutorial/examples, or to my own shortcomings in C#. I think it would be a waste of time to show you what I have tried so far as it seems what I tried was pretty far off the mark.
Does anyone know of a clear and simple way of implementing an asynchronous background timer that is easily understandable by a C# newbie?
// Create a 30 min timer
timer = new System.Timers.Timer(1800000);
// Hook up the Elapsed event for the timer.
timer.Elapsed += OnTimedEvent;
timer.Enabled = true;
...
private static void OnTimedEvent(object source, ElapsedEventArgs e)
{
// do stuff
}
with the usual caveats of: timer won't be hugely accurate and might need to GC.KeepAlive(timer)
See also: Why does a System.Timers.Timer survive GC but not System.Threading.Timer?
Declare member variable in your form:
System.Timers.Timer theTimer;
On form load (or whatever other time you need to start update polling), do:
theTimer = new System.Timers.Timer(1800000);
theTimer.Elapsed += PollUpdates;
theTimer.Start();
Declare your PollUpdates member function like this:
private void PollUpdates(object sender, EventArgs e)
{
}
I think you need to know about all timer classes. See Jon's answer below.
What kind of timer are you using?
System.Windows.Forms.Timer will execute in the UI thread
System.Timers.Timer executes in a thread-pool thread unless you
specify a SynchronizingObject
System.Threading.Timer executes its callback in a thread-pool thread
In all cases, the timer itself will be asynchronous - it won't "take up" a thread until it fires.
Source: Do .NET Timers Run Asynchronously?
In my form's class, I've added a method to "fade" it out. This makes use of System.Timers.Timer and the Elapsed event uses a delegate to change the form's opacity. This was the code:
public void FadeOut()
{
// Timer for transition
Timer fade = new Timer();
// Transition code
fade.Elapsed += delegate
{
this.Opacity += 0.05;
if (this.Opacity >= .95)
{
this.Opacity = 1;
fade.Enabled = false;
fade.Dispose();
}
};
fade.Interval = 100;
fade.Enabled = true;
}
This caused a "Cross-thread operation not valid" error, which is a common hurdle I see. So I looked around for solutions and the first ones to come up involved using .BeginInvoke and blocks of code to keep the call to the same thread as the control. But I found this looked really bulky, so I kept looking and then discovered the SynchronizingObject property of System.Timers.Timer. This seems better because it only needed one extra line of code:
// Timer for transition
Timer fade = new Timer();
fade.SynchronizingObject = this;
The code runs fine now. But I'm really confused, how come a lot of solutions are suggesting the use of BeginInvoke/Invoke when all that's needed is to set SynchronizingObject to the form control?
Mostly because it is pointless to use the property. Yes, it ensures that the Elapsed event handler runs on the UI thread. But now it just does the same thing as a System.Windows.Forms.Timer.
Not quite though, it is worse. Because it doesn't guarantee that Elapsed won't be called after you disable it. Disabling it doesn't flush any pending invokes nor TP threads that aren't ready to run yet. There could be hundreds if the Interval is small compared to the amount of work done by the handler.
You absolutely want a System.Windows.Forms.Timer here. You are not doing any useful work on the threadpool thread.
I'm not sure, but I believe that the Timer will internally use Invoke or BeginInvoke as well on the SynchronizingObject property.
Let us say that this property just gives some abstraction to the developer; to make his life easier.
My guess was indeed correct, this is what Reflector tells us about the MyTimerCallback private member method of System.Timers.Timer:
ElapsedEventHandler onIntervalElapsed = this.onIntervalElapsed;
if (onIntervalElapsed != null)
{
if ((this.SynchronizingObject != null) && this.SynchronizingObject.InvokeRequired)
{
this.SynchronizingObject.BeginInvoke(onIntervalElapsed, new object[] { this, e });
}
else
{
onIntervalElapsed(this, e);
}
}
Why don't you use the WinForms timer? This is based on window messages and will always run in the UI thread; since you want to perform updates where the UI thread needs to pump messages anyways this may be a better solution (no synchronization/blocking required).
Timer solutions like this are really a bit of a hack.
You'd be better off writing a proper asynchronous thread and doing the callback either with
BeginInvoke or SynchronizationContext.
As you rightly observe, it's far from a one-liner, but multi-tasking, done properly, never is.
The point is the SCOPE of code. The whole event handler? or just the UI changing code.
timer.SynchronizingObject make the event handler to be called on the thread of given object. If you set this to 'this' in 'Form1' class, This means that all of your code for processing timer event is run by that same thread of 'Form1' instance even though you created a thread based timer. So this does NOTHING. SAME as windows form timer.
The reason you want to do this is because you want to access UI controls and make some changes in Form1, but the whole UI hangs if you use windows form timer. Because they all get executed on the same thread.
To avoid this, you use a threading based timer. Your event handler is called on another thread that comes from some system thread pool. This solves the problem of hanging UI. However, this brings up another problem. Cross-thread accessing UI controls exception. On some versions of Visual Studio, you can disable this checking on debug builds. But there is no way you can just bypass this checking on release builds. This thread checking is just by design to safeguard from crashes caused by multi-threading. THEN you need to use all those invoke and delegation stuff.
The important part here is that it is the only few lines of code that is redirected to be run on the Form1 thread. Not the whole event handler. Most of the event handling code is run on another thread. And that includes code like doing something on network or disk.
This makes the DIFFERENCE.
BUT, all these apply to windows form apps only. For WPF, just use dispatcher timer. (This is why you cannot find Windows.Threading in WinForm because you can't used dispatcher timer in WinForm, but available in WPF)
I just added some extra functionality to a Coding4Fun project. I have my project set up with an extra option to allow it to automatically change the background after X amount of time. X is set from a ComboBox. However, I know I've done this in a terrible way, as I have created a new timer class with System.Timers.Timer as a parent so when the static method in the ElapsedEventHandler is called, I'm able to get back to the form and call ChangeDesktopBackground().
What is a better way to call ChangeDesktopBackground() at a user defined interval?
Here is my current solution, which involves me casting the sender as my inherited timer, which then gets a reference to the form, which then calls the ChangeDesktopBackground method.
private static void timerEvent(object sender, System.Timers.ElapsedEventArgs e)
{
((newTimer)sender).getCycleSettingsForm().ChangeDesktopBackground();
}
Edit:Added coding sample to show current solution
I've written something like this before myself. System.Timers.Timer is overkill for this. You should probably use System.Windows.Forms.Timer, for a couple of reasons:
You're doing something that doesn't have to be too precise. The Windows timer is just a WM_TIMER message sent to your windows app's message pump, so you're not getting super great precision, but changing your wallpaper once a second is unrealistic. (I wrote mine to change every 6 hours or so)
When using a Windows Forms app that does some kind of timer-based task, you're going to run into all kinds of thread affinity issues if you go with System.Timers.Timer. Any Windows control has an affinity for the thread on which it was created, meaning that you can only modify the control on that thread. A Windows.Forms.Timer will do all that stuff for you. (For future nitpickers, changing wallpaper doesn't really count, cause it's a registry value change, but the rule holds generally)
Timers are probably the most straight-forward way of doing it, although I'm not sure you're using a timer correctly. Here's how I've used timers in my projects:
// here we declare the timer that this class will use.
private Timer timer;
//I've shown the timer creation inside the constructor of a main form,
//but it may be done elsewhere depending on your needs
public Main()
{
// other init stuff omitted
timer = new Timer();
timer.Interval = 10000; // 10 seconds between images
timer.Tick += timer_Tick; // attach the event handler (defined below)
}
void timer_Tick(object sender, EventArgs e)
{
// this is where you'd show your next image
}
Then, you'd connect your ComboBox onChange handler such that you'd be changing timer.Interval.
I would use Microsoft's Reactive Framework for this. Just NuGet "Rx-WinForms".
Here's the code:
var subscription =
Observable
.Interval(TimeSpan.FromMinutes(1.0))
.ObserveOn(this)
.Subscribe(n => this.getCycleSettingsForm().ChangeDesktopBackground());
To stop it just do subscription.Dispose().
Simple.