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.
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
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
GB and option buttons (
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:
SaveControls recursively, and saves each control based on their signature (
control.GetType.toString) to the given file.
Sub SaveControls(ByVal cnt1 As Control)
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.
This is a text
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.
LoadSettings first builds a hash table based on the control's signature - namely its
Dim myHashes As Hashtable
Sub BuildHashTable(ByVal myControl As Control, _
Optional ByVal isInit As Boolean = True)
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,
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.
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
ComboBox, since I haven't felt the need. But doing so is fairly easy - using the
SelectedItems.Index property of that control.
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.