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

Programmers vs. Developers vs. Architects

I received an email this morning from Brandon Savage's newsletter. Brandon's a PHP guru (works at Mozilla) but his newsletter and books have some great overall perspectives for developers of all languages. However, this last one (What's the difference between developers and architects?) kind of rubs me the wrong way. Either that, or I've just missed the natural inflation of job descriptions. (maybe, it's like the change in terminology between Garbage man and Waste Engineer or Secretary and Office Administrator)

So maybe it's just me - but I think there's still a big difference between Programmer, Developer and then of course, architect. The key thing here is that every role has a different perspective and every one of those perspectives has value. The original MSF create roles like Product Manager, Program Manager, Developer, Tester, etc - so every concept may pigeon hole people into different roles. But the statements Brandon makes are often distinctions I…

Security in Windows 10

http://www.slate.com/articles/technology/bitwise/2015/08/windows_10_privacy_problems_here_s_how_bad_they_are_and_how_to_plug_them.single.html

 discusses some Windows 10 privacy settings and their implications.

"Finally, we will access, disclose and preserve personal data, including your content (such as the content of your emails, other private communications or files in private folders), when we have a good faith belief that doing so is necessary." "In other words, Microsoft won't treat your local data with any more privacy than it treats your data on its servers and may upload your local data to its servers arbitrarily"
I did a quick install on a VM choosing the Express settings. When I fully deploy this on a real workstation, I will likely choose to wade through all of the individual pages, as David recommends.

Of course, losing one's privacy is nothing new - it's happening all over the place (despite Santa Ana's police force's lawsu…

AppleSoft

I'm not TRYING to be "fanboy-flame bait" but what I saw yesterday was a typical "Do it this way, now do it this way and then we'll go back to this way" all over again.... a move similar to what Microsoft does to developers on an ongoing basis.

Remember the first iPhone? Smooth and curved, at least as far as it could be back then. I still pull out my 3G and can see the curves on it.

Then the 4 came out and "boxy" was all the rage. Everything should be "tight with corners"

Now iPhone 6.... smooth and curvy is back. Granted I don't have the actual device yet, but that's the message.

Guess that means the iPhone 8 will be back to boxy.

And honestly, Apple Watch is not worth "one more thing" --- especially when everyone knows it's going to be shown. "One more thing" would be something no one saw coming.  The device itself ? Very interesting and yes, definitely lots of potential but "one more thing" wor…