CODEWITHSUNDEEP
c#.netwpfplugins
erotavlas
erotavlas

Reputation: 4475

Exposing the configurable properties of a plug in to a GUI

Referring back to this post

https://stackoverflow.com/a/9874735/1462656

I was thinking doing something similar, make all my plug ins expose the configurable proerties using an interface that contains a dictionary of property names and value pairs.

However my problem is how do you group properties together, or how do you have separate collection of properties that may each represent different settings.

For example say I have an application that user can plug in different processors. Each processor will behave entirely different from each other.

Processor 1 has these settings

<Target location="1" action="dosomething" option="4">
<Target location="2" action="dosomething" option="4">
...and so on

This I could probably represent using a collection of Dictionaries Maybe something like 

List<Dictionary<string,string>>

But say I have Processor 2 with entirely different settings

<Key persist="true">
    <ValueFrom location="1" />
    <ValueFrom location="4" />
    <ValueFrom location="7" />
</Key>

I don't see how in the original post I link above I can represent all configurable items in a simple Dictionary. Unless I represent each sublevel by a different key? Would it still work?

Also if you did have a hierarchy of settings, how do you tell the GUI about this so it can create the appropriate controls to display it?

Upvotes: 0

Views: 66

Answers (1)

Justin Ryan
Justin Ryan

Reputation: 1404

When I did something similar recently, the most important question (I think) that I asked myself was, does the host application (the GUI in your case) need access to view or modify the plugin settings?

In my case the answer was, no, and so I could forget all about the details of what data or how each plugin stores it, and simply provide a container for it to be stored. The plugin's properties are retrieved As Object, serialized, stored, or whatever else I need to do with them, then sent back to the plugin upon the next instantiation. It is entirely up to the plugin to decide which properties to store, how to store them (variable, class, etc..), and to subsequently do the conversion from Object when receiving its properties.

How you allow the user to change those properties is a factor of how 'pretty' you want things to be, but in my situation I opted for a PropertyGrid (mine was a WinForms project). This way the plugin could expose each property exactly how it chooses, complete with descriptions, help text, and TypeConverters. Granted that it's not the most attractive interface, but in terms of prepackaged 'completeness' it is quite powerful.

Upvotes: 1

Related Questions