>The program associated with each form only handles code needed exclusively by that form. This code calls common code in the procedure files. Thus, in most cases, these programs are small. In we have two large procedure files; one containing our 'Base Library of procedures' and the other containing common procedures for the product. These two combined have about 9,000 lines of code in 60+ procedures. I can't even imagine trying to deal with that much code in that many methods in one container.

Unless the container is defined in a .prg, that is.

I've worked with an in-house framework where all the code for the form was in its DE-like object, which in turn instantiated any number of bizobjects it needed, all of which were defined in prg files. This also made a few things simpler, as the code required fewer parameters (having one oSQL object for all things SQL logically led to the handle being its property etc) and the design was proper 3-tier. And there was almost no code in the forms themselves, maybe just in some grids an occasional "return .f." in a column's .when(). All the form code was either class level (in a vcx) or local to the form - ergo, handled by the .de object and its bizobjects.