Greg,

>For true OOP power and resusability you can't beat Codebook. It has a very difficult learning curve and takes some work to get all the paths, include files and rebuild process smooth. However its Codebooks business object concepts allow incredible reusability. The added benefit of the difficult OOP learning curve is you begin to really understand inheritence and creative ways of using classes. Even if you don't use Codebook to develop your own applications a serious professional VFP developer would be well served by understanding it from top to bottom. Be warned at first the array of classes can be daunting and came many times seem unnecessary. I thought the people who put the framework together went way overboard on the OOP when I first started working with the framework. Now I agree with the decision for virtually every class they used. The exception being the OOP menus which I believe creates too many objects for the benefits you receive.>

What you say about Codebook's power and reusabilty is very true. Although we have made VFP3 Codebook much easier to use in our Codebook for Mere Mortals framework, there are a number of gems in the original version from Flash that we have left intact because I consider them real innovations...and extremely useful in any application. For example:

Dynamic View Cursors...these cursors allow you to create a single Visual FoxPro application that can access both local Visual FoxPro tables AND remote databases (i.e. SQL Server, Oracle). In Microsoft's documentation they talk about creating an application locally and upsizing to SQL Server. However, this is a one-way street. You end up with an application that accesses local tables, or remote tables, but not BOTH. Codebook's Dynamic View Cursors allow you to refer to a view generically within an application. This allows you to dynamically switch between local and remote views. Here's the benefit to VFP developers: You can make a lot more money on application that uses SQL Server or Oracle as a back end. If you are neglecting this market and writing VFP-only applications, you are expending the same effort for less money. Take a look at the price of any commercially available application. The price of the client-server versions are always far more expensive than their local database counterparts. Even if you are writing "in-house" applications you can save yourself a lot of time rewriting applications that the boss swore "will never have to be client-server".

Business Objects...these are NOT unique to Codebook or Visual FoxPro. If you look outside our small VFP world you will see there's a large OOP community out there programming in C++, Java, SmallTalk etc. who are using business objects in their applications. Alan Griver and others at Flash recognized the importance of these objects when VFP 3 first came out of the gate. Business objects allow you to create reusable code that can be dropped on any form, anywhere in your application. Not only that, they are the first step towards creating distributed applications, because they break out the business rules and data access from the rest of the application. If you're NOT using business objects now, you have to ask the question, "What kind of rewrite will I have to do when the next version of Visual FoxPro is released and I want to create truly distributable applications?". Of course, you don't *have* to create a distributed application, and may not even see the need right now, but you certainly will the first time your client asks you for it! Microsoft is pushing components in a big way right now and with the advent of Windows 98 and the fantastic success of the Internet, we'll see an even greater push. If you are using business objects now, it's a much easier step to move these to a second tier within a three-tier architecture.

There is a small price to pay for this flexibility. It takes more time up front to do object-oriented design and analysis. It takes a little more time to create an application that does not hard-code its data access, but rather uses views as a first degree of separation and Dynamic View Cursors as a second view of separation. But the end result is a flexible, extensible and maintainable application that will have a much longer life than the "VFP-Procedural" applications that many developers are writing today. So the effort up front actually ends up saving you time in the long run. To help make this flexibility even easier to incorporate, I am currently working on some builders and utilities that we will be adding to our Codebook for Mere Mortals framework.

Regards,