>>Thus : within VFP7 (SP1) all seems right, and this only one class from the VCX at opening from VFP5 it tells that the VCX is not an object file. The other classes still can be opened from this VCX;
>>Where before the PACK (from within VFP7) helped, now it doesn't anymore.
>
>You probably have to COMPILE CLASSLIB.
>
>>
>>You know, I can live with this, as long as all keeps going well with the "conversion" to VFP7. But if not, I'm in kinda trouble. So I guess I need to be able to fall back to VFP5, but, I even wonder whether that's possible at all.
>>Is the VCX downwards compatible ?? I mean (too) : when I start using a property that's new in VFP7 opposed to VFP5, what will VFP5 do with that ?
>
>Puke; in many cases, you can write a UDF() to provide similar functionality for some of the new functions. A few of the properties have really interesting consequences if you want to maintain a common code base back to VFP 5.
>
>>Not that I've done it (nor intend to for now), but anyway ...
>
>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 ?

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.

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.