Question

I wrote an application in WPF / VB and separated the business logic and UI into different projects.

The business layer uses a serial port which runs on a different thread, Now that I’m trying to write a command line interface for the same business layer, it seems to fail when .Invoke() is called. (no error, just doesn’t work)

I’m pretty sure the reason I had to add in checkaccess and .invoke was because I have collections that would be changed during processing the serial port data and wanted the NotifyCollectionChanged to be handled by WPF data binding.
(The reason I’m not 100% sure is because it was months ago I wrote that part and it all worked great from the GUI, now adding the console app has made me rethink some of this)

I would like my business layer to run these processes on the thread they were created, I need this to work from both my GUI version and the command line version.

Am I misusing the Dispatcher in my business layer? Is there a better way to handle an event from the serial port, and then return to the main thread to processes the data?

Updated:

Private Delegate Sub NewDataRecieved(ByVal byteBuffer() As Byte)
Private Sub DataReceived(ByVal byteBuffer() As Byte) Handles _serial.DataRecieved
    If _dispatcher.CheckAccess() Then
        ProcessTheData
    Else
        Dim dataReceivedDelegate As NewDataRecieved
        dataReceivedDelegate = New NewDataRecieved(AddressOf DataReceived)
        _dispatcher.Invoke(System.Windows.Threading.DispatcherPriority.Normal, dataReceivedDelegate, byteBuffer)
    End If
End Sub

Answer 1

Invoke doesn’t do anything because you don’t have a dispatcher running, to get any services from a dispatcher you have to call Dispatcher.Run ( http://msdn.microsoft.com/en-us/library/system.windows.threading.dispatcher.run.aspx )

Now, your problem is that calling Dispatcher.Run will make WPF take control of the thread – and that is probably not what you want to do in a console application.

I think the best option in your situation is to remove the thread synchronization code (anything that talks to a dispatcher) from your business layer and into wrapper objects.

The WPF app can continue to work as before by using the wrapper objects and the console app can use the “raw” business layer directly.

Update: here is an example of the wrapper below, you have to create a method/property for every public member of the original class that does the threading work and calls the original object.

public class BOWrapper : INotifyPropertyChanged
{
    private BO _bo;
    private Dispather _dispather;

    public BOWrapper(BO bo, Dispatcher dispather)
    {
        _bo = bo;
        _dispather = dispather;
        _bo.PropertyChanged += BOPropertyChanged;
    }

    public string SomeValue
    {
        get { return _bo.SomeValue; }
    }

    private void BOPropertyChanged(object sender, PropertyChangedEventArgs ea)
    {
        _dispatcher.Invoke(
            new Action<PropertyChangedEventArgs>(
                e=>
                {
                    var handler = PropertyChanged;
                    if(handler!=null) handler(this,e);
                }),ea);
    }
}

The wrapper class is 100% boilerplate code and you probably can use some code generator to create it, maybe even use something like DynamicProxy ( http://www.castleproject.org/dynamicproxy/index.html ) to generate it automatically at runtime.