Net for (VO) Application Developers

Application and User settings = in the .NET Framework.

= ;A wo= rd of warning first, the proofreaders of this article have told me that by readi= ng the title and intro they did not find it interesting at first. One by one = they found out the valuable lessons to be learned. So please read it, maybe even twice, just to be sure you get it all.

Disclaimer: Reading this Article might even result in a liking of Vulcan.net and the .net framework. You are reading t= his out of your own free will, nobody is forcing you to.

One = of the strong points of the .Net Framework to me is the enormous amount of functionality developers need = that is already built-in and readily available to us. As a rule of thumb you sh= ould always try to find what you need first, it is probably already in there in= the framework in one way or the other. The difficulty is actually finding it. = So research (msdn, gotdotnet, sdn) and= ask around. Recently I noticed an article by Duncan Mackenzie in msdn maga= zine (April 2005) about storing application and user settings. Because I’m writing some .net samples for Vulcan.net this seemed like an excellent exa= mple to implement. Every VO developer will have to deal with settings in one wa= y or another. There are various forms of settings that have to be implemented, application specific ones such as a license key or a connection string. Se= ttings like this will typically be configured during installation or by an administrator. And then there are user settings that have to be stored separately for every single user and usually can be changed and saved by t= he user. Examples are a language setting the position of forms and colours or the recently viewed documents= or orders.

This all must sound familiar; we probably all have build classes that deal with these issues e= ither by using Ini-file= s, the registry or storing them in a database. The good news is that Windows = has built-in solutions for all of this and the .net framework provides us with= a constituent programmer friendly API to start using them.=

AppSettings

First off de non-user specific settings, these settings are stored by the .net framework classes= in a special configuration file that has the default name App.config. When you add a file like that to your Visual Studio project it tak= es care of copying it to the .Exe directory and renames it to <ExeFileName>.Exe.Config. You= can than access the properties you’ve put in using the ConfigurationSetttings.AppSettings class. =

The integration/deploym= ent is not available for Vulcan.net yet but we can start using this class for reading settings.

Reading I hear you say?= Yes reading only, the AppSettings clas= s is read-only by design. There are no methods to write to it in the Class. As = noted earlier the AppSettings are = to be maintained by an application manager or install routine. Normally the users wouldn’t even have rights to edit/write to that file because it woul= d be located in the “Program Files” branch so it makes no sense to support that. This is good obviously because when multiple users use the same computer they would get= the settings of the previous user, so for Application specific settings this i= s a good solution, but it is not for user-specific ones.

3D"VONET_ed1.jpg"

Figure 1, Configuration file in Visual Studio

The following Vulcan.net code reads the value for the key called “Database” (see above picture):

REFERENCES 'System'
USING System.Configuration=

Function Start as void
LOCAL cDatabase as string
:=3D ConfigurationSettings.AppSettings:Get("Database")
? cDatabase
Return

(sample code: AppSettings.prg)=

Simple enough, de AppSettings class loads the content of the XML file into a so called NameValueCollection which has a Get-method that accepts a key name and returns the corresponding value. Although this collection also has a set method, the <= /span>AppSettings class does not have a Save method because of reasons earlier descri= bed. Optionally we can also use the AppSettingsReader clas= s.=

UserSettings

Now for the more exciti= ng part; Object Oriented as we all are and think nowadays we find it natural = and normal to use classes to define our structures and objects to hold on to d= ata in memory but persisting this data to disc is often still done the traditi= onal way translating and saving to Ini- fil= es, the registry or even XML. The latter for obvious reasons; The ability to validate the content and exchange or interface reliably = with other systems. When we do that using an XML-parser such as MS-XML we often write quite a lot of code to do that. The .net framework takes that away a= lmost completely and leaves us with a lot lesser code to maintain!=

XML = Serialisation

The XmlSerializer class uses the Type information= a cl= ass contains to produce the appropriate XML for us, which we can in turn write= to disc using a StreamWriter obje= ct, resulting in a valid XML file in this case.

The following code samp= le which puts this all to practice should be self-explanatory based on the in= fo just provided:

REFERENCES 'System.Xml'
USING System.Xml=

Function Start AS VOID
LOCAL oUser AS UserSettings
LOCAL oS AS Serialization.XmlSerial= izer
LOCAL oW AS System.IO.StreamWriter<= /span>=

// Create object holding settings
:=3D UserSettings{}

// Store a value
:=3D "Ed Richard"<= /span>

// Create an XmlSerialize= r object based on the typeinfo of oUser
:=3D Serialization.XmlSerializer{oUser:GetType()}

// Create a StreamWriter= and pass that to the Serialize method.
:=3D System.IO.StreamWriter{"User.xml"}

// Can also use Text or XmlWriter here.
(oW, oUser)
()

Return=

// User settings class

CLASS UserSettings
&nb= sp; EXPORT <= span style=3D'font-size:10.0pt;mso-bidi-font-size:11.0pt;font-family:"Arial","s= ans-serif"; mso-fareast-font-family:"Times New Roman";color:navy;mso-font-kerning:18.0= pt; mso-bidi-font-weight:bold'>MyName AS STRING=

Below is the result whe= n the file is opened using Visual Studio. Isn’t that cool? Just with a few lines of code and almost no maintenance. Just add more properties to the <= /span>UserSettings class and everything will automatically work.

3D"VONET_ed2.jpg"

Figure 2, The XML returned for UserSettings class

Readi= ng , or de-serializing from a file into an object is just as easy, we ju= st need to cast the return type of the DeSer= ialize meth= od to an object of our UserSettings clas= s. Check out the code:

REFERENCES 'System.Xml'
REFERENCES 'System.Windows.Forms' // MessageBox=

USING System.Windows.Forms
USING System.Xml=

Function Start AS VOID

LOCAL oUser AS UserSettings
LOCAL oS AS Serialization.XmlSerial= izer
LOCAL oR AS System.IO.StreamReader<= /span>=

oUser= :=3D UserSettings{}

oS :=3D Serialization.XmlSerializer{oUser:GetType()}

oR :=3D System.IO.StreamReader{"User.xml"}

// Cast return value (object) to UserSetting<= /span> object
:=3D (UserSettings) oS:Deserialize(oR=

MessageBox.S= how(oUser:MyName)
()
Return

As you can tell from the code, Vulcan.net support a different syntax as VO-32 but does still suppor= t the VO way for the built-in types like INT, DWORD etc. But in this case we are using our own type (UserSettings) so = we need to specify this “the Vulcan way” using a conversion opera= tor (the type name in brackets). You can read all about this in the Help that = comes with Vulcan.net.

To a hard drive, sure but where exactly to we store the file?

Now that we have foun= d a simple way to save our data in an XML file, the next challenge is where to= save it. Modern Windows versions like XP and Vista provides us with multiple go= od alternatives for this and for sure the .net framework supports easy ways to make use of that.

The Application Class h= as various interesting properties just for this purpose;=

Application.UserAp= pDataPath returns a path which points to = application data location for the currently logged on user. When we use that, our data will get stored wherever the users profile= is being stored. This allows us to support roaming profiles where this information is stored centrally on a server and users can use any wor= kstation they like. This is a perfect place for our user settings. The path al= so contains a product name= and version which is generated based on the version resource in the executable. Even if you don’t put one in, it will use the one t= hat comes from the Vulcan.net runtime.&n= bsp; Here’s an example of that path: =

3D"VONET_ed3.jpg"

Figure 3, Application data path

Application.LocalU= serDatapath= is always on the local workstation but again user/product/version specif= ic. =

Another important prope= rty of the Application class is CurrentCulture,<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";mso-fareast-fon= t-family: "Times New Roman";mso-font-kerning:18.0pt;mso-bidi-font-weight:bold'> this holds a reference to a CultureInfo obje= ct where you can find the current language, date format and other regional settings.

The .net framework also= has the Environment class, which has a more generic GetFo= lderPath meth= od to get access to the various system folders like= My Document, My Pictures etcetera. It can also be used to find out about UserName, MachineName, OS Version and some other interesting data you might need in this context.=

As an example we choose= UserAppDataPath, and to merge that with a filename we will use yet another practical .net class, the Path class. This class provides practical and safe ways to= work with paths and filenames. The location is appropriate because users will a= lways have access rights to this location. The actual writing will look something like this:

cFile= :=3D System.IO.Path.Combine( Application.UserAppDataPath, "User.xml" )
:=3D System.IO.StreamWriter{cFile}

Yet another way to store user information= that Duncan mentions in his article is Isolated Storage. This is a specific .ne= t way to store data that is a lot safer in terms of security. You can then have = an application that doesn’t even have write-rights on your file system = but still can store their data in their own specific sandboxed storage area. T= his is appropriate for example when the user is starting your application from the Internet. The class you would ne= ed in this case is called IsolatedStorageFile.=

All i= n all a lot of very flexible ways to store settings with just a few lines of cod= e. I wo= nder how much code in your old toolbox you can write off just by moving to these .net classes? All you have to do is decide when and where to store your data.

So what have we learned= from this article?

How .net uses configuration files, how to create them and where to save them. Dat je er van uit moet gaan dat bijna alles al aanwezig is in het .Net Framework.
That you can reduce your own code base seriously when moving to .net. =
That it is very rewarding when you analyse= your own code and module by module see which .net framework classes could replace your own code. =
That this will give you more time to spend= on actual application code. =
How easy it is to persist object to files. = =
Security and permissions are going to play= an important role in application we write and its about time we sta= rt taking that into account (which is often automatic when using .net classes).
How to access type info en convert to typ= es in Vulcan.net.
That when you have rights you can read and write configuration files using Notepad.Exe. =
That reading .net articles not specific for Vulcan.net will help you out tremendously. =
That .net is a giant step ahead, even for Visual Objects developers. =

Ed Richard ( Ed@SoftwareObjectives.com.au )

Software Objectives
Australia