InfoPath: the multi-threading challenge

Question

Or to be more specific: calling a DataSource from a different thread.
A project I'm working on includes an InfoPath form in which some heavy duty tasks are executed. These tasks can take over 10+ seconds to execute. To avoid the GUI to get stuck during execution, multi-threading is implemented. The problem lies in providing
feedback to the user. Several methods have been used, but all end in the exceptions shown below.
Unlike WinForms and such, InfoPath does not seem to provide a way to invoke the GUI. What we are trying to do is change field values to reflect the status of the process. This is done through the MainDataSource. I've tried several methods to call
this datasource through another thread, like invoking a provided delegate, or execution context. However all these methods have similar results.
When calling a method or property on the datasource the following exception is thrown:
System.InvalidOperationException was unhandled
  Message="Operation is not valid due to the current state of the object."
  Source="Microsoft.Office.InfoPath.Client.Internal.Host"
  StackTrace:
       at Microsoft.Office.Interop.InfoPath.SemiTrust.ICLRExtensionsWrapper.IncrementSqmPoint(Int32 idDataPt)
       at Microsoft.Office.InfoPath.Internal.DataSourceHost.CreateNavigator()
       at Form1.FormCode.ContextCallbackMethod(Object obj) in E:\Projects\InfoPath Multithreading\Source\Form1\FormCode.cs:line 74
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at Form1.FormCode.ThreadMethod(Object myParamsObj) in E:\Projects\InfoPath Multithreading\Source\Form1\FormCode.cs:line 68
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart(Object obj)
This seems to indicate the DataSource is locked for some reason. Even the ReadOnly property can not be read.
When calling the SetValue method on an XPathNavigator provided by a datasource and passed through another thread, the following exception is thrown:
System.AccessViolationException was unhandled
  Message="Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
  Source="Microsoft.Office.InfoPath.Client.Internal.Host.Interop"
  StackTrace:
       at Microsoft.MsoOffice.InfoPath.MsxmlInterop.NativeHelpers.SetText(IXMLDOMNode* , Char* )
       at Microsoft.MsoOffice.InfoPath.MsxmlInterop.MsxmlNodeImpl.set_Text(String strText)
       at Microsoft.Office.InfoPath.MsxmlNavigator.SetValue(String value)
       at Form1.FormCode.DelegateMethod(XPathNavigator nav) in E:\Projects\InfoPath Multithreading\Source\Form1\FormCode.cs:line 81
       at Form1.FormCode.ThreadMethod(Object myParamsObj) in E:\Projects\InfoPath Multithreading\Source\Form1\FormCode.cs:line 70
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart(Object obj)
I have searched through the internet but am unable to find any useful information about this subject. There are only a few weeks remaining before the deadline. A work-around has been implemented, but since it requires additional active user interaction
it is far from ideal. I hope you can help me in finding a solution.

Answer 1

For anyone who is still interested all this time later....
I wouldn't use a Dispatcher in InfoPath simply because InfoPath requires .Net 2.0 only and Dispatcher was not added until .Net 3.0 which means you would have to enforce installation of .Net 3.0 yourself.
There is an easy alternative which is SynchronizationContext (more specifically a WindowsFormsSynchronizationContext).
Also I suggest you do not use ThreadStart but rather use one of the more modern and well known threading paradigms. A good alternative is a BackgroundWorker.
e.g.
private BackgroundWorker _Worker;
public void InternalStartup()
InitializeWorker();
((ButtonEvent)EventManager.ControlEvents["Button"]).Clicked += new ClickedEventHandler(ButtonClick);
public void InitializeWorker()
_Worker = new BackgroundWorker();
_Worker.WorkerReportsProgress = true;
_Rorker.WorkerSupportsCancellation = true;
_Worker.DoWork += new DoWorkEventHandler(_Worker_DoWork);
_Worker.ProgressChanged += new ProgressChangedEventHandler(_Worker_ProgressChanged);
_Worker.RunWorkerCompleted += new RunWorkerCompletedEventHandler(_Worker_RunWorkerCompleted);
public void ButtonClick(object sender, ClickedEventArgs e)
if (_Worker.IsBusy)
_Worker.CancelAsync();
else
// Very important to include this line!
AsyncOperationManager.SynchronizationContext = new WindowsFormsSynchronizationContext();
_Worker.RunWorkerAsync();
void _Worker_DoWork(object sender, DoWorkEventArgs e)
// Do stuff in another thread and report back to the UI thread.
object state;
int percentage = 0;
_Worker.ReportProgress(percentage, state).
public void _Worker_ProgressChanged(object sender, ProgressChangedEventArgs e)
// This is called on the thread that started the worker.
// In this case the UI thread which means it is safe to use the MainDataSource.
CreateNavigator().SelectSingleNode("my:Main/my:Progress", NamespaceManager).SetValue(e.ProgressPercentage);
void _Worker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
// Do anything you want to do on completion here.
One thing of note is that the SynchronizationContext in InfoPath for some reason or other always seems to be Null. The result is that when you call RunWorkerAsync() it captures the current synchronization context (null) which means the default is used and
a ProgressChanged is called on a new thread each time. To prevent this we need to manually set the context before calling RunWorkerAsync() which is done using the AsyncOperationManager.