1. Multi-Threading WPF Inside of AutoCAD
Welcome to my Multi-Threading WPF inside of AutoCAD presentation.
Multi-Threading WPF Inside of AutoCAD
Fenton Webb
Autodesk Developer Evangelist

2. About the Presenter
Fenton Webb Developer Technical Services Americas Autodesk, Inc
Fenton has been a member of the Autodesk DevTech team since Originally a member of our EMEA team, he has recently relocated to California to work for DevTech Americas.  Fenton is an expert in all the AutoCAD APIs, AutoCAD OEM, RealDWG and Plant3d. He particularly enjoys travelling to evangelise the APIs he support at our annual Developer Days conferences. 
Before joining Autodesk, Fenton worked for an ADN partner developing ObjectARX applications in the Civil and Structural Engineering domain.

3. Autodesk Developer Network
Access to almost all Autodesk software and SDK’s
Including early access to Beta software
Members-only website with 1000s of technical articles
Unlimited technical support
Product direction through conferences
Marketing benefits
Exposure on autodesk.com
Promotional opportunities
1 to 3 free API training classes
Based on user level
About the Autodesk Developer Network… Just in case some of you may be unfamiliar with A DN.
The Autodesk Developer Network is a program providing professional support to programmers writing addin applications for Autodesk software. If you think the program benefits listed here would be useful to you, then visit this URL and read more about it.
And by the way, you don’t have to be a commercial software developer to join ADN.

4. Agenda What is WPF? What is Multi-Threading? Multi-Threading and WPF
What about Multi-Threading WPF inside of AutoCAD?
So here’s the agenda for today.
As this presentation is about Multi-Threading in WPF, I thought it would be a good idea just to quickly recap about what WPF is, actually. Then I’ll follow up with a talk about what Multi-Threading is. Then onto Multi-Threading and WPF, and the things we have to watch out for when programming it. Finally, I’ll talk about Multi-Threading WPF inside of AutoCAD, and what you need to consider.
Before I carry on, I just want to mention that there is a lot of material on threading out there, and that can be confusing. So, for this presentation I will attempt to make it as easy as possible to understand multi-threading inside of WPF.

5. What is WPF? Windows Presentation Foundation
Technical Information
Windows Presentation Foundation
Next Generation GUI Developer Platform from Microsoft
New update to WinForms
Packaged with .NET Version 3.0
Driven by Direct3D drivers
Uses XAML
eXtensible Application Markup Language
XML based
Declarative Language
Requires very little programming
Now, I don’t want to stay too long with this slide, but just as a recap - What is WPF? Well, WPF is basically an updated UI SDK from Microsoft. It’s the next in the series, as it were… First we had Win32, then MFC, then VB Forms, then .NET WinForms and now, finally, WPF.
WPF is really, really cool- and I have to say that I absolutely love it! It uses a special XML language called Xaml to describe the UI layout and also how it works… and requires very little programming, although I found it very difficult to learn in the beginning.

6. Windows Presentation Foundation
What is WPF?
Let’s see it for real...
Windows Presentation Foundation
by Microsoft
Actually, there’s so much to WPF, that for those who haven’t seen it before, I think it’s better that you take a look at this video as it gives a great overview of the technology. This recording is accompanied by this Powerpoint, so you will be able to click on the link from there.

7. What is Multi-Threading?
All about Threads...
The utilization of multiple concurrent execution threads in the same process
Threads…
Are used to do “work”.
Run separately from UI/Main Thread.
Share the same application resources as the UI/Main Thread.
Usually need to notify the Main Thread of “work” that is complete
To update UI, etc.
Only use what you need. Reuse.
MyApplication.exe
Now what is Multi-threading exactly…
Multi-Threading is where a computer program spawns separate execution threads or (worker threads) in order to do “work”. What “work” is, is actually up to you as a programmer, but generally speaking, it can be simply defined for us in this presentation as – an operation that is time consuming, that needs to be done, but without interfering with the main execution of the application.
Some examples I can think of maybe, would be
Receive data from a web service, obviously, that takes time to connect and download data, so the question is - should the main application wait and become unresponsive?
Maybe Searching for files on the hard drive, that takes a lot of time
Intense calculation routines
Hardware IO monitoring, waiting for a CD to be inserted into a drive, for instance
UI Helpers, something like autocomplete maybe?
I think you get the picture.
The interesting thing about threads is that they share the same resources that the main thread does. This poses some interesting issues when utilizing multiple threads because it means that your functions can be called multiple times by different threads, at the same time. Although this sounds really cool, it is actually, the problem is that the state of the application may mean that it’s not a very good idea to multiply call that function, it can cause some chaotic scenarios. More about this later.
Usually, when a thread is currently “working” or when it has finally completed its “work” it needs to tell someone about it, more often than not, to simply report what it’s done – a good example of this is a progress bar.
I should also mention that you can create as many worker threads as you want, however, doing so not only becomes extremely complex to manage, but also, it saps the system resources very quickly and the machine can slow down dramatically. Although threads are very powerful, the overhead can be quite high, so be sure to only use what you need and be sure to reuse.
Thread 2
Thread 1
Spawn
Spawn
Main Execution Thread
Notify
Notify
Spawn
Thread 3
Notify
Resources

8. Multi-Threading and WPF
Rules of…
WPF works on the UI/Main Thread
Based on Windows Messaging, like MFC/Win32
Worker thread UI updates must be done on the UI/Main Thread
You cannot update WPF UI from a worker thread
You need to switch to the UI/Main thread.
With WPF, Winforms, MFC, and indeed all the way back to good old Win32, all UI updates must be done on the main thread. That’s because, even though you don’t directly access it using WPF and Winforms these days, they all utilize the good old Windows Messaging loop which was designed and implemented to run on the main thread. An interesting point to note while we are talking about it is that, if you want, you can still access the Windows Messaging loop using WPF to give you more control over what is going on.
Now, Worker threads cannot update UI directly. What I mean by this is that you can’t call any UI update functions from the worker thread. If you try to do it, it’ll either do nothing or throw an exception. If you want to update the UI from a worker thread, you have to somehow switch your update code to the main thread. Obviously, we’ll be talking about that in some detail later on.

9. Multi-Threading and WPF
Tools of the Job
WPF derives all controls from DispatcherObject
Allows easy invocation of code on the Main Thread.
MyControl.Dispatcher.BeingInvoke() – asynchronous
Allows you to set an update priority
MyControl.Dispatcher.Invoke() – synchronous
For UI lots of updates per second
Recommend using the DispatcherPriority.Background priority setting
Too many updates can cause the UI to become slow and/or jerky
Use a timer to know when you authorize an update
How you switch from your worker thread to the main thread in order to do WPF UI updates is easily done using the Dispatcher object.
All WPF controls implement the Dispatcher class. The Dispatcher is a .NET class which maintains a prioritized queue of “work” calls for a specific thread. In WPF’s case, that’s the main thread. What it allows you to do is to basically dispatch all of your UI update requests to back to the main UI thread, it’s very easy. This is done using the WPF control’s Dispatcher.BeingInvoke() or Dispatcher.Invoke() methods.
BeingInvoke() differs from Invoke(), in that BeginInvoke() allows you to schedule a call to your update function asynchronously, whereas, Invoke() posts the request and waits for it to be completed there and then. I think it’s best to use BeginInvoke() as much as possible because I like the underlying UI logic to decide when its best to update itself.
One thing that you need to be aware about is that your worker thread may be returning a lot of results; you have to be careful not to flood the main thread with UI updates, otherwise you’ll find that your UI will become jerky or even unresponsive. Basically, it’s a good idea to not over update the UI, make sure you schedule a sensible number of update calls to it, maybe once per second – usually that’s good enough… If you are not following what I am saying, then an example of what I mean is, say you spawn a new worker thread which counts from 1 to 1 billion and you want to report this progress to the UI. Obviously, the counter is going to increment extremely quickly - Does the user really need to see that updates a second are being done? I doubt that, I think the human eye only sees about 30 updates per second, so it’s probably best to only update the UI maybe every 1/3 of a second at most - that’ll keep the UI responsive and also make the calculations faster because you have less CPU cycles being used to update the UI unnecessarily. You can use a Timer object to do that.

10. Multi-Threading and WPF
Tools of the job - Timers
Timer classes .NET provides
System.Windows.Forms.Timer Runs on UI main thread only.
System.Timers.Timer  Runs on UI main thread, or worker thread
SynchronizingObject is not compatible with WPF
System.Threading.Timer Worker thread only.
All can be used fairly easily inside of WPF
I just mentioned timing the updates that you post to your Dispatcher. So just to continue quickly on that topic for a second as timers can be created as new worker threads…
.NET provides three types of timer object that you can use.
You have the original WinForms System.Windows.Forms.Timer class which only runs on the main UI thread. Indeed, thinking back to when I used to use WinForms, that is the same Timer object that comes inside of the WinForms UI toolbox in Visual Studio. The good thing about this timer is that anything you do in the timer callback will obviously work perfectly with the main app, because it’s all on the main thread – you can call this an old style Windows Message timer, because that’s basically what it is. The problem with this type of timer is that any significant processing that you do in the timer callback will affect the main threads performance, and thus the main program. Also, because this timer is run via the message loop, each timer notification is not necessarily timed to perfection – each notification can be delayed depending on the work being done by the main thread. Personally, I’d only use this type of timer for really simple notifications or variable updates.
Next you have a more up to date timer object which is hosted in the System.Timers namespace. This one is capable of running in both the UI thread or a worker thread, so it’s very versatile. If you run the worker thread version, then your timer notifications will usually be dot on the interval time that you requested. One point to note is that this particular timer object has a Synchronization object, which means that you can set the Synchronization object to a Control, then when the timer event fires the callback automatically switches to the Control’s thread. Unfortunately, this only works for WinForms, not WPF so it’s not much use.
Finally, the pure threaded version is the System.Threading.Timer class which also has very accurate timer notifications.
All three of these Timer classes can be used easily inside of WPF, my personal favorite is the System.Threading.Timer as it’s very powerful, accurate and super easy to use.

11. Multi-Threading and WPF
Tools of the job - Threading
Threading classes .NET provides
System.Threading.Thread class
Raw .NET threading class
I don’t recommend using this class in WPF
BackGroundWorker class
Neatly packages up multi threading to work with WPF
Perfect for use with WPF
Thread switching automatically taken care of
Switching from the worker thread to the main thread.
Moving onto the threading classes. There’s a couple to list.
First there’s the raw System.Threading.Thread class. This basically allows all the different scenarios you might need to create using threads. We will take a look at a simple example of this class in the demo shortly, however, for WPF programming, it’s simply not the one to use because it’s so raw.
The one to use is the BackGroundWorker class. This class provides everything you need to integrate worker threads into your WPF application. What I like about it is the very clean and logical way that you use the class… Once you spawn the new thread, you can easily post progress reports, notify a cancellation and then finally, also get notification when the thread has finished. What’s also really cool about this thread class is that, the thread switching is handled automatically by the call-back functions, so you don’t need to worry about switching from the worker thread to the main thread – just work as normal. Super cool, we’ll see that one a little later on.

12. Multi-Threading and WPF
Simple Example
Demo
“Simple Windows Application”
Demonstrating
Windows Application
Using threads
Providing Feedback while doing “work”
Now for a quick demonstration on the effects of doing “work” in a WPF application, and some simple solutions to the problem.

13. What about Multi-Threading inside AutoCAD
Is it possible?
AutoCAD is an Single Threaded Application
You cannot use worker threads to access any part of AutoCAD.
It will crash.
You may do none-AutoCAD related “work”
So what about using worker threads inside of AutoCAD?
Well, AutoCAD is, to this day, a single threaded application – that means that you can NEVER access any AutoCAD API from any other thread than the main UI thread. If you do so, you will probably end up crashing AutoCAD.
That said, it is totally possible to create multiple worker threads from your AutoCAD plugins, you just have to make sure that whatever the thread is doing, it has nothing to do with AutoCAD.

14. Multi-Threading and WPF
AutoCAD Ribbon Example
Demo
“AutoCAD Performance Monitor”
Demonstrating
CUI Custom Control
Using Timers
Using WPF Dispatcher
Using BackGroundWorker
Providing Feedback while doing “work”
My next demonstration will attempt to show how messaged or threaded timers and worker threads can really give a very nice UI user experience.

15. Multi-Threading WPF Inside of AutoCAD
Thank you…
Multi-Threading WPF Inside of AutoCAD
Fenton Webb
Senior Developer Evangelist