>Of course, this is all just preference, but I completely disagree here. How are prg's easier to manage?
>

For code-centric classes, I could care less about the visual designers. They represent more of an encumbrance to me. For instance, I may have a customer class that encapsulates data and business rules. Why do I need a visual designer for that? I can munge the code WAY faster in PRG's.

>I only use prgs to hold class definitions when I have to for the following reasons:
>
>1. Having a class in a vcx makes it clear without opening it that it is a class or group of classes. With a prg, you have to open and inspect it.
>

Are you saying that you can immediately know in a VCX whether it contains one more classes? Not a big deal to me....

>2. If you have a group of classes in a single prg, you can't see them from the project manager. With a vcx, you just expand the vcx to make the contained classes visible. You can also drag from the PM to a form or another library, or remove classes from the PM.
>

Adhere to some basic concepts, and you will not be creating huge PRGS. Fact is, I can view each PRG in the PM. Some well worded comments, and I am well on my way. Also, my source code control issues are much less complicated.


>3. Two words: Class browser. Try that with a prg.

The class browser addresses one major thing, viewing a class hierarchy. And, when I rely on inheritance, it is an invaluable tool. For most things, the component gallery provides more utility for me....