Many developers have production applications running with one version of a runtime yet do development in a later version. This lets daily work take advantage of the newer productivity tools while the final application is still using the older runtime. The challenge here is ensuring you don’t use features in the newer version in code that will run in an older version.
A great example is using MESSAGEBOX() to show numbers or dates. Recent versions of Visual FoxPro let you do a MESSAGEBOX(5) and it will do the internal translation between the numeric value and the string equivalent. Seemingly a very simple function yet if you get used to using it, and then have to run on an older version of FoxPro that doesn’t support it – you get a invalid type error message.
Likewise with VFP 9 and VFP 8 but this time, it’s something a little more hidden. VFP 9 allows developers to take advantage of MemberData, the ability to extend the property sheet further with your own goodies. VFP 8 doesn’t have this feature. Yet when working with the two versions side by side, it always seems as though you can write in one and then produce in the other. This is almost true.
If you specify member data in a class in VFP 9 (and this can be done very easily using the add-ins provided on the Solutions Sample page), you won’t be able to edit them in VFP 8. Instead, you’ll get errors where VFP can’t find the correct memory variables. The solution is to manually open the VCX or SCX file, find the Properties field with the memberdata in it and remove it.
At the bottom of the memo field, you’ll see a line that says Name = “classname” but everything before it will be square boxes or binary data, just remove everything from the line that says _memberdata = and all the way down. Then you’ll be able to open your class again in VFP 8 and earlier versions.
Yes, you will lose your Memberdata (like Favorites, and advanced editors, etc) but the value of cross-version compatibility is far greater, in my opinion.