Skip to main content

Using My for Settings Management

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.

Comments

Garrett said…
Sweet, Andrew. I can actually think of a place I might be able to use this info in the near future.

Popular posts from this blog

Well, that explains CodePlex...

In a move that will be sure to anger open source (or rather anti-paid software, anti-Microsoft open source)  zealots, Microsoft is planning to buy GitHub . A year ago, I mused about why Microsoft would shut down CodePlex and how the world needs competing source code repositories to be strong. I'm not the only one per this Slashdot article  : "...   people have warned about GitHub becoming as large as it did as problematic because it concentrates too much of the power to make or break the open source world in a single entity, moreso because there were valid questions about GitHubs financial viability...." - Jacques Mattheij I will be interested in seeing this play out - whether developers jump ship or not. Have all the efforts Microsoft has made in pushing towards open source be seen as genuine or will all the zealots jump ship or maybe even attack? Microsoft's comment about why they shut down CodePlex referred to how spammers were using CodePlex. Well, GitHub

Attending Southwest Fox 2019 could change your life - Find out how

Southwest Fox is coming up in October and as I do every year, I spoke with the organizers Rick , Doug and Tamar on the FoxShow. Deadlines for Southwest Fox: Super-saver price (before July 1): $695 Early-bird price (before August 1): $770 Regular price (August 1 and later): $820 This year, I took a different approach with separate shows for each organizer but the main message is still the same : July 1st is their Go/No-Go date. Conferences don't talk about this very often. I don't think developers really question if Apple will hold their WWDC in June or Microsoft will hold their Build conference - but that's because those conferences are vendor-led. Southwest Fox is a community-driven conference - it's not driven by a company with an agenda. Listen to the interviews and you can hear how important each of the organizers feel the live connection between speakers and among attendees.

Virtual FoxFest - A New Way to Conference

If you haven't been keeping up with the news around the Fox community, the Southwest Fox conference has gone digital now showing up as  Virtual FoxFest .  At $49, it's a steal and a great way to learn some new ideas and get inspired. While the reasoning for this change is fairly obvious with the year of COVID - for me, this is something that has been a long time coming. I appreciate many people's needs for a physical conference but the world is very large and it's difficult to get people from around the world into a single physical location. I recently attended a single-track conference via YouTube (a Quasar conference). YouTube's Live stream provided a very handy way to watch, rewind and communicate with people online. While Tamar, Doug and Rick are still making decisions related to the streaming platform, there are lots of great options available. I'm really looking forward to it. The FoxPro community has also really felt its international roots