Develop Reference

is Thread.Join() a good way to let main thread update GUI while a thread func is working

I have Main() function which displays in label the current time. There is a button which calls a function LoadUserImage() for reading image files and writing them to database and then showing the result of reading and writing in another label. While LoadUserImage() is running I want the Main() function to still display in label the current time. My instructor tells me to put LoadUserImage() in a separate thread and then join it. But on his lectures he tells that Thread.Join() makes the main thread kind of pause temporarily The question is: if joining makes the main thread pause then how can it update the GUI in my case?

The purpose of Thread.Join() is to make sure that the background thread started previously is stopped properly, but it is not needed for the background thread to work.
In your case, you start the long-running operation in a background thread, and in the main thread proceed with the other activities. You need to call Thread.Join() only at the end, when the main thread has already finished its activity. If at that point the background thread had terminated already, Thread.Join() will return right away, while if the background thread is still busy, it will block (in the main thread) until the background thread has finished. This is the way to make sure an app is not exiting until operations are active in the background.
I suppose in your Main() (running in the main thread) you have some loop which periodically updates some UI. This loop has some exit condition (e.g. by reacting to pressing Enter in a Console.ReadLine(), or a Ctrl-C handler). Once the loop is exited, it can call Thread.Join().
If proper exit is not implemented at all in your sample program (which is not so nice, but usual in such sample program), then you don't have to call Thread.Join() at all! When the process exits, all threads disappear anyways.

Visual Studio standalone .exe - background worker doesn't do its job

I have a program that copies a .zip file from one directory to another and unzips it. I use background worker for this.
Now the program works when it's started using the Visual Studio Start button or double clicked directly from Debug/program.exe, but when I copy this .exe file elsewhere, it starts properly doing some operations on the main thread, but the background worker doesn't seem to work.
Does anyone have any clue what's going on?

Note to self: Always remember about third-party .dll files. I didn't have them in my output directory so the program wasn't working. Thanks #KoBE.

It is looks like main thread finished, while Background thread do not finished his work. I think you need in main thread wait until background thread finished. You can use synchronization objects, for example Manual/Auto reset events.
Scheme is simple:
1. In main thread you starts some background thread
2. Before main thread finished, it shall wait until background thread finished working
3. When background thread finished working, main thread can be finished too
In debug mode because of delays and breakpoints in main thread, background thread has enough time to finish his work

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.

How to see background threads in Visual Studio 2010 debugger

I'm trying to figure out why the application process lingers in Task Manager after the application is closed and the window disappears.
When I get VS to attach to the zombie process and break all, the threads window shows that the main thread is still alive, and a number of worker threads as well.
Some questions:
Are worker threads necessarily background threads? If not, how do I identify the background threads as I didn't see such a column in the window?
Do I simply double-click on each thread in the thread window, and watch the Thread.IsBackgroundThread value?
When I click on the main thread, the debugger doesn't show a call stack. How
do I identify where the main thread is stuck?

I would strongly sugest you tu use WinDbg. It is not a visual debugger though it is much more powerful.
Surely I will figure you out.
To list all threads in a process use: ~.
To switch to a certain thread ~thread_ids.
To see stak of curent thread !clr_stack.
Brief tutorial.
http://www.codeproject.com/KB/debug/windbg_part1.aspx
Also try in google "Debuging Asp.net with windbg"

Progress reporting to parent UI thread

apologies if I don't explain this clearly, but I'm writing an app which is causing me some problems with threading.
I have a UI which starts a System.Timers.Timer. Each time this timer elapses it triggers a workflow which opens a progress screen. To prevent another workflow starting before the last one has finished it locks an object on the main form.
This progress screen starts and reports the progress of, some file copying using FileCopyEX.
The problem I'm having is that the progress screen does not display until after the work flow has been completed.
Hopefully this will make it clearer:
Main Form
|
Timer Elapses
|
WorkFlow Starts
|
Progress Screen opens (errors which occur go back to the previous)
|
File copying occurs (progress reported back to progress screen)
If no errors, returns to main screen before next tick.
Until now I've only implemented very simple threading, so I'm not sure how best to implement this. I've tried starting the workflow on a BackGroundWorker to seperate it from the UI thread but it behaves the same.
Thanks

I suggest that you read about the BackgroundWorker. This has hooks for reporting progress.
Remember that system timers invoke its event handler on a non-UI thread. Whenever, you do something with the UI you must be on the UI thread.

Without the code I can only guess at the cause, but the likely reason is that the Progress window needs the UI to be pumping messages to appear - i.e. the UI thread needs to be running.
If the UI thread is busy running your workflow, then it won't get around to processing the displaying of your window until after that. You need to separate your flow so that the progress window is on your UI thread and the workflow is on a background thread.
Hope that makes sense!