-
Notifications
You must be signed in to change notification settings - Fork 51
Data Container API
One of the basic building blocks used through Concord is the Data Container API. This API is implemented in the DkmDataContainer class and a few other related types. The basic idea of the data container API is to allow ‘virtual fields’ to be added to all the important objects. This is similar to the 'expando' concept JavaScript, though it doesn’t have the same type safety or namespace pollution problems that JavaScript expandos have.
The API works by having components add ‘data items’ to a data container object. The caller can then obtain the data item back when they need to. Thus the implementation class for a Concord component is usually has little state, and instead uses the data container objects to do the work of holding onto the state. This ensures that state is uniformly cleaned up across Concord rather than having a situation where each component is responsible for finding an appropriate place to clean up their state. For this reason, components generally do not need to remove their data items but can rather just wait for the data items to be automatically removed when the container object is closed. More information on this subject is in the Hello World sample as well as in the API documentation.
Concord Documentation:
- Overview
- Visual Studio 2022 support
- Concord Architecture
- Getting troubleshooting logs
- Tips for debugging extensions
- Component Discovery and Configuration
- Component Levels
- Navigating the Concord API
- Obtaining the Concord API headers, libraries, etc
- Concord Threading Model
- Data Container API
- Creating and Closing Objects
- Expression Evaluators (EEs)
- .NET language EEs
- Native language EEs
- Installing Extensions
- Cross Platform and VS Code scenarios:
- Implementing components in native code:
- Worker Process Remoting
Samples: