Generic user adjustable VFP settings

[awaresoft]

The goal of this topic is to put together a list of settings that an application might read from an INI file that would allow customers to make field level adjustments to an application's behavior without having to recompile the application in question. I'm looking for settings whose values - in theory - should not affect core program logic.

By settings I mean generic VFP settings vs. application specific settings. Typically these would be SET, SYS(), _VFP/application object, or SYSTEM variable (_* variables) related settings.

Here's my list so far:

_dblclick - time period that defines a double click
_incseek - listbox/combo incremental seek delay
sys(2060) - mousewheel event handling
sys(2700) - enable/disable use of XP themes
sys(2800) - enable/disable Active Accessability support
sys(3050) - foreground/backgroun memory use
sys(3051) - record lock retry delay
sys(3052) - use record lock delay for index/memo
sys(602) - offscreen bitmap on/off

application.OLERequestPendingTimeout - OLE timeout value
application.OLEServerBusyRaiseError - OLE timeout value
application.OLEServerBusyTimeout - OLE timeout value

Any additions/deletions?

Malcolm

 

[alvechurchdata]

What about SET DATE. I've used a couple of apps where I had to use American dates because the writer hadn't given the option to choose a local date setting.

Similarly - 12/24 hour clock for time displays.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[Mike Lewis]

Malcom,

There will be many user interface settings that can be controlled in this way. Whether to show tooltips is one example that comes to mind.

A couple of points:

- Ideally, these settings should be made within your application's user interface rather than through an INI file. The advantages would be: it will be easier for the user to change the settings, you can provide additional help on the various options, you can validate their choices, you can restict te ability to alter the settings to specific types of user, and there is no danger of the INI file being deleted.

- If you are going to let the user choose foreground / background memory settings, you will have to provide a clear explanation of the implications of this choice. Similarly for the OLE timeouts, and others.

Apart from that, your thinking is good. I'll look forward to seeing what other people suggest for your list.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[awaresoft]

Geoff,

I excluded SET DATE because allowing a user to change this setting might affect an application's behavior if the application assumes a specific date format. IMO, SET DATE is one of those settings that an application should manage.

I'm looking for advanced settings that one might expose that "shouldn't" affect core application behavior.

Malcolm

 

[awaresoft]

Mike,

I think many of us already provide a user interface to application specific settings including features such as form ShowTips settings.

I'm thinking about advanced (sorry - should have been more explict in original post) generic settings whose controlled exposure might provide us and our customers with additional flexiblity and customizaton options without affecting core application behavior and without the need to recompile our applications to support a customer specific setting.

Since these are advanced settings, I think an INI file is a reasonable solution assuming most customers won't ever change the application's default values. I think an INI file strategy provides a generic way to extend the capabilities of existing and future applications without having to worry about cluttering the user interface or application specs with discussion of these config settings.

In other words, I'm trying to "make simple things simple, and difficult things possible".

Does this strategy seem reasonable?

Malcolm

 

[Mike Lewis]

Malcom,

Yes, that makes sense. I assume that you will give your "advanced users" some sort of guidance on how to make the necessary adjustments to the INI.

Also, perhaps you should confine the INI settings to things that won't have a disastrous effect if someone messes them up. Ideally, at worst the user will get an application that doesn't perform as well. You wouldn't want a rogue setting in the INI file to crash the system or destroy data.

Interestingly, I just used an INI file for the first time for many years. I needed to store an email address within the app. Since the app doesn't have any other configuration settings or user preferences, it would have been quite a lot of effort to provide a user interface and storage mechanism for this one piece of data. An INI file turned out to be an easy solution -- only a couple of lines of code, using the GetPrivateProfileString() API.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[awaresoft]

Mike,

I think it goes without saying that any INI setting should be pre-tested for reasonableness.

Thanks for your feedback (again!) - you've been a real help to me today.

Cheers!

Malcolm

 

[Mike Lewis]

Malcom,

Glad to have been of help. Good luck with this exercise, and let us know how it works out.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)