[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7] [ 8 ] [ 9 ]

I wrote the first chunk of code above into the Init of a form class. The second set of lines went into the Click event of the form's OK button. This form class was
not related to the framework in any way, rather simply subclassed from VFP's base form. The interface for the new MyOptions dialog looks like the figure below.

A new options dialog for a specific application…

To make my new dialog the options dialog, for an application, and to set the user options array up for this option only, I added the VCX containing this dialog class to the Project, to make sure it was available to
the application. Then, using the cOptionsDialogClass and cOptionsDialogClassLib properties, I told the application object for this application to use this dialog class instead of the default, as shown in the figure below.

… becomes the options dialog for this application with very few changes…

A change of the application's cOptionDialogClass property to read "NewOptions", and you'll get the options dialog shown in the figure below. This dialog adds the new "lUse_GetExpr" option into a subclass of the _options default dialog, to show you how you might do it.

…or, if you prefer, add new options into the existing set by subclassing the _options dialog class in _FRAMEWK.VCX.

NOTE: No matter how you create or set your options, when the application starts up, an array setting might not be available for the current user (perhaps the user table has just been created), but no harm is done, no error occurs. Any property or SET not available in the current options array will use the application default, and any user-specific setting will be saved when the user first accesses the options dialog from the menu.

If you find you want to add an option like this into all your framework applications, this is the kind of change you might want to make in your T_SUPER.VCX, described above in the section on changing the Wizard-generated components. Your version of _options, in T_SUPER.VCX, could be either a completely new dialog like MyOptions or a subclass of the _options class in _FRAMEWK.VCX, like NewOptions.

Going on from here

The framework's main job is to wrap VFP hard and good stuff, so it's still good stuff and not so hard. At the same time, the framework tries to make sure that you can "do it your way". This means there's a lot of depth you won't need, or want, to look at every day -- and at the same time the functionality is there when you want to have your cake as well as eating it <g>.

Believe it or not we've only scratched the surface of the built-in functionality you can access in the VFP 6 framework. However, you now have a pretty good idea of how that functionality is laid out, and what to look for. The best way to find out more is to explore the PEMs in the classes _FRAMEWK.VCX and the FFC classlibraries from which the framework derives some of its features.

This process will be gradual. You can start with automatic use, mix and match the delivered classes with experiments of your own, and adapt this framework project by project, hook by hook. Along the way I hope that you and your team enjoy what you learn and enjoy your work, and play, in VFP.

As you explore, be sure to drop by http://www.softspoken.co.nz/lisa_fox.htm, or write a message on the msnews.microsoft.com public fox groups. Share your ideas with me and with the Fox community.

[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7] [ 8 ] [ 9 ]