David,

>Peter,
>
>>Two things :
>>1. We have our own fool proof "editing" of PRGs; once one is editing, the other is informed of that.
>>2. Right, functional groups are to be together in one VCX. Or better : related obejcts at least (you referrred to this further down the line). We have one disadvantage here : our classes are not about independent user-functionality at all, but only about an "OS" like thing controlling the app. Let's say it's only base classes, from which run-time objects are created. A main form class, inheriting classes for change-forms, grids, etc. Also, a main control class, inheriting classes for textbox, spinner, checkbox, etc. (o yes, this can be done too).
>>So, all of it relates. We have two VCXes. See further down the line too.
>
>If you have more than one class definition in a PRG then two independent developers can not both be working on different classes in the file. Ok, so there is no real difference in the "single user environment" between a VCX and a PRG.

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).

>
>>Both I did not know. And, my point wasn't a real argument in the end. But let's say that when the VCX could be looked at as a "toy" just on top of the real working (i.e. at loading of the class internally it'd be generated PRGs executing), it would be the proof of the ability to do without. That WAS a point of me (and perhaps still is).
>
>The VCX isn't a toy at all. Like its FP2.x roots VFP uses a table as it's datastore for the design surface. VFP goes one thing better though, VCXes and SCXes no longer need to be converted into source code to be compiled, the compiled code is just another one of the memos. It's an easy way for VFP load a set of class definitions into memory.

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.
BTW, from your lines further down, I start to believe that the VCX really is "additional". I am beginning to change my mind ...

>
>>1. Assume not building EXEs at any time, except for some startup small EXE.
>>2. Now you are able to adjust one small function, and upgrade it to the customer.
>
>You can make the change to the classlib and distribute the VCX/VCT. Yeas it's one more file than sending a FXP, but it should be handled by a little distribution builder that you can build.

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).

>
>>3. When you have the VCXes as well, be careful not to forget them when the one function goes to the customer. That is, when the adjustment of the function implied an adjustment to the VCX as well. It therefor is some redundant operation (i.e. explicitly keep track of the fact that both have to go to the customer.
>
>The distribution builder can simply check file timestamps.

Haha, right. But it doesn't work like that here;
We have three groups of developers : 1. user functionality, 2. system programs, 3. Classes. Each of them work independently, and nobody knows what the other is doing (theoretically). Group 1 usually can do what they want, but may urge for system or class adjustment (rare). Group 2 usually do what they want and they never ask for anything. Group 3 will imply system program adjustments often;
It's the products of group 2 and 3 interfering. So, when the Procedure (file) of group 2 is formally set ready, they'd always ask group 3 whether it can go along without the product of goup 3 (the VCX files). This, because that can't be part of the PRG Editing mechanism. 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.


>
>>4. Build an EXE of all of it is the solution, and btw the normal procedure. But, building an EXE of all we have, takes ages (let's say a day or so), and besides that we'd have an EXE of some 70 MB. Opposed to this, our one function adjusted takes 6KB or so, so better upgrade only that 6KB to the customer. And that's what we do. So, the runtime consists of the 8,000 PRGs (FXPs) and some 2MB (excl. source) of VCXes.
>
>Ok, that's a huge EXE Peter! And I thought ours were big at 20mb, but ours rely heavily on VCXs so a good deal of the EXE size is actually the source code.
>
>If this really posed a problem we'd integrate a soruce code removal step in our build process. Building our app takes less than 10 minutes and only happens when we are releasing a test or production build every few days. Developer testing is done by instantiating the app object and calling a method.

Yeah, well, our 80MB is already without source code (obviously). It can't be squeezed further, and it's nothing to deal with. BTW, downloading the SP3 of W2K was 78 MB. Took 1,5 hours. So really, it's no way to go for when the customer needs some minor adjustment (or the correction of an app error).

BTW, the build takes this long because it wants to workout all the references. And as you know, this is not lineair to the number of functions involved. We just have too many. Note : possibly today the build can do without the workout of the references; I didn't try this since VFP3.

>
>>So what I tried to say in the end, is that when each class in the VCX would be a single PRG (the extreme), we could only send that PRG to the customer. Furthermore, it would be part of our 100 % transparent upgrade functionality like it was another of the 8,000 PRGs. This means, the developer adjust some class AND a related functional PRG as one logical set of adjustment ("releasenote") and after saying that set is ready to do, nobody notices or does anything. All is by automation from that point on. So for us, this would be a pro really. For us that is, because it'd be far from the normal procedure, right ?
>
>You couldn't phase in the upgrade, everything would have to be running under the VFP7 runtime. Once that is accomplished you could phase in changes by merely sending new modules (VCX/VCT/FXP files).

Oh yes David. My explanation above was me telling about our general approach. Obviously this VFP5-7 transition won't allow for any phasing.

>
>>Okay, that's not what I meant. Suppose you have one "structure" of a visual class. This is not arbitrairy but depends on the logic (of inheritance etc.). Now with this very class as the basis, when that's put in PRGs in there all can be put as we like (okay to some extend). We can put all in one PRG, all functions (methods) in separate PRGs, we could Include what we want, etc. The kind of point I want to make here, is that we are better able to present the class definition as some (better readable) procedural definition. This may be personal, but I still like to have all as procedural as possible, because of readablity and troubleshooting.
>
>The class browser does a semi-adequate generation of viewable code from a classlib. I've written a couple of different tools that process the memo fields of a VCX/SCX to produce much better documentation of the classes/forms.

Okay, should have tried that earlier (see more below too).

>
>>I understand the above, but for the last sentence. I mean, what you apply for the VCX, can be applied the same for PRG's I'd say. However, never mind that much, because we control the PRG-editing (as explained earlier).
>
>To copy a class from one classlib to another, all you have to do is drag the class from the source classlib to the destination classlib in the project manager. To pull a class out of a PRG you have to make sure you copy all of the lines of code for that class, there is some probability of error (not getting all of the methods on the copy out and then when you put the modified code back in the PRG you could accidently erase the method, or duplicate them for that matter)

I understand exactly what you are saying. And, I knew that, but still didn't mention it in the original message of this thread. The strange thing is : once you have setup an environment of non-visual classes, "somehow" you don't have the need for this (drag etc.) anymore. I am not sure where this comes from, and it should be about something like being more formal in the non-visual classes. I guess when doing it all in code, all is more snippets from the beginning, and hooks are more likely to use. I must think about this (interesting) phenomenon, and wonder how others feel this.


>
>>The main point is though, that we hardly can separate our momentary two VCXes into more. So it won't do (or, not enough).
>
>Are you saying you only have two VCX files in your project?

Yes. One is about "base-base" classes (like the one Form definition) and the other is about base classes (like the Grid definition). So, in there is not any form with controls on it, because all further is generated in run time, using the base classes (obviously). All various controls are in there too. Look at this (e.g.) as the "Office97-look buttons" which VFP somehow didn't provide. Or normal Menu-classes. Nothing strange really, but nothing "complete" in there just as well. So, all Forms are generated at runtime, and all controls on it as well. Look at this as the 100 % separation from the business rules and the GUI. Hence, Validations (and dealings with the user-answers to it) are generated (to the controls) at runtime just the same.
And oh, the 10-tab form loads in 0.2 sec. Off-topic again.


>
>>So here is your point. And, mine too (ref. 'some "impossible"' above). I just haven't the experience on doing it. Right now I can't judge this. Still without trying it, I think that this comes to Ed's advise on "generate source" from the class broser, but the only possibility to do it per class. And not for the VCX as the whole. Though I am typing and speculating, I'd better try instead ...
>
>The class browser was not designed to generate runnable code. It was meant as a view only sort of tool. If there's any containership with overrides involved it will not run. It can generate runnable code for very simple forms though.

Well, if that's so ... We have containers within containers within containers ... So much for Ed's advise (sorry).
The balance sure goes one sirection now.

>
>>David, I sure hope you don't find me "fighting" your statements. In fact, I now have quite some other angles.
>
>I don't take the discussion as an argument at all.

I learn(ed) a lot. I hope others do so too.
Thanks again.
Peter