>Peter,
>
>Are you trying to edit the exact same classlib file in both VFP5 and VFP7?
>
>I surely would not do this, I think you are setting yourself up for catastrophic failure on both platforms. Copy your VFP5 code to a new directory tree where you can you use VFP7 only on the code.

Nope. As I tried to say in the below (previous message), this is merely about me finding the reasons that things get "corrupted", and VFP5 by "automation" being able to to that. So, VFP5 auto-recompiles the classlibs once an VFP5 app is run over them. So, THAT shouldn't be done as well. However, as it turned out yesterday (via another thread) it's VFP7 on herself being able to perform the below implied stuff. Hence it wasn't VFP5 doing this at all, but what remains of it (the below) is that VFP5 auto-recompiles in the wrong way (for herself). It's not important.

Furher what remains, is how the status can arise that methods won't save by crossing away the class designer only. Crossing away the individual Edit boxes helps in this case.

So, "corrupted" came down to "not saving only", but what can be captured by saving in the way VFP7 likes it.
What the h... can cause this to happen I don't know, but what I do know by now is that nothing (explicit !) helps to recover from it (so no Pack, no Compile Classlib), but something is there that can.

BTW, it could well be that from these troubles I have, the conclusion comes that it is perfectly save to let both VFP5 and VFP7 loose on the same VCXes. For what reason ? none I think. But whay not conclude it if it's so anyway.

Peter


>
>>Description update:
>>
>>As per today I think I know now what's happening. If anyone can add something to it, please do so.
>>
>>1.
>>I have a classlib compiled under VFP5;
>>Running that (development version) under VFP7 does not imply an auto-recompile by VFP7. All looks as if it's working, but for some things I can't sort out at the moment, because of anomalies subject to this thread.
>>
>>2.
>>Making adjustments to some method under VFP7 -at some time- won't show the adjustment, nor is it in the Memo field (of the VCX) concerned.
>>Compiling the classlib under VFP7 solves this. But a Pack solves it just as well.
>>
>>3.
>>Now I have the classlib compiled under VFP7;
>>Running that (development version) under VFP5 will imply an auto-recompile by VFP5.
>>BUT: this recompile makes the methods of some class disappear from the running app as well as the class editor. However the methods are still in the VCX's method.
>>Explicitly compiling the classlib under VFP5 makes all back to normal.
>>
>>Intermediate conclusion: When VFP5 implies its under the hood recompile, it doesn't make a good job of it. It rather destroys things than making them right (for herself). This is a bug in VFP5.
>>
>>4.
>>Again I have the classlib compiled under VFP7.
>>Running that in the runtime version (hence no auto-compile possible) of VFP5, it says the object was compiled under a previous version of Visual FoxPro (similar). I accept this as just the other version, so I can live with that.
>>
>>Intermediate conclusion: VFP5 can't run the objects of VFP7, which I find perfectly normal. Not normal at all though, is the fact that VFP7 (SP1) won't auto-compile a classlib for herself the proper way. And actually, it just runs ... But don't start touching the methods, because your adjustments won't come through. This is a bug in VFP7. Either in the area of the auto-compile not working, or the fact that adjustments won't come through. Let MS decide.
>>
>>5.
>>All normal PRGs compiled under VFP5, run under VFP7 (development version). They do not auto-recompile. IOW, VFP7 has the opportunity to auto-recompile because the sources are there, but is just uses the existing FXP's.
>>I can't decide whether this is in the buggy area, but it is consistent with the not auto-compling of the classlib anyway.
>>
>>6.
>>The runtime of VFP7 just runs all of the VFP5 compiled stuff. In the end this is consistent with 5 and 1.
>>
>>7.
>>The runtime of VFP5 won't run the VFP7 compiled PRGs. This is consistent with 4.
>>The development version of VFP5 will auto-recompile the VFP7 compiled PRGs. This is consistent with 3.
>>But: The number of bytes of the both compiled versions (FXP) is exactly the same. This makes me conclude that the both versions only differ in their version-info (7 vs 5) and it seems rather stupid that no upwards compatibility is provided here. I'd say : only because VFP5 says so. And I am sure : when I'd change that byte in there being different, VFP5 just will run it. That is, as long as no VFP7 specific features are in the PRG.
>>Anyway I cannot find the consistency in a. not auto-compling the VFP5 source by VFP7 and b. once VFP7 done that, VFP5 won't run anymore.
>>In the end though, this is consistent with 4.
>>
>>This all makes me think that there is really no reason to provide me with the problems of not being able to run both versions mixed (as long as no VFP7 features are being used). And remember, this is caused by one thing only : The class editor of VFP7 destroying (btw invisible) things, when applied to a VFP5 compiled classlib. It destroys source when the (VFP7) compiled derival of it is not present.
>>
>>I know, Dragan tried to explain it, but a. something must be in the object (Memos) causing the Editor to flaw, and b. why the heck will it just run normally (the same VFP5 object) !!!
>>
>>In the very end this is (IMO) about just one major bug only : the VFP7 class editor. And o yeah, you can solve it by not letting VFP5 loose (just running) on the VCX anymore. But is this in the documentation ? and doesn't imply all other that it just could be done ?
>>
>>Lastly, I keep on thinking that my "cyclic relation" is not allowed, because so far it's only that place where
>>a. Adjustments won't get saved under VFP7 upon VFP5 compiled VCX;
>>b. Methods disappear under VFP5 and VFP7 after a VFP7 compiled VCX auto-compiled under VFP5.
>>
>>Can you follow ?
>>
>>I'm pretty sure this is to be continued.