David,

>Peter,
>
>>So, this urges for having a class definition per PRG, right ? Anyway, it is an (some) argument for that. IMO, when both are heavily related, they should be in the same PRG, JUST for the disallowment of two persons changing at the same time (and again, our edit facilities will protect that then).
>
>If a person has the file checked out then there is no way another developer can work on the file. That's the best security.
>
>I think the packaging of PRGs or VCXes should be done on a functional/hierarchical/aggregation/association basis and not be overly regulated by the VSS concerns.

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

>
>>Right you are. Now let's ask MS to give VFP a command to compile our own code in the Memo, just like the VCX can do it. IOW, VFP can do it, just give us the command. Off-topic that is.
>
>You can already take the FXP and put in into a binary memo field. You could then potentially distribute a DBF/FPT that gets extracted at the client to the correct files on disk. But since the VCX already does this why not just use it?

It's not about that (it was off-topic, not about distribution). This is about generating VFP code into "some" place where it can be kept associated to the database. Thus, generate some source in a cMemo and perform a cTable.cMemo(). Think of highly generic systems driven by meta data. Within our website (the CMS of it) this is actually used. But, it needs the stupid trick to pack the generated source in a Procedure. This is really different, because the PROCs in there have to have names obviously, and all is not transparent anymore. Having it in a Memo is THE solution, but derived from the fact that VFP can do this.


>
>>Yes it can. But you know, this would be ANOTHER stream to distribute. Right now we don't do that at all. So only at first install, and when some DLL or OCX ect. is needed to be registered. Think of it : why bother all the indiviual users with the "upgrade" phenomenon, where it can be done without. And it can. So we do (without). Remember, we are not the package with a 1-year-new-release. They are there each day, and it's up to the customer when they download (incremental upgrade).
>
>I guess I really don't understand the specifics of your upgrade/fix distribution system, but there really isn't much difference as far as PRG/FXP vs VCX/VCT are concerened.

Well, I don't undertstand the context anymore roght now ;) But let's say that overhere we have one major objective : each person must be able to do his/her job without any communication, and it is about this "job" only. This is NOT about having to deal with upgrades. David, look at yourself adding some functionality to your app, change some structures, add a dbf here and there, test some, approve it and then run for holidays. Your co-workers do the same. Well, from that point on the new stuff starts to arrive by your customers. You don't notice it but it happens. Wouldn't that give you lots of additional time for the real job ?
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.

Get the idea now ? It's just not properly normalized ...
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.
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 ?

>
>>This can't be derived from timestamps because we'd be looking at the timestamp of the DE-VCXes. Once the VCXes are formally set ready (move them to the upgrade DIRs after removing the source), THAT timestamp does its normal work like you imply. But it's too late isn't it ? So it's about the traject of setting the big system Procedure ready, possibly needing the VCXes as well (and the other way around).
>>But never mind this story, because ibviously this can be arranged just as well. It just needs the other (technical) procedure here, which wouldn't be necessary if all is PRGs. No big point.
>
>I wouldn't deVCX the classlibs. The VCX timestamp will change with mods just like the PRG timestamp changes. Again there's no real difference.

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

The discussion now led to my idea of having a separate VCX for each class.
Would that be (too) stupid ?
In our case this would result in 105 VCXes.
The "cyclic" relations would be all over the place, and I still wonder whether it's officially allowed.