>I wish it would be as easy as it sounds. Here is what I found: each developer has his/her way of doing things and copies programs and classes from one application to another every time they need to create a new project.

Could it be that their testing team (if there is a dedicated one) is smaller ? The approach you describe is one I sometimes encounter in small shops delivering a number of different programs (compared to an application build on modules).

>One of them explained me his concepts and sort of was forcing me to follow the same steps. The other developer told me to grab anything I like from her applications and implement it. Finally there is another developer whom I haven't spoken at all and didn't see the applications (perhaps for the best to not confuse me further). There are only two main directories under each application folder: Data and Source.

>This goes against everything I used to work before. I always had base classes, programs, graphics in one common place (with appropriate subdirectories) and each application just subclassed the base.

Nothing preventing you from splitting your vcx/prg in fwk and application level. The described approach is one of "can always compile against local fixes and don't need to test against changes in fwk". In the places adhering to that scheme the fwk classes are only updated on major releases, while minor resleases (=critical bugfixes <g>) are implemented against the local copy. The benefit is that changes in the fwk classes will not blow other applicatins out of the water as they were not tested in that environment. Inherent assumption: when building the new major release all necessary tests stemming from changes in the framework done "in between" are done to get the thing running again. When developing *not* as a team effort but every developer responsible for a handful of applications this can make economic sense if they have very few bugs to fix between major releases. Get a mental picture of their bugfix/release approach (and the way the company "earns" for the software: via sale or maintainance contract) before deciding on a fitting strategy. View it as "branching" in source safe and only reintegrating/merging later. I still think a n-way structure

base class layer for clasees from dev 1 and/or 2 : BlaBlaLayer_Base_Author
base class layer for yourself : BlaBlaLayer_N_Nsnv
testing/intermediate class layer : BlaBlaLayer_Test (should be empty or pushed "up hierarchy")
application classes for yourself : BlaBlaLayer_app

will be most helpful even if you follow the copy method of No.1 - perhaps there is a tried method in there he was just unable to script (which I would see as self-evident, and the omission might make me suspicios<bg>).

Even if they use vfp8, I'ld develop/test at least partially in 9 to be able to jump faster - unless they are big on bindevents() <vbg>. Working one day a week in vfp9 nearly guarantees a portable program.

good luck and don't worry too much - you can probably fix later.

thomas