C&L Nicholls - Spacefold Lisa's Page >L<'s Fox Stuff FoxSpoken Volume Index

>L<'s MasterClass Framework

Note: before reading and using any information on this page, please read the caveats *3 with which I provide material for your use. You may also want to read the short note *5 on why I've written MasterClass, what MC is, and how I make it available, if you have no idea what the MC Framework is about.

Please note

Development of MasterClass Framework has officially stopped in VFP 6. You'll find more information about this decision elsewhere on the FoxSpoken pages -- here, I'll just briefly explain that VFP 6 offers better architectural opportunities. MasterClass' original purpose (to educate VFP developers) is still legitimate, but much of its premises, and the problems it solves, are inherently better-solved by VFP internally than they were when MC was conceived.

This page remains for the use of those people still using MC for VFP 3 and VFP 5 development projects.

Unpassworded M_CHG#.ZIP Change file(s) for Conference Attendees

M_CHG1.ZIP: Changes in MC Version 5.1 (post DevCon '96) updated Oct.96, ~21k

M_CHG2.ZIP: Changes in MC Version 5.2 updated Mar.97, ~27k

M_CHG3.ZIP: Changes in MC Version 5.3 updated Apr.97, ~14k

These small, unpassworded zipfiles contain changes -- what's new and fixed in MC since versions distributed at various conferences. I'm talking about the changes to the files you use to develop in MC (delivered in MASTER.EXE by GENMC, or generated by GENMC), rather than all the changes to the GENMC delivery/generator mechanism, although you'll find the latter referenced in the change files as well.

The notes contain various pieces of VFP development advice along with MC-framework-specific changes, which is really why I make them available freely here.

MC Framework files for people who have received a password from me

Please don't bother to d/l these (rather large, passworded) files unless you know beforehand that you're supposed to do so.

GENMC.ZIP updated Apr.97, delivering MC 5a.3, ~399k (generator application to deliver the MasterClass basefiles and startup MC Framework-based applications)

M_DOCS.ZIP updated Apr.97, ~177k (documentation for the MasterClass Framework)

Instructions/version caveats for the people who should download these files:

MC 5a.3 is a very minor upgrade to 5a.2, uploaded Mar.97. If you already have GENMC.APP 5a.2, you can skip this download and just pick up M_CHG3.ZIP, which describes the differences. M_CHG3.ZIP's chg_source field will give you everything you need to edit your MC base files up to the latest version of the framework.

In most cases, however, you do not need to download the change files above. Each of those zipfiles is contained in an M_DOCS record (read the Version Changes section and COPY these files out of the MEMO field TO <filename>ZIP as instructed). If you have been using MC before the current version, you should probably read the M_CHG# logs before you do anything else!

I have tested both GENMC.APP and the framework as well as I can in both VFP 5.0 and 5.0a. However, this version was developed almost entirely in 5.0a. If you experience difficulties in 5.0, they should either be described in the change logs or I don't know about them -- so please tell me!

CAVEAT: this version of the MC framework requires a 5.0a version of GENMENU or GENMENUL.PRG, If you are using a version of GENMENU that is too early, GENMC will try to warn you and do something about it. If you're not using GENMC, you have to take care of this on your own.

Put the APP and the M_DOCS.DBF/FPT all in the same directory when you unzip them. If it can find your Wizard.DBF file, the APP should register itself as a Wizard and you can use the Tools...Wizards...All list to get it later.

MC News: MC as a Server?

Several people have asked me whether the VFP 5 version updates MC for OLE Server (DLL or EXE) development. The answer is 'yes it does, although I'm not sure that MC is the best Server framework you can have'. I certainly have made MC 'Server-aware' in 5, removing visible feedback and other aspects inappropriate to automation or Server activity when you indicate that the app is a Server-type, whether you instantiate it in the current session of VFP or in its own protected environment. Like most MC settings, this one is a Controller property, and you shouldn't have any trouble switching its value on and off -- assuming your code is similarly careful to check its surroundings.

Remember, every framework specialises, and mine specialises in multiple instances of a given app. This does have potential for a Server application. However, MC also puts a lot of effort into environmental strategies that are required for safety in one session of VFP -- this kind of thing is unnecessary for a Server app. Notably, the Controller object is a formset to provide a private datasession, with some attendant overhead over a an object descended from a simpler baseclass -- and this effort is completely wasted in a Server, where everything -- bliss! -- including SET("HELP") and every other detail will be encapsulated automatically.

So (sorry for the long wind-up), I'm still trying to decide whether it is worthwhile to re-vamp the Controller into two collaborating objects: a custom object that "takes care of business" and a formset only instantiated to provide the private session where the MC application is not a Server.

It's a lot of effort, and I don't want to do it quickly, since there are a number of other services and design issues that might be different in the Server case as well. For example, would I really need a custom forms collection when _SCREEN.Forms() would never include any by non-MC-app forms?? For now, I'm content to have made MC capable of supporting a Server app with some integrity, and the efficiency-design issues will come later.

I am proud to say (this is the good news) that MC takes less adaptation for Server use than most VFP frameworks would. This is a direct consequence of its lack of READ EVENTS assumptions. At the same time, the supporting components that allow MC to ignore the READ EVENTS prop are overkill for many developers. I'm looking into simpler alternatives, especially for use by beginning VFP programmers.

Meanwhile, this doesn't stop my adding small tweaks and refinements... look back at the information on GENMENUL.PRG for some related discussion.