Just about every FoxPro application has a need to store settings. Whether it be the startup folder or various application preferences, they have to be stored somewhere. Of course, that begs the question "where"?
Back in the DOS days, many developers stored settings directly in a DBF table. This sometimes created a table with one record and lots of fields which was immediately useless once you had more than 255 settings (many applications continue this tradition today).
When Windows started becoming popular, many started to follow the INI approach, creating settings like
[application]
suppresslogin = true
name = george
[timezone]
This approach is still used and has support in the FoxPro Foundation Classes (and in the Solution Samples).
Developers have also embraced the Windows Registry (especially with Win XP). It's very handy because you would easily separate out MACHINE level settings from USER specific settings. Problem these days is that writing to the Registry is pretty much frowned upon with Vista unless you're running as an administrator (which may be fine for storing app generic settings but not so much for end-user settings).
So what's a developer to do?
I've been using a DBF for several applications (appropriately named SETTINGS) which works well but if you've started working with ASP.Net or other VS applications, you're likely becoming familiar with the whole ".config" file approach. These are essentially XML files that hold settings. Since it's XML, it's not completely understandable to an average user but the basics are in there and it can be edited in Notepad (or maybe better, XML Notepad)
Enter My.
My is one of the new VFP pieces from Sedna and it includes a handy Settings class for managing application Settings. There are only four methods so it's easy to start working with. The big benefit here is that it saves settings into an XML file that uses the same schema as DotNet, making it easier to let non-VFP admins or devs review the files.
Here are some quick samples:
My = NEWOBJECT("My","My.vcx","My.app") && If you've copied it over.
** Creating the initial settings file
My.Settings.Add("ApplicationFolder","C:\MyApp\")
My.Settings.Save("App.config") && or whatever file name you need to see
IF My.Settings.Load("App.config")
IF NOT my.Settings.Exists("HelpFile")
my.Settings.Add("HelpFile","HELPME.CHM")
my.Settings.Save("App.config")
ENDIF
ENDIF
Those are all the methods you have to be aware of: Add, Save, Load and Exists.
So how do you access a setting? It becomes a property of the My.Settings object.
lcFolder = My.Settings.ApplicationFolder
lcHelp = My.Settings.HelpFile
If you look in the actual file that is created by the Save method, it looks something like this:
<?xml version="1.0" encoding="utf-8">
<SettingsFile xmlns="" CurrentProfile="(Default)" GeneratedClassNameSpace="" GeneratedClassName="Settings">
<Profiles/>
<Settings>
<Setting Name="ApplicationFolder" Type="System.String" Scope="User">
<Value Profile="(Default)">C:\MyApp\</Value>
</Setting>
</Settings>
</SettingsFile>
As you can see, there's room for a little more growth in that file.
Benefits
1. The Add method handles different types of data elegantly. (note the Type="System.String" in the XML file)
2. Easy access via properties (although you have to use Exists if you need to verify that a setting actually does exist)
3. It's Extensible (more on this in a future post- but I know Doug Hennig has talked about this before as well)
Drawbacks
There are some little quirks that will hopefully be addressed with:
a) be sure not to put spaces into the setting value - it errors out
b) if you call Load and the file does not exist, it errors out so be sure to wrap it with a IF FILE() before you look for it.
c) you can't remove a setting without manually editing the settings file
d) you have to manually check to ensure a setting exists
So what?
Your existing applications may already have their own method for managing settings - and I certainly wouldn't want to start changing working applications.
But if you are rebuilding an application, need to start tracking settings, or working with other possible non-VFP users and want to make your settings file easier for them to understand, consider using the My.Settings.
It will get you started exploring the other benefits of the "My" namespace, will make it easier to manage settings, and provides an easy to learn approach for other developers as well.
Need to get My? Go to the VFPX CodePlex project or download Sedna.
Back in the DOS days, many developers stored settings directly in a DBF table. This sometimes created a table with one record and lots of fields which was immediately useless once you had more than 255 settings (many applications continue this tradition today).
When Windows started becoming popular, many started to follow the INI approach, creating settings like
[application]
suppresslogin = true
name = george
[timezone]
This approach is still used and has support in the FoxPro Foundation Classes (and in the Solution Samples).
Developers have also embraced the Windows Registry (especially with Win XP). It's very handy because you would easily separate out MACHINE level settings from USER specific settings. Problem these days is that writing to the Registry is pretty much frowned upon with Vista unless you're running as an administrator (which may be fine for storing app generic settings but not so much for end-user settings).
So what's a developer to do?
I've been using a DBF for several applications (appropriately named SETTINGS) which works well but if you've started working with ASP.Net or other VS applications, you're likely becoming familiar with the whole ".config" file approach. These are essentially XML files that hold settings. Since it's XML, it's not completely understandable to an average user but the basics are in there and it can be edited in Notepad (or maybe better, XML Notepad)
Enter My.
My is one of the new VFP pieces from Sedna and it includes a handy Settings class for managing application Settings. There are only four methods so it's easy to start working with. The big benefit here is that it saves settings into an XML file that uses the same schema as DotNet, making it easier to let non-VFP admins or devs review the files.
Here are some quick samples:
My = NEWOBJECT("My","My.vcx","My.app") && If you've copied it over.
** Creating the initial settings file
My.Settings.Add("ApplicationFolder","C:\MyApp\")
My.Settings.Save("App.config") && or whatever file name you need to see
IF My.Settings.Load("App.config")
IF NOT my.Settings.Exists("HelpFile")
my.Settings.Add("HelpFile","HELPME.CHM")
my.Settings.Save("App.config")
ENDIF
ENDIF
Those are all the methods you have to be aware of: Add, Save, Load and Exists.
So how do you access a setting? It becomes a property of the My.Settings object.
lcFolder = My.Settings.ApplicationFolder
lcHelp = My.Settings.HelpFile
If you look in the actual file that is created by the Save method, it looks something like this:
<?xml version="1.0" encoding="utf-8">
<SettingsFile xmlns="" CurrentProfile="(Default)" GeneratedClassNameSpace="" GeneratedClassName="Settings">
<Profiles/>
<Settings>
<Setting Name="ApplicationFolder" Type="System.String" Scope="User">
<Value Profile="(Default)">C:\MyApp\</Value>
</Setting>
</Settings>
</SettingsFile>
As you can see, there's room for a little more growth in that file.
Benefits
1. The Add method handles different types of data elegantly. (note the Type="System.String" in the XML file)
2. Easy access via properties (although you have to use Exists if you need to verify that a setting actually does exist)
3. It's Extensible (more on this in a future post- but I know Doug Hennig has talked about this before as well)
Drawbacks
There are some little quirks that will hopefully be addressed with:
a) be sure not to put spaces into the setting value - it errors out
b) if you call Load and the file does not exist, it errors out so be sure to wrap it with a IF FILE() before you look for it.
c) you can't remove a setting without manually editing the settings file
d) you have to manually check to ensure a setting exists
So what?
Your existing applications may already have their own method for managing settings - and I certainly wouldn't want to start changing working applications.
But if you are rebuilding an application, need to start tracking settings, or working with other possible non-VFP users and want to make your settings file easier for them to understand, consider using the My.Settings.
It will get you started exploring the other benefits of the "My" namespace, will make it easier to manage settings, and provides an easy to learn approach for other developers as well.
Need to get My? Go to the VFPX CodePlex project or download Sedna.
Comments