If you attempt to use an ArcGIS Explorer object on a different thread to the one on which it was created, a ThreadingException is thrown.

ArcGIS Explorer objects are not thread-safe and are bound to a specific thread. If you find this exception is thrown, you should review your code, paying particular attention to class level variables of ArcGIS Explorer types that may be used in multiple functions, or references to ArcGIS Explorer types which are passed around between multiple functions; in both cases, check if the same object is used on different threads. There are many situations where .NET code may be called on different threads, for example:

• Using the ESRI.ArcGISExplorer.Threading.BackgroundWorker to do work on a worker thread in Explorer.
• Creating new threads using the System.Threading.Thread class, part of the .NET Framework.
• Using the .NET thread pool, System.Threading.ThreadPool.
• Using asynchronous delegates, which makes use of the standard .NET thread pool to call the delegate on a different thread.
• Using Windows Workflow Foundation classes which in turn make use of the .NET thread pool.
• Using the WebClient class which may raise the DownloadCompleted event on a worker thread.

You can use the ManagedThreadId property on the System.Threading.Thread.CurrentThread class, part of the .NET Framework, in order to check the ID of the thread upon which code is called.

In order to run code which accesses any ArcGIS Explorer objects on a different thread to the main user interface thread, the correct pattern is to make use of the ArcGIS Explorer ESRI.ArcGISExplorer.Threading.BackgroundWorker class by serializing ArcGIS Explorer objects and passing this state information to the BackgroundWorker, then deserializing the object on the worker thread. In this pattern the different threads are actually using different instances of a class; for more information see the BackgroundWorker class for more information.