COM and Automation Threading Considerations

The following Tablet PC threading considerations are specific to when Component Object Model (COM) and Automation are used.

Thread Safety

Except for the InkPicture and InkEdit controls, Tablet PC objects are thread-safe and are marked as both. By being marked as both, they can run in either a single threaded apartment (STA) or a multithreaded apartment (MTA).

Windows forms use the STA model because windows forms are based on native Win32 windows that are inherently apartment threaded.

STA and MTA Applications

If your application runs in an MTA or uses the free threaded marshaler (FTM), you must write thread-safe code; however, by doing so you can improve certain event handling performance issues.

InkCollector and InkOverlay

Your application should not release its final reference to the InkCollector or the InkOverlay object, thus destroying the object, directly from the ink thread. Instead, the application should release the InkCollector or the InkOverlay object from an application thread.

Caution: An application that is marked MTA or uses the FTM, which allows direct calls from the ink thread into the application's apartment, can release its final reference to the InkCollector or InkOverlay object directly from the ink thread; however, this causes unrecoverable application failure.

Event Sinks

If your application is not using the FTM and an object and its event sink are created in different apartments, then the event executes on the thread servicing the event sink.

Exceptions within Event Handlers

Exceptions thrown from within Tablet PC event handlers are consumed and are not visible to the rest or your application. Likewise, HRESULT values are not propagated from Tablet PC event handlers. If an application using the COM layer throws an exception, the background thread terminates, and the exception will be lost. No additional event handlers will be called.

C++ Event Sinks Sample

General Threading Considerations

Managed Library Threading Considerations