The code below shows a timer that ticks every 100* 1000(milliseconds) to show a pop up message for registration.The below code is working but unfortunately my application gets hang after some time.
I have searched in google and stackoverflow for this answer.But i couldnt find a correct answer to make my application work without getting hanged.
private System.Timers.Timer register_Timer = new System.Timers.Timer();
register_Timer.Interval = (100 * 1000);
register_Timer.Elapsed += new ElapsedEventHandler(register_Timer_Tick);
register_Timer.SynchronizingObject = this;
register_Timer.AutoReset = true;
register_Timer.Enabled = true;
System.GC.KeepAlive(register_Timer);
private void register_Timer_Tick(object sender, EventArgs e)
{
//Pop up to show register message
}
register_Timer.SynchronizingObject = this;
This completely defeats the reason for using System.Timers.Timer. It prevents the Elapsed event handler from being raised on a threadpool thread, the property ensures it will run on the UI thread. Which is what you wanted.
But you still get all the disadvantages of that Timer class. Particularly its habit for swallowing exceptions without a diagnostic is very ugly. As well as continuing to raise the Elapsed event after the form is closed, ensuring this cannot happen is a very difficult problem to solve, there are two inherent race conditions. .NET 1.0 had some design mistakes related to threading, this was one of them.
Just don't do this, use a System.Windows.Forms.Timer instead. It will work exactly like your timer, minus all the disadvantages.
The application hangs because you're doing a popup (I assume a MessageBox or some other modal dialog box). Of course the application is going to hang. You're putting a modal dialog up in the UI thread.
The problem isn't with the timer, but with your application design.
Related
I need to hook the message loop in a Windows Forms application to do some tick-count related work.
I'm developing a tcp server using async methods (async/await) and I'm avoiding dealing with race conditions in a multi-threaded process - this is basically the reason I'm using async/await instead of other models. Because of this restriction, I can't create a background thread to do the tick-counting because with this I will end up in a multi-threaded code.
An option I thought was to somehow hook up the message loop in the Windows Forms, so I could easily do my tick-count related stuff using the same thread of my Windows Forms object, although I didn't find any suitable method or event in the Windows.Forms.Application class.
Anyone knows a way to do what I need?
Thanks.
I think your best approach may be to use a timer, which will execute your code on a timed interval:
var aTimer = new System.Timers.Timer();
aTimer.Elapsed += new ElapsedEventHandler(OnTimedEvent);
aTimer.Interval = 5000;
aTimer.Enabled = true;
// What you want to happen when the Elapsed event is raised.
private static void OnTimedEvent(object source, ElapsedEventArgs e)
{
// Do something
}
You wouldn't want to override the message loop. That was a pretty common approach in much more primitive GUI solutions, but it is literally a last resort on .NET.
Since you just want a regular "tick", the most appropriate solution is a timer. Since you want it to run on the UI thread, you should use System.Windows.Forms.Timer.
I am going through this tutorial on how to perform some work in the background and in this piece of code I am confused as to why the message reading the file... is not displayed before the ReadTheFile(filename) method is called.
private void btnSelect_Click(object sender, EventArgs e)
{
OpenFileDialog ofd = new OpenFileDialog();
ofd.CheckFileExists = true;
ofd.CheckPathExists = true;
if (ofd.ShowDialog() == DialogResult.OK)
{
lblResults.Text = " ... reading the file ...";
FileReader1 fr = new FileReader1();
int numLines = fr.ReadTheFile(ofd.FileName);
lblResults.Text = string.Format("We read {0} lines", numLines.ToString());
}
}
The author explains it by saying the following, but it did not really get through to me.
Worse, even though we set the label’s Text property before we call ReadTheFile, the message loop doesn’t get a chance to process that change, and update the text, before we go out to lunch in ReadTheFile.
What does this mean? Can this be explained in simpler terms?
Worse, even though we set the label’s Text property before we call ReadTheFile, the message loop doesn’t get a chance to process that change, and update the text, before we go out to lunch in ReadTheFile.
Basically you are setting the text of label. However, you then start doing a "intensive" task that could take seconds, minutes, hours. As long as you are continuing to load the file and read the number of lines, the window will not update. That's the point of doing it in a background thread. Let the main thread continue to paint the window and handle UI stuff while your background thread processes the file.
I would continue with the tutorial. Once you get to the part where you start creating and running the background worker you may end up with one of those "Aha!" moments. =)
You may also be interested in reading up on threads in general.
http://www.codeproject.com/Articles/26148/Beginners-Guide-to-Threading-in-NET-Part-1-of-n
http://www.techrepublic.com/article/a-beginners-guide-to-threading-in-c/1044970
You could read Application.DoEvents Method .
When you run a Windows Form, it creates the new form, which then waits
for events to handle. Each time the form handles an event, it
processes all the code associated with that event. All other events
wait in the queue. While your code handles the event, your application
does not respond. For example, the window does not repaint if another
window is dragged on top.
So, until your btnSelect_Click is finished, your form will not repaint.
I'd edit my answer to remark, that one'd better not use DoEvents explicitly, as it may result in rather weird programm behaviour. (based on comment by J.Skeet).
You could read Use of Application.DoEvents() at SO also for more info. There is an extract from MSDN posted in that thread:
Calling this method causes the current thread to be suspended while
all waiting window messages are processed. If a message causes an
event to be triggered, then other areas of your application code may
execute. This can cause your application to exhibit unexpected
behaviors that are difficult to debug. If you perform operations or
computations that take a long time, it is often preferable to perform
those operations on a new thread.
I have an application that start System.Threading.Timer, then this timer every 5 seconds read some information from a linked database and update GUI on main form of application;
Since the System.Threading.Timer create another thread for the Tick event, i need to use Object.Invoke for updating User Interface on the main Form of application with code like this :
this.Invoke((MethodInvoker)delegate()
{
label1.Text = "Example";
});
The app work very well, but sometimes when the user close the main form and then close the application, if the second thread on timer_tick event is updating the user interface on main thread the user get an ObjectDisposedException.
How can i do for stop and close the threading timer before closing the main form and avoiding then Object disposed exception ?
This is a bit of a tricky proposition as you must ensure the following on a given Close event
The timer is stopped. This is fairly straight forward
The control being updated isn't disposed when the delegate is run. Again straight forward.
The code currently running off of a timer tick has completed. This is harder but doable
There are no pending Invoke methods. This is quite a bit harder to accomplish
I've run into this problem before and I've found that preventing this problem is very problematic and involves a lot of messy, hard to maintain code. It's much easier to instead catch the exceptions that can arise from this situation. Typically I do so by wrapping the Invoke method as follows
static void Invoke(ISynchronizedInvoke invoke, MethodInvoker del) {
try {
invoke.Invoke(del,null);
} catch ( ObjectDisposedException ) {
// Ignore. Control is disposed cannot update the UI.
}
}
There is nothing inherently wrong with ignoring this exception if you're comfortable with the consequences. That is if your comfortable with the UI not updating after it's already been disposed. I certainly am :)
The above doesn't take care of issue #2 though and it still needs to be done manually in your delegate. When working with WinForms I often use the following overload to remove that manual check as well.
static void InvokeControlUpdate(Control control, MethodInvoker del) {
MethodInvoker wrapper = () => {
if ( !control.IsDisposed ) {
del();
}
};
try {
control.Invoke(wrapper,null);
} catch ( ObjectDisposedException ) {
// Ignore. Control is disposed cannot update the UI.
}
}
Note
As Hans noted ObjectDisposedException is not the only exception that can be raised from the Invoke method. There are several others, including at least InvalidOperationException that you need to consider handling.
System.Timers.Timer is a horrible class. There is no good way to stop it reliably, there is always a race and you can't avoid it. The problem is that its Elapsed event gets raised from a threadpool thread. You cannot predict when that thread actually starts running. When you call the Stop() method, that thread may well have already been added to the thread pool but didn't get around to running yet. It is subject to both the Windows thread scheduler and the threadpool scheduler.
You can't even reliably solve it by arbitrarily delaying the closing of the window. The threadpool scheduler can delay the running of a thread by up to 125 seconds in the most extreme cases. You'll reduce the likelihood of an exception by delaying the close by a couple of seconds, it won't be zero. Delaying the close for 2 minutes isn't realistic.
Just don't use it. Either use System.Threading.Timer and make it a one-shot timer that you restart in the event handler. Or use a System.Windows.Forms.Timer, it is synchronous.
A WF Timer should be your choice here because you use Control.Invoke(). The delegate target won't start running until your UI thread goes idle. The exact same behavior you'll get from a WF timer.
Create two booleans called 'StopTimer' and 'TimerStopped'. Set the timer's AutoReset property to false. Then format the Elapsed method to the following:
TimerStopped = false;
Invoke((MethodInvoker)delegate {
// Work to do here.
});
if (!StopTimer)
timer.Start();
else
TimerStopped = true;
This way you are preventing a race condition, checking if the timer should continue and reporting when the method has reached its end.
Now format your FormClosing event as follows:
if (!TimerStopped)
{
StopTimer = true;
Thread waiter = new Thread(new ThreadStart(delegate {
while (!TimerStopped) { }
Invoke((MethodInvoker)delegate { Close(); });
}));
waiter.Start();
e.Cancel = true;
}
else
timer.Dispose();
If the timer hasn't stopped yet, a thread is launched to wait until it has done so and then try to close the form again.
I have a singleton timer in my WP7 application however I have no idea how to get it to update a textblock everytime the timer ticks... Is there a way to get the event handler of the timer ticking and then update the textbox with the correct time?
Here is what I tried to use but wouldn't work:
public _1()
{
InitializeComponent();
Singleton.TimerSingleton.Timer.Tick += new EventHandler(SingleTimer_Tick);
}
void SingleTimer_Tick(object sender)
{
textBlock1.Text = Singleton.TimerSingleton.TimeElapsed.TotalSeconds.ToString();
}
Here is my Timer.cs SingleTon:
http://tech-fyi.net/code/timer.cs.txt
void SingleTimer_Tick(object sender)
The method above should be something like
void SingleTimer_Tick(object sender, EventArgs e)
And when you ask a question please get your terminology right and give more details. It'll help you get the right answer faster. For example when you say "the application won't let me call ..." what you actually mean is the compiler gives you an error.
The method SingleTimer_Tick gets executed on a non GUI thread. Call
textBlock1.Invoke(() => textBlock1.Text = Singleton.TimerSingleton.TimeElapsed.TotalSeconds.ToString());
I'm not sure which type your timer is. Some are used to raise events on a thread pool thread, others on the GUI thread. If you could tell us the type of your timer (System.Timers.Timer, System.Threading.Timer etc.) then I can tell you what it's used for. However, if I remember correctly, Tick is used for the GUI timer whereas Elapsed is used for other timers - I might be wrong.
At the risk of patronizing you, I'm going to ask if you've started your timer or not :) Usually a call to Start() or setting Enabled to true will kick off a timer object. If you expect the timer to already be running you should be able to check a property such as Enabled to assert that it's running before you hook up the event.
Apart from that I'd do some printf style debugging to check that the event's actually being raised.
Whilst debugging my program in VS 2008 I have come across the following error:
The CLR has been unable to transition from COM context 0x34fc1a0 to COM context 0x34fc258 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this
It appears to be deadlocking even though the code only contains a simple C# timer: See Snippet Below:
private void RequestWork()
{
// The timer will be re-intialised if there are still no wating jobs in the database
StopTimer();
// assign all the threads some work
InitialiseTimer();
}
/// <summary>
/// Initialise a timer with a timer interval configured from app.config. Enable the timer and
/// register an appropriate event handler
/// </summary>
private void InitialiseTimer()
{
if (m_Timer == null)
{
// look up the default backoff time from the config
string backOffInt = ConfigurationSettings.AppSettings["BackOffInterval"];
int backoffInterval = 1000;
m_Timer = new System.Timers.Timer();
// set the timer interval to 5 seconds
m_Timer.Interval = backoffInterval;
m_Timer.Elapsed += new ElapsedEventHandler(m_Timer_Elapsed);
}
m_Timer.Enabled = true;
}
private void StopTimer()
{
if (m_Timer != null)
{
m_Timer.Enabled = false;
}
}
void m_Timer_Elapsed(object p_Sender, ElapsedEventArgs p_E)
{
RequestWork();
}
As far as I know the timer should run, elapse and then initialise again, I can see no local reason for a deadlock.
I am aware of how to turn this error msg off but feel that this is not a solution, instead it is masking the problem.
You can turn this off if you think you've definitely not got a deadlock situation:
Debug->Exceptions->Managed Debug Assistants menu in Visual Studio and uncheck the ContextSwitchDeadlock
This is an infinite loop. You need to let your application pump some messages at least once every 60 seconds to prevent this exception to happen.
Try calling System.Threading.Thread.CurrentThread.Join(10) once in a while. There are other calls you can do that let the messages pump.
It seems that you are adding a new event handler each time you call InitialiseTimer. That way m_Timer_Elapsed will be called as many times as it has been added.
You should add the event handler just one time.
If your application hangs or not reponse even after you uncheck the box against contextswitchdeadlock. Put the following line before call of method or for loop.
In C#
System.Windows.Forms.Application.DoEvents();
and VB.NET / VB / ASP.NET
DoEvents()
Couple thoughts/questions:
1) The code snippet looks like your interval is every 1 second (not 5 as mentioned in the comments).
2) The big question is what is RequestWork() doing?
Without knowing what RequestWork() is doing, we can't really comment on why you are seeing a ContextSwitchDeadlock.
Somethings to think about with respect to this method
a) how long does it take?
b) is it accessing GUI elements?
Some MSDN comments on Elapsed:
If you use the Timer with a user
interface element, such as a form or
control, assign the form or control
that contains the Timer to the
SynchronizingObject property, so that
the event is marshaled to the user
interface thread.
-and-
The Elapsed event is raised on a
ThreadPool thread. If processing of
the Elapsed event lasts longer than
Interval, the event might be raised
again on another ThreadPool thread.
Thus, the event handler should be
reentrant.
I'm thinking since you have a 1 second timer, you might want to look into what happens in RequestWork and see how long its taking.