I find it's helpful to think of a .VCX as what it is: a "package" in both the colloquial and UML sense of the word.

VFP Packages are not immutable, and in VFP it's easy to change the packages.

1. Check out all the VCXes
2. Open your .PJX in one instance of Class Browser.
3. Open any particular VCX in another instance of the Class Browser
4. Ctrl+Drag and drop from the .PJX class browser into the target VCX instace of the other class browser.

When you do this, behind the scenes, the Class browser adjusts all the pointers in *all* the source and target .VCXes so that moving a class from one VCX to another is remediated seamlessly behind the scenes.

I did this once on a Saturday with 1800+ classes in a huge project reorganization and it worked flawlessly.

Why do this?

To create packages that are more task-oriented. In other words, keep the classes that work together in the same package (or just a few packages) so that someone working with a particular module will have low probability of contention with other developers. Contention probability is proportional to the number of developers and the number of classes in each VCX increases. There's a balance here, and the key is to realize that it's a lot more flexible than people think.

You can even prepare a package containing most or all the classes neede for a particular task so that junior developers aren't wasting time searching for classes -- it's mostly all gonna be in one place...

**--** Steve


>What is the best way of Controlling the SourceCode in a ClassLib with multiple Programmers down to:
>(a) A Class Level
>(b) A Class and Method Level
>VSS will obviously not do this to this level, so are ther any alternatives?