A concrete class: User settings Part 2

The second solution is the first that takes advantage of the System.Configuration namespace and also the first that will save user scoped settings between sessions. Writing a concrete class that inherits from the abstract class ApplicationSettingsBase allows you to easily create application and user scoped settings for your Revit commands. This is the same approach implemented in Visual Studio’s settings designer.

In the example Revit command, I’ve created a FormSettings class . For each property I want to use as a scoped setting I’ve added an attribute for either a application or a user scoped setting as well as the appropriate default values.  In the case of Application scoped settings you don’t need a set accessor because properties are readonly.

public class FormSettings : ApplicationSettingsBase

    {

        [UserScopedSettingAttribute()]

        [DefaultSettingValueAttribute("200, 200")]

        public Point Location

        {

            get { return (Point)(this["Location"]); }

            set { this["Location"] = value; }

        }

Remember to call the Save() method as required or subscribe to some of the ApplicationSettingsBase  events for more control.

What might seem strange when you run this is where the heck are the user settings stored? If you remember from part 1, all commands share the same AppDomain. Therefore, because Revit is the host application all user scoped configuration settings will be stored in the Autodesk Revit user.config file. Regardless of the path from where you host the command, or the namespaces of your commands. So for me on winXP this path is:

C:\Documents and Settings\Guy\Local Settings\Application Data\Autodesk,_Inc\DefaultDomain_Path_hdmtxhxelhauublfsbzroygotfgkvnt3\20081118_1045\user.config

Notice because Revit doesn’t utilise .NET configurations itself .NET has automatically created the path based on the AppDomain and the version of Revit.

For some utilising ApplicationSettingsBase will be more than enough. It’s certainly easy to implement. But what if you wanted to do one or more of the following?

• Share settings across disciplines for your API command.
• Store the application scoped settings in the API command’s own config file on the network for ease of editing?
• Easily utilise the powerful and useful ConfigurationSection and ConfigurationSectionCollection classes from the System.Configuration namespace.
• Allow commands to update the Application scope settings if the user has the authority.

In other words have all the power of scoped settings available at the application level on a per Revit API command basis. Well this is all possible with a little more work and understanding. And this is what I’ll cover in the next post in the series.

The sample project and assembly for part 2 is at the usual place here.