Many programmers shy away from multithreading in applications, probably because it can be a complex and difficult concept to grasp. We tend to associate multithreading with huge, critical, complex applications and trick ourselves in to believing we don’t need it in our apps. However, the next time you are dealing with a non-responsive UI, you are dealing with a threading issue. Or try doing something as simple as implementing a simple ProgressBar, and you will be frustrated to the point of losing your mind… I think we’ve all been there!
One angry Google search later, and you’ll have your quick solution: Application.DoEvents(). Unfortunately, it’s all too easy to stick in that magic line to allow the UI to get repainted and remain responsive. Of course, you had to ignore 50 forum posts about how evil DoEvents is, but you continue to use it because actual multithreading is waaaaay to complicated and has got to be overkill for a simple UI responsiveness issue, right?
Headaches with threads often stem from complications due to confusing delegates, cross-thread operations, thread-safe calls… These are all definitely issues that need to be addressed in threading. However, if you are smart about keeping the actions of your thread compartmentalized, you can avoid most of the problems. For example, if you write a thread to do some processing work, it should only do that work–not interact with all your UI elements (of course there are exceptions to this rule)! Leave that to the main thread.
In the video, I show you how easy it can be is to do this with threading. I not only demonstrate the original frustration of a non-responsive UI, but show you how to solve the problem using threading instead of Application.DoEvents(). From brand new project to fully functional demo in just 5 minutes, with only 15 lines of written code.