Save settings in a configuration file - for Preferences/Options/Settings box

• Download demo project - 8.84 Kb
• Download source - 7.89 Kb

Introduction

This article (and a module along with it) helps you to save the information in most controls in a Form, to a file (or registry with slight tweaking), and load them whenever.

Background

A little information on how to use files and hash tables might help, but is not necessary.

Using the code

The code that accompanies demonstrates how to use the module to save the controls in a form. Typically, I have a TextBox, CommandButton, Label, OptionBox, and RadioButton in a form, and clicking Save/Load does the same.

This is done using recursion - thus, you save the parent control, and the recursive method calls its children and saves them all too. Similar fashion can be extended for the loading process.

Let's say we have a Form with a TextBox T, a GroupBox GB and option buttons (OB1, OB2,..) inside GB. You can also use the Tab control to provide the interface seen in Internet Explorer Options toolbox. So, to save these controls, we just use the following method:

SaveSettings(Me,"settings.set")

SaveSettings calls SaveControls recursively, and saves each control based on their signature (control.GetType.toString) to the given file.

Sub SaveControls(ByVal cnt1 As Control)
    '.....Recursive call....
End Sub

Saving is done using a generic function called RSet(setting as String, value as String). The beauty of this method is that it can be extended later to suit your purpose: maybe you want to use the registry (refer below for a comparison), instead of files, and so just replace file methods with GetSetting etc. You can also use various API / .NET calls to provide alternate versions too. Thus, it's a template that can be extended.

Loading is similar in process, but as we read the properties from the file, we have to trace them back to the control they belong to.

For e.g.,

Text1
This is a text
Opt1
1
Opt2
0

Thus, we are faced with the challenge of searching through all the controls, and matching it against the one currently read. This is inefficient, since it is a O(n^2) algorithm - which can deteriorate if you try with a Form with 100 or so controls...

A little more thought takes us to the almost optimal solution: .NET's HashTable. This is amortized constant (i.e., usually retrieves the value within one step or so) algorithm, and hence well optimized.

So, LoadSettings first builds a hash table based on the control's signature - namely its Name property.

Dim myHashes As Hashtable
Sub BuildHashTable(ByVal myControl As Control, _
           Optional ByVal isInit As Boolean = True) 

    '.....Hash is built here.....

End Sub

Now, we can use the GetType.toString to know the type (e.g., "System.Windows.Forms.TextBox") and follow the appropriate steps to retrieve the value.

Points of Interest

I have modularized the methods to read/write a file, using my own methods - if you want, you can change them to use the registry using, say, GetSetting and SaveSetting methods in .NET. Remember, if you are using registry, then GetSetting will work only if the setting is already there - in which case, you have to read the controls first, and then use that signature to read from the registry.

Registry/File:

File is flat file organized, and cannot be shared (readers/writers problem), whereas the registry is a database and simultaneous reading / writing is taken care by Windows. But, this shouldn't discourage file usage, since only multiple processes reading the same file should cause a problem - which is a rarity.

File is easier to delete in case of uninstallers, whereas, Registry requires lots of underlying work to delete (even if you don't, Windows doesn't).

File usage allows you to understand the settings without much ado, (like going through regedit and finding the settings...). But, beware that the settings themselves are not per user - which is easily possible using Registry.

The rest of the issues lies upon you.

I used this settings saver/loader extensively to use a Options dialog box. And all I need to do was call a method - that's it. However, I did need to handle the changes in the controls - using events. Thus, it saved me tons of lines of code that I should have written.

The source shows a simple demo.

I haven't tried ListBox/ComboBox, since I haven't felt the need. But doing so is fairly easy - using the SelectedItems.Index property of that control.

Issues:

Sometimes, you might delete some controls/add new ones to the Form. In which case, the file doesn't correspond to the updated Forms. However, the loading of such a file will not cause problems, since the hash for that control won't exist (if the control is deleted) and will just proceed.