FIX: VFP 3 Form or Class Modified in VFP 5 Loses Method Code (163023)
The information in this article applies to:
- Microsoft Visual FoxPro for Windows 5.0
This article was previously published under Q163023 SYMPTOMS
Modifying a form created in Visual FoxPro 3.0 or 3.0b may, under certain
circumstances, result in temporary or permanent loss of event or method
procedure code.
-or-
Instantiating a class created in Visual FoxPro 3.0 or 3.0b may, under
certain circumstances, result in temporary or permanent loss of event or
method procedure code.
This can happen if both of the following conditions are true:
- Code is contained in method or event procedures within dependent
controls, such as the following:
- Option buttons in option groups
- Command buttons in CommandGroups
- Grid columns in grids or headers within columns
- Pages in PageFrames
- The Visual FoxPro 3.0x form is modified under Visual FoxPro 5.0 without
being first run or compiled under Visual FoxPro 5.0, or the Visual
FoxPro 3.0x class is instantiated under Visual FoxPro 5.0 without being
first compiled under Visual FoxPro 5.0.
This loss of code does not occur if any of the following are true:
- If code is not contained in dependent controls.
- If the Visual FoxPro 3.x form or class is run or instantiated prior to
modification in Visual FoxPro 5.
- The form or class is compiled with COMPILE FORM or COMPILE CLASSLIB
before form modification or class instantiation.
RESOLUTION
Issuing a COMPILE FORM or COMPILE CLASSLIB command against the form or
class library sometimes, but not always, repairs the file in question. If
any other changes are made to the form or class and the form or class is
saved, compiling is not likely to retrieve the lost code.
STATUS
Microsoft has confirmed this to be a problem in the Microsoft products
listed at the beginning of this article. This problem has been fixed in
Visual FoxPro 5.0a.
Modification Type: | Major | Last Reviewed: | 10/16/2002 |
---|
Keywords: | kbBug kbvfp500aFIX KB163023 |
---|
|