Peter,

>Yes, and it's exactly about that. Off-topic for this thread, but interesting anyway :

I moved this part of this thead over to the other thread for the sake of continuity.

>I know. I didn't try to blame VFP, but I expected the upgrade for SP1 at least to recognize this, and urge for the upgrade to W2K-SP2 first. If it weren't for you out here (UT), how was I to know ?

This is one reason that developers ought to be part of online communities and familiar with searching MSDN.

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

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

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

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

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

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

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

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

>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?

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

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