The book is rated at "Intermediate to Advanced" It is not. It would be better described as being at the beginning to intermediate level. While not explaining how to program per se, the vast majority of the pages are devoted to explaining how to use the VFP5 IDE and giving code snippets to explain the various VFP5 properties, events and methods. For example, care is taken to explain how the concepts of "SETUP" and "CLEANUP", from the VFP2X environment are replaced by INIT and DESTROY methods. In fact, for programmers just moving from VFP 2.x to the VFP5 environment, you couldn’t find a better guide to lead you on that journey. Even the most arcane areas of the IDE, for example, remote views and the odbc, are WELL explained and described.
I wish I had discovered this book six months ago, when I was making my journey, but I know I will be consulting it frequently in the future. But, contrary to the claim made in the title, this book does NOT do an adequate job of introducing or explaining the concepts of a framework. Substantive discussion of frameworks begins and ends with chapter 16, a total of 36 pages, most of which is taken up by code snippets from the "Utility" framework found on the diskette. But not quite. The snippets in the book are similar but not identical to those in the code on the diskette. The code on the diskette is accompanied by a 71 page Word Document. That puts the total framework documentation "page" count at 107, fulfilling the claim of "Over 100 pages of documentation." Much of the 71 pages are merely listings of objects with brief descriptions of their PEM’s, with little, if any, explanation.
The framework modeled in this book differs from that of CodeBook 3.0 in its use of the form. King feels that creating programmatic subclasses of the DataEnvironment, Cursors and Relationships the way CB3 does adds unnecessary complexity because the form contains already those elements. CB3 creates containers with controls and loads the DE and Environment as objects to mimic a form. He adds this note: "It’s important to remember that a form created from a class does not officially ‘inherit’ from the class, which means that although the code from the parent class will fire, you can’t edit it in the form. Moreover, any method of event of the parent class will be irrevocably overridden if you put any code into the form method of the same name. There is no way to reference the class code (such as with the :: operator) because FoxPro does not recognize the creating class as a ‘Parent’ "
For the past couple of months I have been trying several application frameworks and an application generator. For my particular needs it became apparent that the frameworks I had been examining had one thing in common: they were too extensive, too elaborate. They showed me that I really needed was a framework that had login, security and error trapping. The diskette included essentially just that. Like the sample that came with CodeBook 3.0, the "Utility" framework didn’t work either. It had path problems and when the login object tried to find the User table it couldn’t, so it informed the error object, which tried to display the GENERROR.SCX screen but couldn’t find it, which resulted in the old FoxPro error msg box. However, despite the path assignment problems, the three principal object were there, and well designed, if not well written. Especially the error object. It includes an error.dbf, which contains all 667 FoxPro errors and a full description of each and a complete error logging ability at either a developer level or a user level. The security object is no less complete, allowing group, access and activity checking to five levels. With care an NCSC level B1 application can be created using the AppSec object. AppSec.PassCheck(), a one-line security "gatekeeper" can be put anywhere in your application.
Despite the bugs, the three main objects (there are others) are so well designed and implemented, and so easy to understand, that I feel it was worth the $39.91 that Amazon.com charged me.
