On 10/24/06, Jack Skelley <[EMAIL PROTECTED]> wrote:
Jack, I scanned & ocr'd the relevant text. Didn't do any correction though. Hope this explains it & Whill doesn't mind <s> A+ jml Form (.SCX) file corruption There is a bug that has existed in the Form Designer ever since Visual FoxPro 3.0. Folks at Microsoft have observed this bug, so it isn't entirely in the imagination of those of us who have encountered it in the field. The reason it hasn't been corrected is that no one can consistently- reproduce it. Don't you hate those? Anyway, this bug has bitten me a half-dozen times over the years. It wasn't until I had a co-worker who encountered this one on a regular basis that I stumbled on what appears to be a fix. The behavior in question is the actual swapping of method code. The code you placed in method A will suddenly appear in method B, and vice-versa. The most common place this seems to occur is between the BeforeOpenTables and AfterCloseTables event methods of the Data Environment. However, i've seen one case in which the entire set of form-level methods was scrambled. Although it takes a while to figure out why your form is blowing up in your face, it isn't too big a deal to move stuff around and put it back where it belongs. The frustrating thing's that the next time you edit and run the form, it'll move the method code around a^ainl If you examine the .SCX table, you'll see that the form source code is all stored in a single Methods memo field. When the Form Designer closes this file, the source code in the Methods field is compiled to pseudo-code and placed in the ObjCode memo field. This problem appears to involve something that actually takes the code from between one PROCEDURE...ENDPROC and moves it to another. How can this be? The answer (I think) is that, contrary to our expectations, it is not a one-way relationship bettween the Methods field and the ObjCode field. To illustrate this, create a form, place some cc de in one of the methods, then close and save the form. Open the .SCX table, and examine th5 record representing the form (usually the third record—you'll see "form" in the Baseclass field). You'll see the code you just placed into the form method. Examine the Objcode field, arjd you'll see some gobbledygook that represents the compiled version of the code. While ycju're looking at ObjCode field, erase it—select the entire cóntents of the memo and hit the <pelete> key! Now, close the table and reopen the form in the Form Designer and examine thé method into which you placed some code. It's empty, even though you didn't touch the cóntents of the Methods field. To verify that you didn't erase the wrong field, reopen the .SCX taple and look at the Methods field. The code is still there, isn't it? ; This leads to the fix I've discovered for the swapping-methods behavior. Open the form's .SCX file as a table, REPLACE ALL ObjCode WITH "", close the table, and then issue the c<immand COMPILE FORM <formname>. This will remove all the object code and force Visual FoxPro to recompile all of the code in the Methods field. So far, this seems to do the trjck. By the way, this trick also seems to be a generic solution for forms that seem to be "cor-nlpted." I've had forms that the Form Designer refused to open. Purging the ObjCode fields ai^d recompiling has on several occasions restored these forms to a usable condition. _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
