I prefer to include everything in the App/EXE except the data and the reports. As Vlad says, it prevents users from meddling with your classes, and I have rarely been in a position where a change was simply a matter of changing a VCX. My users generally want changes that affect a form or two, some of the PRGs or Method code and (if I'm unlucky) a table structure change and a new index.

In most of my projects I use method code for all 'procedure' code, putting the method onto a form or onto the application object as needed. The same could easily be accomplished with a custom object, but it hasn't been necessary to date.

My latest project involves 4 programmers, and we've opted to use PRGs for many items and a PROC file for a 'bunch' of small functions used repeatedly. We've found it's easier to keep the code up-to-date for all of us. Because of some system limitations, we have to send our code to one person who manages the Visual Source Safe, so checkouts are not totally reliable.

Also, I prefer SCXs to VCXs for forms. I like having my data in the DE, available for dragging fields, etc., and I find them more convenient for testing.

We're using Visual MaxFrame, and it has some excellent built-in hooks for attaching custom controls.

Barbara

>To date, I've been in the habit of classing just about everything that is classible. For the most part, my classes are EXCLUDED from the build and then distributed with the .EXE (source code removed if necessary). The only objects that are not always classed are non-visual objects (i.e: DE, columns,headers...). I say 'not always' because I do have some custom classes that programmatically define non-visual classes by creating the necessary low-level files with the needed definitions.
>
>Reuseable procedures or application specific procedures are implemented using custom objects located in the .VCXs that can be instantiated as needed (application startup or on a form/method basis). I've found that this allows for easy updates to distributed applications and reduces the need to build,build,build during test and deployment. Also, if a change occurs that affects several applications, only the updated .VCX needs to be distributed vs a new .EXE for each affected system.
>
>A recent discussion with a developer for whom I may soon begin to work revealed that:
>
>1. .VCXs are compiled in the .EXE/.APP - not independently distributed. If a change is made, the .EXE/.APP is recompiled
>2. custom classes are not placed in .VCXs but., rather, are programmatically defined and compiled in the .EXE/.APP in .PRGs
>
>I'm pretty open-minded despite how this may sound. However, I'd like to get as much input as possible as to what other think about the use/purpose of .VCXs versus the implementation of proc files to hold class definitions. In the case of a preference for .PRGs, please explain your preference. Right now, I can't really see a benefit. Maybe I'm missing something.
>
>Please respond - the more the merrier.
>
>Thanks
>
>Dan