Managed Library Threading Considerations
Managed Library Threading Considerations |
Description of managed library threading considerations.
The following Tablet PC threading considerations are specific to when the Managed Library is used.
Thread-Safety
The Tablet PC Platform's Managed Library classes are not generally thread-safe. The following collections are thread-safe at the member level. However, these collections do not guarantee that an enumerator is protected if another thread operates on the collection simultaneously:
STA and MTA Applications
Managed applications created by using the wizards contained in Microsoft® Visual Studio® .NET are single-threaded apartment (STA) by default. You can change the apartment for your application by setting the STA thread or multithreaded apartment (MTA) thread attribute on the entry point of your application.
If your application runs in an MTA, you must write thread-safe code; however, by doing so you can improve certain event handling performance issues.
For more information about the STA thread and MTA thread attributes, see STAThreadAttribute class .gif)
and MTAThreadAttribute Class .
Windows Forms Threading Considerations
The InkPicture and InkEdit controls extend Windows Forms controls. Windows Forms controls use the single-threaded apartment (STA) model because Windows Forms are based on native Win32 windows that are inherently single threaded.
In managed code, ink controls should be created in the same thread as the main thread for the form. For more information about threads in ink controls, see Ink Controls.
In an STA application, certain events happen on a thread other than the application's user interface (UI) thread. When calling any Windows Forms object or control, including the InkPicture and InkEdit controls, from within a Tablet PC event handler, use the object or control's inherited Invoke method.
If you put a UserControl onto a Web page in a browser (see Web Controls), then it runs as an STA application. For smart client applications (see No-Touch Deployment), the developer has full control over the ApartmentState . (The default is generally STA, but may be MTA, depending on your version of CLR.) For threading issues involving the RealTimeStylus, see Threading Considerations for the StylusInput APIs.
For more information about calling Windows Forms from an MTA application, see Multithreaded Windows Forms Control Sample .
Clipboard Considerations
The Clipboard object works only from an STA thread. When trying to copy to or paste from the Clipboard from a thread that is not STA, you get a ThreadStateException . If your application is MTA, create an STA thread to handle the Clipboard's method calls and some of the other UI aspects of your application.
Exceptions within Event Handlers
Exceptions cannot be thrown from within Tablet PC event handlers. For example, if an event handler delegate for a Tablet PC object or collection has three registered handlers and the first one throws an exception, then the following sequence occurs:
- The first handler exits.
- The exception is lost.
- The remaining handlers are not invoked.
Disposing Objects and Controls
To avoid a memory leak you must explicitly call the Dispose() method on any Tablet PC object or control to which an event handler has been attached before the object or control goes out of scope.
To improve performance in your application, manually dispose of any Tablet PC object or control that implements the Dispose() method when the object or control is no longer needed.
StylusInput APIs
For information about threading considerations for the RealTimeStylus object and the StylusInput application programming interfaces (APIs), see Threading Considerations for the StylusInput APIs.