David, thank you very much for your extensive reply.
Please allow me to reply again. I left the "agreements" out.

>>Today, at last, I go along with 7 SP1. The app didn't even start. This, due to some stupid slightly different TYPE - SYS(2018) behaviour (see the other thread).
>
>I didn't really understand why you were relying on sys(2018) the way that you are. I use TYPE() to conditionally execute code:
>
>

if ( type( "OfSomething" ) )
>   ...
>endif

>
>I've never even known that this triggered the setting of any error messages, because it does not trigger an error that an Error() eventhandler or ON ERROR handler see. IMHO the contents of sys(2018) are meaningless outside of an error handler.

Yes, and it's exactly about that. Off-topic for this thread, but interesting anyway :
Once you got the idea to use SYS(2018) in order to create a recursive error handler (btw ... what about FoxBase doing the recursiveness intrinsicly ...), you already can expect the relation with "... outside of an error handler". So right, outside the error-handler (when an error is already in effect) SYS(2018) can be used to look whether an error occurred again. But please note this is a very simplified explanation.
Now, what I saw in VFP5, and today in 7 that is still true, is that VFP seems to use the similar in its internal workings. So for example (VFP) the TYPE of a variable which doesn't exist, internally generates a kind of error, causing SYS(2018) to be filled with that variable name. And, somehow that seemed logic for me at the time, and I started depending on that ...
Right now (7) I see SYS(2018) kind of randomly filled with not the argument of an IF, but with something subject to an object reference, but, SYS(2018) is filled at the moment of executing the IF command. But, not "always" at all, and the further line I don't see yet. What I do see however, is that the content of SYS(2018) has become something not to depend on anymore, that is, not even from within the error handler in effect. Hence, once in there "some" IF is executed before asking for its contents right after the error, it doesn't say anything anymore.
All together it was - and still is so, that VFP internally uses the SYS(2018) just as well. For itself or so.

Our use case (besides general recursive error trapping) is the setup of the tables needed for some function, never knowing in advance which tables will be addressed to in practice. See it as an array that contains all the tables the function could use. The OPEN routine is rather intelligent, and it won't open tables that aren't used anyway, and when it opens, it opens some groups of tables. See this as the functional program encountering a SELECT cTableName, but the table isn't open. So the error handler does it. But NOW all kind of stuff can go wrong, thinking of exclusive use etc.
There is much more to it, but this is the general idea.


>
>>At the very same day I ended up with corrupted VCXes already. "I should have known about the W2K SP2 ...". Come on.
>
>This is an OS level problem, not a VFP problem. VFP is very badly affected though. Backups and VSS help mitigate most of the problem.

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 ?


>>a.
>>VCXes can get corrupted. Though I didn't experience it from power failure or shutting off PC's or similar, there are just things you cannot do on them. A lot of it is related to dragging from one class to another, especially when they are on different drives. Okay, so don't do that.
>
>In all of the VFP development I've done since VFP3 I've only had a couple of VCX corruptions, and I never lost more than the amount of work from the last backup or checkin.

Me neither. But the problem is, when do you encounter the corruption ? It's no problem at all (anymore), and I can well live with it. Just know what you can and cannot do. So in general this is a con, but for me it doesn't count.

>
>>b.
>>I can't ever imagine why, but VCX is a single user environment. No matter VSS or the kind, it's completely stupid. This BTW is the first cause for corruption. In VFP5 it is anyway.
>
>A single PRG is single user in context of VSS, so how do you work around that? You don't put all of your classes in one prg. The VCX corrollary is to not put all your classes in the same VCX.

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.

>
>>c.
>>VCX works with Memos, always subject to corruption. It's not for nothing that the app doesn't use Memos at all and we created our own "memos". It just sucks. But, the visual classes let you make work with Memos ...
>
>again memo corruption just has never been a real problem for me. Having the code and properties in memos makes it much easier to write class documentation tools.

I just agree here. It's not THE reason, but A reason once it comes to arbitrairy decisions ...

>>e.
>>VCX seems not to be designed for the production environment. I mean, isn't it stupid that the source has to be removed explicitly ? It looks like a toy for this matter.
>
>VFP3 shipped with a tool to remove the source from the EXE. For the clients I've worked for having the source code exposed is not a problem, but I understand the need for some developers to remove it. In VFP6 projects hooks made the removal effortless.

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

>
>>f.
>>PRGs allow for distribution at the level you like, as long as you don't create a build from them. Note that we don't build anyhow, except from some startup stuff. Besides this, the VCX is always redundant (better : related) to PRGs anyhow, so an "upgrade" must go along with the VCXes. Better build, you say. Yeah, but sure not for the 5M lines of code (in our case to be done each day since we have new releases (to distribute) each day. Really).
>
>I don't understand what you are saying in this one Peter.

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

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 ?

>
>>g.
>>PRGs allow for any "visual" structure you like. What's together in the one PRG is up to you, and what's "procedural" under eachother is up to you.
>
>I'm not sure what you mean here either. Classes can be packaged in VCXes by whatever architectural design you want.

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.

>
>>h.
>>I don't think "hooks" can be made without PRG's as part of the complete class. So, once you are into that, it may be better to have all in PRGs.
>
>Hook patterns work with VCX based classes.

Okay, good thing. The web-app uses them (VFP6), and I never tried to investigate it from the VCX point of view.

>
>Issues with VSS can be handled by proper packaging of classes together into classlibs. To deal with cases where we have more than one developer working on separate classes inside the same classlib we do "logical" checkouts of individual classes into developer classlibs, the developer then checks into a testclasslib, once it passes testing the classlibrarian checks the class back into the real classlib. These moves of classes between classlibs is as easy as dragging a class from one lib to another in the project manager. This operation would be harder and more error prone in a PRG classlibrary.

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).
The main point is though, that we hardly can separate our momentary two VCXes into more. So it won't do (or, not enough).

>
>>If you, or anyone else could enlighten some real deterministic do or don't, I ask you, please say so. For now I can't decide really. But I must say, a "generate source" from the classes could come up with some "impossible". I've never done it.
>
>If you have classes that have a lot of containership you are going to have a harder time pulling the code and properties out into a flat PRG. If you have code attached to any of the contained objects you'll have to create each one of them as an explicit subclass.

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

David, I sure hope you don't find me "fighting" your statements. In fact, I now have quite some other angles.
Your lines are highly appreciated. Thanks.

Peter