Reply to thread

There are different layers to handle this. I try to summarize it here, we don't have minimum example yet.

1. Settings

First there are settings classes, which are plain C# classes where properties can be decorated with Settings attribute. Example

There are 2 settings scopes:

• "User" affects only the currently logged in user (we do have multi-user support in MP2)
• "Global" affects whole system

Accessing settings from code is easy, just like here. It's done by SettingsManager.Load<T> call.

2. Configuration

Settings alone don't have any UI to control them. This happens first, when you add Configuration classes and registration to your plugin. This is done inside the plugin.xml, like here.

The first two tags like <Register Location="/Configuration/Settings"> ..</Register> define the hierarchy in the configuration plugin, where your config items will be displayed. We are using one common generic configuration plugin.

Then there are the actual configuration classes: MediaPortal/MediaPortal-2. They have a localized name and important a ClassName which is dynamically invoked by configuration plugin.

For each config item there is a small class which deals with load / save of the changes. All of them derive from basic classes for text input, number input or similar. MediaPortal/MediaPortal-2

3. Accessing Settings from UI

The UI is defined in XAML and from there you can bind to Models. If you like to expose a setting's value to UI, you define Properties in the Model classes.

Here one example: MediaPortal/MediaPortal-2

Rules:

1. Always use WProperty classes inside Models. They deal with WeakReferences to allow early release of resources.
2. Only exception to use SProperties are XAML controls. They are using Strong references which keep alive longer/for application runtime.