David,

Your last remark first :

>
>How long do think the conversion or your app from 5 to 7 is going to take? It really should be a trivial effort. Whenever I changed versions of VFP from 3 to 5 to 6 to 7 I copied everything to a new directory tree and made what few changes were necessary to get the project up and running under the next version.

I've been there from FoxBase+ to first version of FoxPro (don't even know what it was, should be 1.x). It didn't run (my app) at all I even had MS visited (!). BTW, FoxBase+ didn't run either, but is was my own contribution (close contacts with Fox Software) that improved it sufficiently. Please note that we were the first to come up with some real app in the MU environment back then (end of 80's).

FoxPro 2.00 didn't run because of many memory problems. It ended up with a near lawsuit against the distribitor for Europe, because I just refused to pay the few hundred $ for that version. But, when time elapsed, 2.00a came along, and the memory problems were fixed. I received the 2.00a for free and the lawsuit stopped.
Still we were spending lots of time to create workarounds for all you can think of.

2.5 came about, and that was the big improvement. It allowed for more than 25 files to open, and now we could really start ...

Then 2.6 (Dos) came along, and we just skipped that version because of immediate problems again.

Then there was VFP 3.00, and it just did not run at all. Again memory leaks and related stuff. We skipped that. Obviously this was in the middle of the attempts to recreate the app for the VFP environment.

5.00 came along, and that just worked fine. We still use that today, and no SP was ever installed (hence needed).

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.

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). At the very same day I ended up with corrupted VCXes already. "I should have known about the W2K SP2 ...". Come on.


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

This app is worked on for more than 100,000 hours, and I guess it stresses all from the Fox that can be stressed. And we don't even use SQL ...
But, already at the time of FoxBase+ we used function keys. Think of it, it couldn't be done back then but we did it anyhow. Objects ? no way they existed in the Fox back then, but we had them anyhow.

All runs on top of some system environment (all normal Fox code) with the size of an average midsize app (around 350,000 lines of non-redundant code); about all in there deals with better speed, workarounds for bugs (most of them still being there ...), logical DB-commands not provided but which should exist, and further what we today call the framework. Submitting a form runs over 30,000 lines of code. Within a fraction of a second that is.
Moral : the Fox is stressed possibly more than it was designed for. But no problem, we deal with it as it comes. Just accept the problems and work around them. And take the time it needs ...

Then your other remark :

>
>>Ed, thanks. Where I already drew some conclusion that my earlier decision to set it all up in visual classes wasn't the best decision, I think this really is the answer. No danger at all in it. You just pushed me to do it now.
>
>That's a serious overreaction. IMHO VCX classlibraries are superior to PRG based ones. You might check a couple of the articles over on the Wiki.

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.

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.

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

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.

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.

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

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.

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.

i.
OTOH I think that things can be done in the VCX which can't be done in PRGs. I must say, it's just a feeling. Has to do with inheritance somewhere and dropping one class onto another.

j.
Not sure again, but I expect OCXes to allow for different possible manipulation in both cases.

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.

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.

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.
So for now, I'd really like to listen to you all.
Thanks David,
Peter