Using the ASCOM Settings Provider to manage your driver's settings more effectively

Tags: ASCOM, astronomy, software-engineering, development, howto, tutorial

Many developers seem to be completely unaware of the powerful tools that exist for managing application settings within Visual Studio. Features such as the Settings editor and the ability to bind settings directly to controls on forms, together with Visual Studio's code generation of a strongly-typed settings class make this a compelling way to create and manage application settings. Often, it is possible to completely manage an application's settings in just two or three lines of code.

The default situation with ASCOM drivers is that settings code is written by hand. The following tasks have to be performed:

  • When the driver loads, retrieve each settings from the profile store, convert it to the correct type and put it into a field or property of the driver class. (One or more line of code per setting).
  • When the settings need to be saved, convert each property and field to a string and write it to the ASCOM profile store (one or more line of code per setting).
  • When the SetupDialog is opened, copy the current settings values from fields on the driver class and set the current value of each control. (One or more line of code per form control)
  • When the SetupDialog OK button is clicked, retrieve the value of each control, convert it to the correct type and store it into the corresponding field/property of the driver.(one or more line of code per form control).

There is a lot that can go wrong with all that code. Every time a setting is added or changed, code needs to be updated in four separate places. The setting names have to match up, type conversions need to be done to and from strings. In a large driver there can easily be 20 or 30 settings and it all adds up to a lot of unnecessary code and a violation of the Single Responsibility Principle (any class should only have a single reason to change).

Surely it is better to use Visual Studio's built in Application Settings Architecture, and let it do all the heavy lifting? The ASCOM.SettingsProvider provides the 'glue logic' that makes that possible. It is built into the ASCOM Platform, so there is nothing to install - but unfortunately the default project templates don't use it by default - so there are a couple of simple steps required to make it all work. This video is a short walk-through of the steps needed.

No Comments

Add a Comment

Let Us Help You

Find us on Facebook