I'm new to the world of threading, but a few aspects of an app I'm working on require me to use a BackgroundWorker control to prevent the UI freezing up while it's doing some file operations.
What I'm trying to do is update a couple of form labels from within the BackgroundWorker. Having never worked with this before I very quickly discovered that I can't access controls that weren't created within the same thread, so after a bit of research I've implemented the following code that seems to make everything work:
Private Delegate Sub DelegateUpdateStatus(ByVal statusText As String, ByRef currentFile As String)
Private Sub UpdateStatus(ByVal statusText As String, ByVal currentFile As String)
If InvokeRequired Then
Invoke(Sub() LblStatus.Text = statusText)
Invoke(Sub() LblCurrentFile.Text = currentFile)
Else
LblStatus.Text = statusText
LblCurrentFile.Text = currentFile
End If
End Sub
Thing is though, I have no understanding of what this code is doing, or why it's required.
I've done a bit of research but I've not done any real work with this kind of thing, and most articles I've read assume some kind of prior knowledge.
The three main things I looking to gain an understanding of:
As said, threading is still quite a foreign concept, so any answers in plain English would be really helpful - thanks!
EDIT: Thanks for the responses so far everybody. I've done some further reading, and I'm wondering if I'm going about this the right way. The reason I'm using a BackgroundWorker is to ensure that the UI remains responsive while I'm performing file operations. The issue is, I still need to wait until the BackgroundWorker has done its job so I can return a boolean indicating the success of the operation. There's ways to work around this, but from my reading, having to wait for a BackgroundWorker to complete its work is defeating the purpose of using it in the first place. So, what's the best way to go about preventing the UI from locking up?
OK, well done for getting so far.
Lets start with point 1.
From How to: Make Thread-Safe Calls to Windows Forms Controls
If you use multithreading to improve the performance of your Windows Forms applications, you must make sure that you make calls to your controls in a thread-safe way.
Access to Windows Forms controls is not inherently thread safe. If you have two or more threads manipulating the state of a control, it is possible to force the control into an inconsistent state.
So, as you can see, you need to ensure that when changing the state of a control, it is done in a threadsafe manner.
Now, the property Control.InvokeRequired checks whether the code you are executing is on a different thread to the one that originally created the control.
If it is, we need some way to call code on that original thread.
For this reason you need to use Control.Invoke Method to execute such code on the original thread.
Executes a delegate on the thread that owns the control's underlying window handle.
Now the thing is, you need to tell that thread what it should be executing, and this is done using the delegate.
Represents a delegate, which is a data structure that refers to a static method or to a class instance and an instance method of that class.
Now, the last thing I would recommend is that you look at what the differences between Delegates, Anonymous Delegates, Anonymous Methods and Lamda expressions.