Develop Reference

How do you make the application wait and keep other processes running at the same time in C#?

Using System.Threading.Thread.Sleep( ) makes the entire application stop for the time taken in the arguments. I want other processes running while one process is waiting for a particular amount of time. To put it in short, I want another way other than System.Threading.Thread.Sleep( ) in my application that does not stop the entire thing.
Example: If I have a label that changes text every 5 seconds, I should be able to press a button which can do some other process, like changing an image.

Thread.Sleep() only puts the current thread to sleep. If it is the UI thread, this might block your application and it looks like it is completely blocked. Background threads are still running.
If you want to sleep without blocking, you could use the following code:
await Task.Delay(5000);
// continue here with your code, such as updating your label
This doesn't block the UI thread, just delays the proceeding of your function. You have to declare your method as async

I am not too informed about this so I am not sure this is the best way to do it
The Task.Wait Method
like that your main thread waits for the child thread to complete before continuing. From here on to your problem I guess just brains will help
an other helpful link:
Thread Synchronization

Wait on thread for UI activity

I have read a lot on threading but can't figure out a way to make this one work right. So it should really be obvious how to do this as it usually is with me (always missing the obvious) :p
Here's my problem (BTW, am working with WPF in C#):
I have a long running process i'm running on a separate thread while the UI stays responsinve and showing evolution. However, mid-process, i need to ask the user to confirm a value before proceeding. That's what i can't figure out, cause the window to confirm the value must be run in the UI thread and still return the value to the work thread so it can continue it's work.
So...
Long running process beeing run in work thread
Work thread waits for UI Thread
UI thread shows the confirmation window
User confirms/fixes value and closes the confirmation window
UI thread sends result from confirmation window to work thread
work thread gets values from UI Thread (value was changed by user? to what?)
work thread continues long running process
Work thread gets values from confirmation window
I've already the work thread working well using ThreadPool - although am open to using threading in different ways (NET 4.5). Problem i am having is that if i send the confirmation window part to dispatcher my work thread won't wait for the results from the confirmation window. If i don't put in the dispatcher i get an exception about not beeing in an STA thread when the window constructor is called.
Any ideas welcome

You probably don't want to block the worker thread waiting on UI (not saying you couldn't do it, but it would be messy).
A much simpler solution would be to split up your process into two threads; one that runs pre-user input, and one that runs after. You would prompt the user upon the first thread's completion (via a callback or event).
Something like (pseudo-code)
InitialThreadObject.Completed += () =>
{
PromptForUI();
SecondThreadObject.Start();
}
InitialThreadObject.Start();
Obviously you would choose the completion notification mechanism based on your current code.

C# Window gets blank when busy -> Progressbar? But how?

I have a program which does some copy jobs (via File.Copy) that could last a few minutes. When the user brings another window to foreground in this time the program window gets blank since it doesn't redraw itself.
Now I want to show a ProgressBar in an extra window in the center of the screen, but that window get's blank too.
So I startet it in another thread which didn't help.
I'm quite sure someone did this before but I cannot find a working example. Any Ideas?

There is nice example in the documentation on BackgroundWorker class.

ChrisF is correct. Your long operation should be done in a BackgroundWorker thread. You can use BackgroundWorker to report progress, and hook that up to a progress bar on your form.

You need to thread your operation using a BackgroundWorker. There are other ways to thread the operation, but this one is probably the simplest, and will continue to perform message pumping in the foreground so Windows doesn't think your application has stopped responding.
Another option would be to use a Thread, and use Thread.Join to wait for the background task to complete, since Thread.Join also sends standard message pump information to Windows while it waits.

You can use BackgroundWorker class.
See this answer.

C# background worker

I have a task running in backgroundworker. on clicking the start button user starts the process and have got one cancel button to cancel the processing.
When user clicks on cancel, I would like to show a message box that "Process has not been completed , do you want to continue".
Here I want the processing which is left to be done only after user input. Till then want to halt the back ground thread. Can anyone help me on this. Is there anyway to halt the background worker for some time .Any kind of help will be appreciated.

Not built in. You could tell your code to (on every [n] loop iterations, etc) check something like a ManualResetEvent to see if it should keep running (at the same time it checks for cancellation). I don't recommend suspending the thread (Thread.Suspend), since you don't know what locks etc it may hold at the time.
On the other hand... why not let it run until you know it should be cancelled? Then you just need to check for cancellation (there is a flag for this) every [n] iterations...

If the BackgroundWorker is working on an object that is visible to both threads, you could 'lock' that object while waiting for the user to answer the question in a dialog box. This will cause the worker's thread to halt until the dialog-generating thread ends the lock.

C# Winforms How to update toolStrip in function

I'm building a UI for a program, and I can't figure out why my progress bar won't become visible after the convert button is clicked.
private void convertButton_Click(object sender, EventArgs e)
{
toolStripProgressBar.Visible = true;
...
toolStripProgressBar.Visible = false;
}
I ran into a similar problem with tkinter in Python, and I had to call a function to update the idle tasks. Is there a way to do this with windows forms without using threads?
Edit: On a side note, this is a progress bar in a toolStrip that also contains a label that gets updated with status bar text. Is there any way to get the label on the left side and the progress bar on the other instead of right next to each other on the left?

Well, there is a way to do this without using threads (Application.DoEvents) but I strongly recommend against you using it. Re-entrancy is nasty, and you really don't want the UI thread tied up at all.
Use BackgroundWorker instead - it's easy, and it's pretty much designed for progress bars. It takes the hassle out of using a separate thread and reporting progress back to the UI thread. No need for Control.Invoke etc - it takes care of that for you.
There are lots of tutorials for BackgroundWorker - it shouldn't take you too long to get going with it.

Per the question you asked for the way to do this WITHOUT threads, that is to do it with Application.DoEvents();. (Just add that call right after setting the progress bar as visible.)
Now I do agree with Jon Skeet though that BackgroundWorker is a better way of doing this, but it does use a separate thread.

You need to execute your process in a thread separate from the UI thread, and then have it periodically report back to the UI thread with it's progress. If your convert operation is working inside the UI thread, it will simply go unresponsive until the operation is complete.

The progress bar can only become visible when it is allowed to paint which occurs during the processing of messages. Message processing cannot normally happen while you are in the middle of an event handler. If you want the progress bar to show up you will have to set the visiblitity to true, start a background thread to complete the work and return from the handler.

I'm guessing the problem is that the "..." in your code is a long-running process. UI updates are not instantaneous, but must run through the message queue in windows and then be painted to the screen. The queue is pumped and painting takes place in the same thread as your events.
As a result, any long-running tasks need to be moved to a different thread. More than that, your line line of code needs to called after that thread terminates. Otherwise you set the progress bar and then immediately turn it off again.
One way to do that is with a BackgroundWorker control.

Here go two links trying to explain you how things work:
(1) (2)
Now, I will try to explain it as shortly as I can. Most of what happens inside a windows forms application happens in a single thread, usually the same thread Main() runs in. If you open Program.cs, you will see that Main() has a line that looks like the following:
Application.Run(new Form1());
If you debug the application at any moment and examine the call stack, you will see it will trace back to that Run method. This means that a Windows Forms application is in fact a continuous run of the Run method. So, what is Run doing? Run is eating a message queue through which Windows sends messages to it. Run then dispatches those messages to the correct controls, which themselves do things like add text which corresponds to the key being pressed, redraw themselves, etc. Notice that all this happens during and endless loop running alongside a single thread, so weather you are typing or simply moving the window around, loads of those messages are being passed onto the application, which in turn is processing them and reacting accordingly, all in that single thread. Controls can also send messages to themselves through the queue and even you can place messages in the pump via Control.BeginInvoke. One of the things those controls do is to raise events according to what happens. So, if you click a button, the code you've written to handle that click will ultimately and indirectly be run by the Application.Run method.
Now, what is happening with your code is that even though you are changing the visible status of your progress bar to visible and then updating its Value, you are then changing its visibility to false, all in the same method. This means that only after you leave the method, will Application.Run() be able to continue iterating and consuming the message queue, effectively asking the progress bar to update its display. When that happens, you've already left the progress bar's visibility to false, the last thing you did before exiting the method. DoEvents() is a quick and dirty workaround to your problem as it reads the messages in the queue and processes them. I don't really feel comfortable using it as it can bring reentrancy problems.
Using threads is a good solution, but I would recommend using a ThreadPool thread instead of a custom thread in this kind of situation, as I tend to use custom threads only in cases where I have a limited number of long lived threads and I need to control their life cycles. The easiest and most practical way to use threads is to use the BackgroundWorker component, even though I would recommend going through the pains of understanding how to do Windows Forms multithreading with delegates if you want to really understand what is going on.

My solution is to call refresh on the status strip.
I believe this causes the UI thread to repaint the status strip.
toolStripStatusBar1.PerformStep();
statusStrip1.Refresh();
This is for .NET 4.0. Even though this question is old it was the first I found on googling this issue.