Is asynchronous events from COM server allowed/recommended RRS feed

  • Question

  • I'm developing a COM class exposing a connection point for event notifications to the client. In my .Net test application I noticed that the events where received on a non-GUI thread (since I'm using a worker thread on the server) causing threading exceptions when modifying the GUI directly in the delegate.

    I ran into brick when trying to solve this in the COM server. See Marshalling interface pointer between two STA apartments.

    I'm now considering solving this problem in the client using ISynchronizeInvoke.

    My question is whether this architecture is allowed/recommended. From the client perspective there is no way to anticipate that events will be fired from another thread, besides reading the interface documentation.

    The SerialPort.DataReceived Event of the System.IO.Ports.SerialPort class for example suffer from this behavior:

    "The DataReceived event is raised on a secondary thread when data is received from the SerialPort object. Because this event is raised on a secondary thread, and not the main thread, attempting to modify some elements in the main thread, such as UI elements, could raise a threading exception. If it is necessary to modify elements in the main Form or Control, post change requests back using Invoke, which will do the work on the proper thread."

    • Moved by Helen Zhao Friday, June 15, 2012 8:43 AM (From:Visual C++ MFC and ATL)
    Thursday, June 14, 2012 8:53 AM

All replies

  • Posted in wrong forum. Could someone move to .Net forum!
    Thursday, June 14, 2012 8:56 AM
  • Hi Sanctus79,

    I am moving this thread to Common Language Runtion forum for better support, where more experts live.

    Thanks for your understanding and active participation in the MSDN Forum.
    Best regards,

    Helen Zhao [MSFT]
    MSDN Community Support | Feedback to us

    Friday, June 15, 2012 8:42 AM