I have this code in a winform app:
for (int i = 1; i <= 20; i++)
{
lbl.Text = i.ToString();
Thread.Sleep(100);
}
I expected to see the label progress from 1 to 20 but instead it just hangs while the for loop is running and then displays a 20, i.e. I don't see 1-19.
Why is this and is there a way to update the label text quickly similar to the milliseconds on an analogue clock (I'm not making a clock, just an example.)
Thanks
*EDIT: This also happens if I have a button with an event that increments the number without Thread.Sleep but I have a beginInvoke to play a wav file *
You are sleeping the gui thread, so before the gui gets to update its slept again.
Try using a timer with a tick of 100ms
Call Application.DoEvents(); before sleep, that will process all messages in the queue:
for (int i = 1; i <= 20; i++)
{
lbl.Text = i.ToString();
Application.DoEvents();
Thread.Sleep(100);
}
The application hangs and you only see 20 simply because this would appear to be executing on the UI thread and you're Sleeping it, and therefore choking the window message loop. However, even if that wasn't the case, you'd most likely only ever see 20 anyway as the loop would execute so fast.
Use a System.Threading.Timer to execute every x milliseconds and update your label by invoking the appropriate method on the UI thread.
The following post demonstrates how to implement what you might want (albeit in the WPF environment, but the principle is the same - use ISynchronizeInvoke for WinForms as opposed to the Dispatcher shown in WPF here):
Timer callback closes WPF app (DispatcherTimer works..)
Use Timer control
int i=0;
private void timer_Tick(object sender, EventArgs e)
{
if(i <=20)
{
lbl.Text = i.ToString();
}
i++;
}
Set TimerInterval according to your need (Interval of 1000 = 1 second)
Related
This is my code:
Stopwatch timer = new Stopwatch();
timer.Start();
while (timer.ElapsedMilliseconds < 3000) {
label1.Text = Convert.ToString( timer.ElapsedMilliseconds );
}
timer.Stop();
My intetion was to update the label's text in real time, so if timer.ElapsedMilliseconds == 1350, then label1.Text = 1350. How can I do this? Thanks in advance!
You better to use System.Windows.Forms.Timer for this, and not Stopwatch()
Even if that timer is less accurate then StopWatch(..) it gives you a good control.
Just example sniplet:
myTimer.Tick += new EventHandler(TimerEventProcessor);
myTimer.Interval = 1350;
myTimer.Start();
private void TimerEventProcessor(...){
label1.Text = "...";
}
You cannot update the UI in a tight loop like that, because while the UI thread is running that code, it isn't responding to paint events. You can do nasty things like "DoEvents()", but please don't... it would be better to just have a Timer and update the UI periodically when the timer event fires; every 50ms would be the absolute fastest I'd go, personally.
Is this a WinForms app?
The problem is that while your loop runs, it does not give any other tasks (like updating the GUI) any possibility to get done, so the GUI will update the the entire loop is complete.
You can add a quick and "dirty" solution here (if WinForms). Modify your loop like this:
while (timer.ElapsedMilliseconds < 3000) {
label1.Text = Convert.ToString( timer.ElapsedMilliseconds );
Application.DoEvents();
}
Now the label should update in between the loop runs.
If you want it update every second you could use the modulus operator in your while loop:
Stopwatch timer = new Stopwatch();
timer.Start();
while (timer.ElapsedMilliseconds < 3000) {
if (timer.ElapsedMilliseconds % 1000 == 0)
{
label1.Text = timer.ElapsedMilliseconds.ToString();
}
}
timer.Stop();
The modulus operator gives the remainder of a division operation, if the milliseconds are a multiple of 1,000 it will return 0.
I'd probably look into using Timers. You do a lot of spinning using the above technique, that may cause your UI to be unresponsive.
i am programming a benchmark tool, that reads a bunch of variables from a local server in a thread.
int countReads = 1000;
Int64 count = 0;
for (int i = 0; i < countReads; i++)
{
Thread.CurrentThread.Priority = ThreadPriority.Highest;
DateTime start = DateTime.Now;
session.Read(null, 0, TimestampsToReturn.Neither, idCollection, out ReadResults, out diagnosticInfos);
DateTime stop = DateTime.Now;
Thread.CurrentThread.Priority = ThreadPriority.Normal;
TimeSpan delay = (stop - start);
double s = delay.TotalMilliseconds;
count += (Int64)s;
Dispatcher.Invoke(DispatcherPriority.Render, new Action(() =>
{
progressBar1.Value = i;
}));
}
double avg = (double)count / countReads;
Dispatcher.Invoke(DispatcherPriority.Input, new Action(() =>
{
listBox1.Items.Add(avg);
}));
I am calculating the timespan it took to proceed the read and getting the average timespan at the end.
DateTime start = DateTime.Now;
session.Read(null, 0, TimestampsToReturn.Neither, idCollection, out ReadResults, out diagnosticInfos);
DateTime stop = DateTime.Now
if i run the code without updating the progressbar it took about 5ms average.
but if i run it with
Dispatcher.Invoke(DispatcherPriority.Render, new Action(() =>
{
progressBar1.Value = i;
}));
it takes about 10 ms average.
My question is, why is the timespan higher when using the progressbar?
i am just calculating the timespan for the read. Not including the progressbar update.
Is there any way to evacuate the ui-painting so that it doesn´t effect my read-timespan?
Thanks for your help.
Best regards
Stop using Invoke to transfer progress information to the UI thread. Publish the progress information to a shared data structure or variable and have the UI thread poll for it using a timer on a reasonable interval. I know it seems like we have all been brainwashed into thinking Invoke is the be-all method for doing worker-to-UI thread interactions, but for simple progress information it can be (and often is) the worst method.
A polling method using a timer on the UI thread offers the following benefits.
It breaks the tight coupling that Invoke imposes on both the UI and worker threads.
The UI thread gets to dictate when and how often it should update the progress information instead of the other way around. When you stop and think about it this is how it should be anyway.
You get more throughput on both the UI and worker threads.
I know this does not directly answer your question as to why session.Read appears to run slower. Try changing your strategy for updating progress information from a push model (via Invoke) to a pull model (via a timer). See if that makes a difference. Even if it does not I would still stick with the pull model for the reasons listed above.
Here is what MSDN says about Dispatcher.Invoke
Executes the specified delegate synchronously on the thread the Dispatcher is associated with.
So, basically, Dispatcher.Invoke blocks until the dispatcher thread as handled the request.
Try Dispatcher.BeginInvoke instead.
If current executing thread is associated with Dispatcher you are using - Invoke() will block this thread so in this case try out using Dispatcher.BeginInvoke() it will do the job asynchronously.
MSDN, Dispatcher.Invoke Method:
Invoke is a synchronous operation; therefore, control will not return
to the calling object until after the callback returns.
BTW, just of interest try out DispatcherPriority.Send
I came 9 years late to the party, but I think this is an even easier solution: Just wait until the progress bar value reaches a certain threshold before updating it. In my example, I refresh the toolbar every fifth of the maximum value.
private static int progressBarMaxValue = -1;
private static int progressBarChunkSize = -1;
public static void progressBarSetNotRealTimeValue(ProgressBar progressBar, int argNewValue)
{
if (progressBarMaxValue != -1)
{
if (argNewValue < progressBarChunkSize)
{
//Threshold not reached yet, discard the new value.
return;
}
else
{
//Allow the update, and set the next threshold higher.
progressBarChunkSize += progressBarChunkSize;
}
}
if (Thread.CurrentThread.IsBackground)
{
progressBar.BeginInvoke(new Action(() =>
{
if (progressBarMaxValue == -1)
{
progressBarMaxValue = progressBar.Maximum;
progressBarChunkSize = progressBar.Maximum / 5;
}
progressBar.Value = argNewValue;
}));
}
else
{
progressBar.Value = argNewValue;
}
}
I am trying to generate a random fruit and display it on GUI in a label. I am using this code to do it.
partial class Form1 : Form
{
int MagicNumber = 0;
List<string> NameList = new List<string>();
Random r = new Random();
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
NameList.Add("Apples");
NameList.Add("Pears");
NameList.Add("Oranges");
NameList.Add("Bananas");
NameList.Add("Kiwi");
for (int i = 0; i < 8; i++)
{
Thread t = new Thread(new ThreadStart(Display));
t.Start();
label1.Text = NameList[MagicNumber];
Thread.Sleep(1000);
}
}
private void Display()
{
MagicNumber = r.Next(5);
}
}
The problem is the fact that in GUI i see only the last result of fruits choice and not how they are skipped from an iteration to other. I thought that this code will give me the possibility to see how fruits changes until the last was chosen , when i is 8.
Please if you have an idea why this code is not displaying how the fruits are chosen in label give me a hand !
Thanks.
You seem to be confusing timers and threads. In this case, I think what you want is a timer; specifically, System.Windows.Forms.Timer. You might do something like this:
partial class Form1 : Form
{
Timer timer = new Timer();
private void button1_Click(object sender, EventArgs e)
{
int i = 0;
timer.Tick += (s, e) =>
{
if (i < 8)
{
label1.Text = nameList[r.Next(5)];
i++;
}
else
timer.Stop();
};
timer.Interval = 1000;
timer.Start();
}
}
The idea is that you set a timer to tick once a second, and then each time it ticks, you change the label and increment the counter until it reaches 8 -- at which point it stops. You always want to make sure you call Start() after you've set Tick and Interval; otherwise, under some strange circumstances, the timer might tick before you have a chance to change the settings.
Alternatively, you could use threading and Sleep(), in which case it might look like this:
private void button1_Click(object sender, EventArgs e)
{
Thread t = new Thread(new ThreadStart(Display));
t.Start();
}
private void Display()
{
for(int i = 0; i < 8; i++)
{
label1.Text = NameList[r.Next(5)];
Thread.Sleep(1000);
}
}
Thread.Sleep() always sleeps the thread that it's called from -- so maybe this is what you meant to do.
However, this might throw a thread synchronization exception -- Forms prevents you from accessing UI controls from another thread, since it might be in an invalid state (i.e. in the middle of rendering or doing something else that's volatile). System.Windows.Forms.Timer actually runs on the UI thread, so it's easier to manage.
Your approach is flawed, but you may want to understand what is going on in your code, as it may help you find a better approach:
for (int i = 0; i < 8; i++)
{
Thread t = new Thread(new ThreadStart(Display));
t.Start();
label1.Text = NameList[MagicNumber];
Thread.Sleep(1000);
}
You are looking through, creating eight threads every time the button is clicked. Do you have a reason to create eight threads? If so, you may want to create them once, inside your init function and reuse them.
Then there is a race here in that your threads may not have had time to change MagicNumber before it is used, as the loop starts the threads then immediately changes the text, before going to sleep.
The sleep is another problem, as you haven't gotten off of the main (event) thread, so the text isn't changed until you exit that event handler.
If you want to see the text changing, then you will need to get off of the main thread, and in a second thread go through and do the loop of eight.
Then, you can put that thread to sleep, and since the main thread was free to make the change you will see it.
Here is an article from MS that is a bit dated, but the basic idea should help you:
http://msdn.microsoft.com/en-us/magazine/cc188732.aspx
Now you can use lambda expressions for your threads, as shown here:
http://www.rvenables.com/2009/01/threading-tips-and-tricks/
Just call Application.DoEvents(); after assigning text to label - that will refresh UI.
BTW I don't understand why you are using threads to generate random numbers
The problem is that when you execute an event handler or a function called from it, the changes are rendered at the end. Try changhing the label text inside the thread where you get the random number. You also have to set the CheckForIllegalCrossThreadCalls property to false in the form constructor.
Your observed problem of the form not refreshing is due to your function blocking the GUI thread and preventing a redraw of the window while its running. And it's continuously running for 8 seconds. The GUI thread needs to handle messages to allow a window to be redrawn.
But apart from what you observed it has has at least two theoretical problems related to threading:
The read of MagicNumber isn't volatile, so the compiler may read it only once and cache the result. It probably won't do that in practice since the code between each reading of the variable is so complicated that it can't guarantee that they won't affect the variable.
r.Next isn't threadsafe. So calling it from two different threads at the same time can corrupt the Random instance. Won't happen in practice either since the delay is so long that one thread will most likely have finished before the next one starts.
There is a much better way to choose a random item:
label1.Text = NameList.OrderBy(f => Guid.NewGuid()).First();
Randomizing on different threads is a bad idea in of itself.
I am doing some experimenting with threads, and made a 'control' method to compare against where all the processing happens in the UI thread. It should run a method, which will update a label at the end. This method runs four times, but the labels are not updated until all 4 have completed. I expected one label to get updated about every 2 seconds. Here's the code:
private void button1_Click(object sender, EventArgs e)
{
Stopwatch watch = new Stopwatch();
watch.Start();
UIThreadMethod(lblOne);
UIThreadMethod(lblTwo);
UIThreadMethod(lblThree);
UIThreadMethod(lblFour);
watch.Stop();
lblTotal.Text = "Total Time (ms): " + watch.ElapsedMilliseconds.ToString();
}
private void UIThreadMethod(Label label)
{
Stopwatch watch = new Stopwatch();
watch.Start();
for (int i = 0; i < 10; i++)
{
Thread.Sleep(200);
}
watch.Stop();
// this doesn't set text right away
label.Text = "Done, Time taken (ms): " + watch.ElapsedMilliseconds;
}
Maybe I'm just missing something basic, but I'm stuck. Any ideas? Thanks.
Your UI thread is a single thread, not two threads. To get your UI to be responsive, you either have to put the work on another thread (generally with a BackgroundWorker), or tell the UI to repaint itself in the UI thread.
I always have to experiment when I do things like this, but the Control.Refresh method should do it:
http://msdn.microsoft.com/en-us/library/system.windows.forms.control.refresh.aspx
You're blocking the UI thread by performing the sleep operations, which causes no redraws to happen. If you would sleep on another thread and Invoke the Label updates on the UI thread, then it should work as expected.
I am using the below code to update my progress bar.
ProgressBar.Visible = true;
ProgressBar.Minimum = 1;
ProgressBar.Maximum = PortCount;
ProgressBar.Value = 1;
ProgressBar.Step = 1;
int intdata = 5;
for (int x = 1; x <= intdata; x++)
{
ProgressBar.PerformStep();
}
MessageBox.Show("Done");
But, it is not getting updated during runtime. Is it because the progress bar is in the same thread. If so, how to update this progress from another thread. Help...
You are not giving the message pump time to update the control.
Although either of these are bad, you can do:
Call Refresh on the control
Call Application.DoEvents
Is this Windows Forms? Calling Refresh() on the ProgressBar should do it. You could also use Application.DoEvents though which will let your UI respond to user input instead of locking up during the process.
A better idea would be to use the BackgroundWorker class. Do the work on the background thread and send progress updates to the UI thread via the ReportProgress method. This keeps your UI thread responsive.