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 has its own …

FoxInCloud Stats

FoxInCloud sent this link a while back about their statistics regarding visits to their site:

http://foxincloud.com/blog/2017/12/27/VFP-community-lessons-from-foxincloud-site.html



What's interesting here is the breakdown of people. Yes, I think it's understandable that the Fox community is getting older.

Another factor is the growth of the mobile and web environments taking over development. These environments really do push people towards the newer non-SQL or free SQL/hosted environments but more towards hosted storage options like Amazon and Google. A tool like FoxInCloud that helps MOVE existing applications to the cloud inherently competes with those environments.

But FoxInCloud also allows developers to extend their application further by giving them a starting point using Javascript and the basic CSS (such as Bootstrap). If you're not rebuilding your application from scratch, it's certainly a great step forward.

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.