Sunday, June 22, 2008

VFP: Include Config.FPW in EXE

I was working with one of my clients a couple weeks ago and he asked me my thoughts on using a Config.FPW with a VFP app. I mentioned I include one with every application I deploy and sometimes two.

The first one is brought into the project, marked as included, and compiled inside the EXE. Some Developers shy away from this technique because it makes the Config.FPW read-only and this sort of defeats the purpose of a configuration file. This was true in VFP 7, but since VFP 8 was released you can have more than one by including the following line in the Config.FPW:

ALLOWEXTERNAL = ON

You can include a Config.FPW file in the application folder to override any of the settings. Visual FoxPro gives the external file priority. Here is my default Config.FPW file I start with for all my applications.

* Default Configuration file for application
SCREEN = OFF
RESOURCE = OFF
ALLOWEXTERNAL = ON
_BROWSER = ""
_BUILDER = ""
_FOXREF = ""
_CONVERTER = ""
_COVERAGE
_GALLERY = ""
_GENGRAPH = ""
_GENHTML = ""
_GENMENU = ""
_GENPD = ""
_GENSCRN = ""
_GENXTAB = ""
_TASKPANE = ""
_TOOLBOX = ""
_TRANSPORT = ""
_WIZARD = ""

You might be wondering why I have a bunch of the system memory variables blanked out. I cannot recall where I read it, but this helps a run-time application start faster because VFP is not trying to find the IDE tool locations determined by the system memory variables. This has been an old trick from a long time ago. We are probably talking nanoseconds of savings because VFP is very fast, but I only really had to type these in once.

So my client implemented my idea in his app and called me back to tell me I was nuts because it was not working. Crazy talk, I know I have been using this for years. I asked him if the file was marked included, and if there was actual settings in it and he proclaimed yes. So I connected up to his machine to see what was up. He included it in the Programs section, not the Text Files section in the Project Manager. Took me about 30 seconds to figure this out and he was back in business.

I do find it interesting that Fox cares about this as I always thought it was the file name extension that mattered, but apparently the section you include the file under does have an impact on how it is treated. Good to know (and share with all of you just in case I am not the last developer to learn this {g}).

I have read where some developers are using this file to SET REPORTBEHAVIOR 80 so they can move their apps to the VFP 9 runtimes without needing to change their source code. I have an application object that calls an environment settings object to make most of the SET commands the way I like or need them for my applications. Alternatively you could set them in the Config.FPW, I just don't use it this way.

I also read something interesting this week about the Config.FPW file that I had not considered before, but if you include a Config.FPW file in the same folder as the Visual FoxPro OLE DB driver it will use your customized settings. I have not had a whole lot of use for the OLE DB driver in my Fox projects, but it is good to know in case I do have the need to do so in the future.

What techniques are you using to help me build a better default Config.FPW?

Labels:

5 Comments:

At 6/23/2008 04:57:00 PM, Blogger Victor said...

A different way of using multiple CONFIG.FPW files is by including "-C" parameter in the command line that executes the application, so, for an specific configuration we may include a customized CONFIG2.FPW, then within the application we may test for the value of the active FPW with SYS(2019)

Best Regards

Victor Espinoza
Miami, FL

 
At 6/24/2008 02:01:00 PM, Anonymous RVBoy said...

Rick, the VFP9SP1 Help File agrees with you that blanking system variables can improve start-up speed.

The other setting that can make a visible difference is SYS(2450), especially if you have a convoluted path. SYS(2450,1) has a number of advantages especially if most of your procs are inside the exe. apart from performance, it can help prevent code injection as well. You can include it in your config.fpw using a command= statement, of course remembering that you can only safely include one command= in your config.fpw!

 
At 8/06/2008 07:47:00 AM, Anonymous Mike Lewis said...

It's been a long time since I used a Config file for SET options (things like SAFETY = OFF rather than SET SAFETY OFF).

Don't know why, but I prefer to put the SETs in my main prog, and also the Load event of my base class for forms with their own data session.

That leads me to a question: When you make the settings in the Config file, do they apply to all data sessions, or just the default session. (Obviously, this is only relevant for the subset of settings that are scoped to the data session.)

Anyone know the answer? Just curious.

Mike Lewis
Edinburgh
www.ml-consult.co.uk

 
At 9/25/2008 03:13:00 PM, Anonymous Mike Yearwood said...

Hey Mike Lewis

The settings in the config only apply to the default data session, not to all forms - as you know private data session forms have their own settings.

The config.fpw file is the only place where you can prevent the initial VFP screen flashing up by using the _screen=off and prevent the creation of a foxuser.dbf resource file.

 
At 2/24/2010 11:40:00 AM, Anonymous Jon Goad said...

One way that the config.fpw saved me was when a user in Ireland bought a copy of our application, and I was able to change the date format globally by simply adding DATE=BRITISH in the config.fpw.

 

Post a Comment

<< Home