Simple Threading Example

JasonD

Member
Joined
Aug 13, 2006
Messages
17
Location
Papillion, NE
Programming Experience
3-5
Heres a simple example on how to multi-thread your application.

Why Multi-thread?
When you have a critical process that needs to be ran, it may sometimes freeze, lock, or severaly slow down the main thread (form). To get past this, you simply create a new thread for the process to run on.

To get started, you first must import the System Threading
VB.NET:
Imports System.Threading
To assign a thread to a process, simple declare something as a New Thread and address it to a Sub.
VB.NET:
Dim xThread As New Thread(AddressOf SomeSub)

Public Sub SomeSub()
     ' Your process here
End Sub
To start the process, just call ThreadInstance.Start()
VB.NET:
    xThread.Start()
But, you dont want the thread to keep going after the form closes, right?
You must set the thread as a background thread, then start it.
VB.NET:
    xThread.IsBackground = True
    xThread.Start()
Source:
Download

Hope this helps someone new to VB.NET ;)
 
Thank you for this help with threads. However, I have run into a problem.

When I run your program and press "Start" it throws an exception saying that the progressbar has been accessed by a thread other than the one it was created on.

Error message:

"Cross-thread operation not valid: Control 'ProgressBar1' accessed from a thread other than the thread it was created on."
 
If you're using a ProgressBar to track the progress of a worker thread then the sensible option is to use a BackgroundWorker and call its ReportProgess method. This will raise the ProgressChanged event in the UI thread so there is no issue with making cross-thread control accesses.
 
The reason you get that error programmer1024 is because axactly as the message says. A control shouldn't be manipulated by any other thread than the one it was created on. If you think about it this makes sense othewise you have controls properties being altered all over the place and you would never know what is going on. All controls have an 'InvokeRequired' Property, this property returns a boolean value as to whether the calling thread is the same as the one that created the control (simply) If you're going to be looking into multi-threaded application you'll need to get familiar with this property. Also have a look in asynchronus delegates.
 
Sorry, I've never gotten that error before, so I was not aware of it..

As this is just an example, just change the whats in the threads sub, it was my coding issue, nothing to do with you ;).
 
In the form load event or wherever you want, before the new thread is started, just place this command.

Control.CheckForIllegalCrossThreadCalls = False

This will not raise the error anymore. This is new in 2.0 in 1.1 you never got this error.
 
Last edited:
That's a bad idea. Cross-threaded control access is illegal by default for a reason. Ignore that fact at your own peril. There are many situations where it just won't work and others where it will crash your app. That's the reason. Do you know which situations will cause issues and which won't? I don't. It's quite simple to use a delegate to access controls across thread boundaries the proper way, so setting CheckForIllegalCrossThreadCalls is just being lazy and slack. You are willfully making your app less robust. As I said, if you use a BackgroundWorker this is not an issue anyway, because the ReportProgress method, which you call from the worker thread, raises the ProgressChanged event in the UI thread. That means that if you access controls from the ProgressChanged event handler there is no issue, which is exactly why the BackgroundWorker was created in the first place. That and the fact that the RunWorkerComplete event is also raised in the UI thread when the work is done.
 
Yes I know which situations it will effect for my personal application because I have been multi thread programming since 1.0 and i've pretty much learned the in's and out's of all the errors that can happen. I personally prefer my own version of the Background worker class which raises events that can be handled on the main thread which in turn works exactly like a background worker (because it's the same idea) ect. You are correct however; background worker is a safer and cleaner way to get what you want. I was just showing another solution not dodging ones given. However; note that as I mentioned; you can build your own class to function as a background worker and tweak your own options and events. Multi threading is very fun and endlessly flexable but I won't argue that it get's dangerous and errors can become nearly if not impossible to track down. Keep the earlier suggestion for using background workers and or build your own to maintain better functionality.

On a side note. If your application contains a control such as a progress bar and that control is only ever accessed from within your new thread and only from a single new thread then setting that option to false won't harm a thing. The trick is to make sure your controls aren't interupted by seqential threads at the same time ect... There are many more problems that could happen but that is most popular. It's a matter of really understanding what your program is doing. If there are any chances that two threads may try to access the same object then make the object thread safe (for example hashtables are by default thread safe and can be accessed by multiple threads) or use a background worker.
 
Back
Top