>>There are consequences as far as variations in native classes, ActiveX behaviors, installation requirements, supportable runtime environments. Unless you have Win9x as a major issue, I'd scrap VFP5 for VFP7. Otherwise, you'll be debating upgrading from VFP5 to VFP8 when the beta for VFP9 gets released. Or not.
>>
>
>This is not exactly what I meant. Here it is :
>
>Everyone is screeming that upgrading from 6 (or 5) to 7 doesn't (shouldn't) give problems. Since I already have the bad experience from 5 to 6 when 6 came, I just cancelled that an took a very deep breath. So here I am again, and within one day I am kind of stalled. And, I didn't start the *report* threads for nothing; it's just my expectation of it all.
>
>Now, depending on what I run into, I can solve things in code by means of IF VFP7 do this - ELSE do that (etc.). But what if the program won't compile ?
>
First, they will compile, but the structures of the classlib or form may be irreversibly different from VFP5 to VFP7. But there's a really easy solution for this. Non-visual classes. Source code is not sensitive to the data structure in a code-based class or form definition. If you find that you must go back and that you've migrated irreversibly something that must be rolled back that you haven't provided for with an SCC product, you take the form or classlib, run it through the class browser and emit source code. Face it, text files is text files. And that's all a class defined in code is - source code text.
Do not pass Go, do not collect $200...
>So, I sure don't want to maintain VFP5 at all, and once I am ready, all users go to VFP7 at once. But what if I got stuck somewhere ? I can't keep having an un-upgradeable version forever.
>
You're making an assumption that you will have performed a forward migration, rolled it back, and then had to maintain code by hand. You never get to the point where you can't migrate. You're making excuses.
You can certainly try implementing it in dBASE III+; the list of known bugs is well-known by now, and the feature set is well defined. It sucks, but it is stable and well-defined. Or ust dump xBASE in favor of anothetr product. Or you'll still be bitching about how awful having to write @ SAY...GET is 5 years from now.
>Therefor it is my approach to
try whether all can be kept into the one version, and as off the status of right now, I couldn't fall back to VFP5's classes. At all I do I create a backup, so that's not the problem, hence VSS won't help for that.
>Again, I won't be using new properties in order not the challenge the worse. That is, not until all is up and running.
>
>You probably can imagine that when stuff like TYPE is behaving differently, and it could be about REPLACE and that kinda commands just as well, I will have some big problem, because that stuff has nothing to do with visual - object - event aspects, and hence they are in code everywhere. And my code consists of near 8,000 prg's and 5M lines. Sure I can re-generate it accordingly, but when that starts to happen, there will be a longer time of "no upgrades possible" again. This where users expect to have upgrades any time they like or need. This is every day in theory ...
>
>Hey, I am not really asking for an answer, and I should be able to cope with this myself. But maybe it's already defined that moving from 5 to 7 is not by "doing nothing" at all. And I just began !
>
>But anyway, this is exactly why I started this thread(s) : register what one
might bump into when it's about an average large application. It should encounter some things ... And it does.
>
>But any help always very welcome.
