>>>>>>Not a solution of the cause, but the solution to continue, appeared to be a PACK of the VCX. Since there weren't any deleted records in there, somehow the Memo file must have got corrupted. The Pack, though, didn't say anything. It just did its work.
>>>>>>
>>>>>
>>>>>Are you running on Win2K without SP2 or SP3 installed?
>>>>
>>>>Ed, I'm afraid I am (SP1). So I guess I missed something, uh ?
>>>>
>>>
>>>Yep - there's a not-so-subtle bug with Win2K's deferred disk caching that results in VCT/SCT files not actually being written to the media except on a normal shutdown and termination of Windows; another not-so-subtle bug in the disk device manager caused IDE drives to reenable their write caching after each reboot even if you disabled it! The result; lots of trashed memos for forms classes and the like. Fixed in SP2 of Win2K.
>>
>>
>>Thanks Ed.
>>Well, the auto-update feature of Windows (MS) sure didn't tell me that all. In fact, I only needed some SP for IE5.5. And ehh, the download of VFP7 SP1 didn't tell anyting either. IMO that's the least what could have been done ...
>>Anyway, I just downloaded the 80MB or so, and will have another go with it.
>>
>
>
>So
now I don't know what happened (happens) anymore ...
>
>W2K SP3 is installed, and after a restore of the proper VCX all seems to go okay now. But, I was working the whole day "okay" before this happened.
>BUT :
>I can't open the class in VFP5 (no SP) anymore.
>
You can to some extent, but there are consequences to using features of VFP7. One way to preserve your work is to use Visual SourceSafe or another source code management product; the SCCTEXT.PRG which coverts the visual class/form libraries isn't subject to many of the consequences of visual conversions, and you can always rescue source from there. VSS would have saved your bacon the first time as well...
>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.
C#...because you do have a choice!
