Peter,

>Right. Sidenote : we don't use the VSS product at all.

You should.

>Well, that's what we pursue here. It's a very complex system by itself, knowing that one pending function can (and should) stop related functions (also adjusted but not pending, hence from another "release note") from going over. The VCX as it is now, can't be part of this automated procedure, already because when I change one method of a class, the whole VCX is "pending". Right ? But my stupid adjustment was only about changeing a color of a shape I am not satisfied with. This one (even !) method is all that shouldn't go to the customer, but the whole VCX and all in it, is blocked now. And you know, there were three other classes adjusted for important new features. Now what ? now PS has left for holidays and the VCX can't go to the customer because some stupid shape appearing everywhere has a wrong color.

I think deployment needs to have better control than what you describe. The developer changes the color, tests it himself. Once it passes developer test the code gets promoted to the test team, once it passes test the code gets promoted to release. Then the change gets deployed to the client. The scheme I talked about earlier allows us to update one or more classes in a classlib through the dev/test/release cycle.

>Now obviously when this one method would have been in a PRG (but like you said, with stuff around it depening on hierarchy, depedencies etc.), it would be normalized. Far better at least. And I don't think this should be solved by creating 250 VCXes. I mean, when you find yourself doing that, you'd better stuff it in the PRGs IMO.
>But I must say, it is worth while thinking this over, once the 250 VCXes are bound by the project. IOW, you'd have the advantages of the visual environment (drag and drop etc.), and it would be better normalized.

I'd never create that many classlibs, I think one class per classlib is excessive. Like I mentioned before functional/hierarchical/aggregation/association relationships should control what classes are packaged into what classlibs.

>And you know why I "am able" to think like this now (opposed to, say, day before yesterday) ? because I found this "cyclic" relation in our VCXes (thread #698836). I would never have done a thing like this on purpose, but as it looks now, this is just legitimate. So apparently all can be scattered more than I knew. And again, as long as the project binds them all, why not ?

I'll have to look more closely at that thread. I have developed some classes likes this:

BusinessRule
   BusinessRuleCollection
   XBusinessRule
   YBusinessRule

where the BusinessRullCollection class aggregates in the X and Y BR objects. That's about as close to a cyclic relationship I've worked with.

>See earlier; One property-change, and I see the timestamp of the whole VCX.

Yes, the package needs to be deployed as a whole....

>The discussion now led to my idea of having a separate VCX for each class.
>Would that be (too) stupid ?

I think it's not smart *g* I think ther's a happy medium between having all the classes in one classlib and every class in it's own classlib.