Peter,

>I've been there from FoxBase+ ...

There was a huge change from FPx to VFP3. I chose to completely rewrite all my code, that took a long time.

>Then there was 6.00 (first version), and the first thing encountered was the help of VFP5 on the same PC not being reachable anymore. That is, when following the install instructions from 6. Then, the app wouldn't run at all. I saw messy things in the VCX, and I just quit at that time.

I've never had any problems keeping multiple versions of VFP running simultaneously. Up until I moved this notebook to XPPro I had 3,5,6 and 7 all running, although I rarely ran 3 or 5 any more. Since I installed XP I've only loaded 6 and 7. And like I said before I replicated the source code base to a new tree for each version so I don't have problems with one version stomping on another.

VFP3 was stable enough, VFP5 was even better. VFP6 was a whole lot better than VFP5, especially as far as new features and the IDE is concerned. VFP7 is an order of magnitude better in the IDE area.

I'm sorry that you never got VFP6 up and running properly.

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

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

>So yes, it should be trivial, but history shows it probably is not. And in advance I started the thread(s).

>My base :
>1. The ERP app running with visual classes;
>2. Our web-app (the CMS to heartprofit.com) running with non-visual classes.
>IOW, I know both environments. From this, these are my feelings :
>
>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.

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

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

>d.
>VCX allow you (expecially the beginner) to see the defaults of properties (and methods). Not only as from the base class behaviour, but also from the inherited custom class behaviour. Important for the co-developer too. PRGs obviously are in lack of this.

Access to setting properties via the property sheet is a big plus. And builders can not work on PRG based objects.

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

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

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

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

>k.
>Though I didn't do it yet, I expect a commercially distributed class library including source, better to be a visual class. Again this is the newbie aspect.

I think most of the frameworks rely heavily on VCX based classes.

>These are my very personal aspects to some decision.
>David, after reading FoxWiki as much as possible (search on VCX), the above aspects didn't change. But as we all can see, my aspects don't lead to any definite conclusion i.e. decision. Well, not for me. You could be right in the overreaction. But let's say that where corruption is at hand it's worth 100 points. Against, that is.

Memo corruption just isn't that big of a problem IMHO.

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.

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