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

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.

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 …

The World of Updates Today

I just received an update for Office 365. It certainly includes some cool features - including starting in one environment and picking it up in another environment. In recent years, I've certainly enjoined the use of Continuity on a Mac and in fact, I feel spoiled being able to start a message in one environment (even Google) and then finish it off on another.  This has become some pervasive when we were reviewing our most recent backlog at a client site, a similar feature was added to the current workload.

But with web applications, the trend is to reduce the amount of software on a client machine. I used to have automatic backup for all of my machines (thanks Carbonite!) but these days, many of my machines don't need anything beyond the core OS and some basic applications. Certainly that's the feeling with Chromebooks and even the lightweight aspect of many iOS apps. The functionality is mostly in the cloud.

When you upgrade your system, you expect it to a big update. So…