A few thoughts... If I'm reading this right you're saying that mainform.resize is being called after the CANCEL? Then the form object must still be in scope and is not being released.
I tend to not directly call the Destroy event. I don't recall exactly why but calling Release will trigger the Destroy event. Are you using any 3rd party classes or framework? Is there possibly some inherited method code that you're not seeing because the parent class source is not available? Have you tried generating a coverage log to see exactly what's firing and in what sequence? Any code in the form level error method? Put some code in the resize method that you can set a break point on or put an ASSERT .F. in there so you can invoke the debugger when that method fires. -- rk -----Original Message----- From: ProfoxTech [mailto:[email protected]] On Behalf Of Ken Dibble Sent: Tuesday, October 07, 2014 1:07 PM To: [email protected] Subject: RE: Extreme Case of PRG File Corruption? >I'm not quite clear on why you're doing all the SHUTDOWN stuff yet >leaving your main form in scope? I'm not deliberately leaving my main form in scope. I have no idea why the last thing it returns to is MainForm.Resize(). Long before we get to the point I've described, the form has been closed and its Destroy() has executed, and CLEAR EVENTS has been issued. I've said for years that the VFP event chain doesn't always work exactly as advertised. But leaving that aside, RELEASE ALL EXTENDED should have killed the form, and if it didn't, then CANCEL should have. Which, in fact, it does if that *completely unrelated* class definition is readable in the general prg file. The existence of remaining commands after CANCEL is an artifact of the debugger, isn't it? As best I can tell, it's got its own memory space that it works in somehow, which is what causes heisenbugs. I've also said for years that VFP 9 caused the debugger to become less reliable. It's like this: *** All the shutdown commands in the world have already executed here, beginning with MainWindow.Destroy() CLEAR EVENTS .... **** and ending with CANCEL The next thing in the debugger, though, is this: MainForm.Resize() THIS.MemberObject.SomeMethod() ...MemberObject.SomeMethod() * Free procedure from the general prg file, which is completely * unrelated to the form class definition which was commented * out in that file. two(someParm) ,,, ... .... The form's Resize() method is never explicitly called at all, either by the member object, or the form itself, or any of its parent classes, or by any other code in the system. The Resize() event is firing according to rules imposed on it by VFP, but the only thing done to the form that triggers this process is to click its "X" close button. As far as I know, closing a form is not supposed to call its Resize() method. If it was gonna hang, it should have hung in Destroy(), no? Not Resize(). It's just crazy. >VFP will search its path and will stop at its first match. (This is a >classic way to be running the wrong version of something because VFP >finds something you did not intend to leave in its path; a rouge form >or FXP >or...) Since the class definition is inside the form it's going to find >that code regardless of other pathing or SET PROC stuff, right? The code only exists in one place. If I comment it out in the general prg file, I uncomment it in its new location, and vice-versa. I also can explicitly delete the general.fxp file to force a recompile and still get the same result. * If the class definition at the bottom of this file is commented out, * this procedure works at program startup, but during program shut * down, it bombs out with Error 1 ("file not found"), because * SET("PROCEDURE") returns "" at that time. * * If the class definition at the bottom of this file is not commented * out, then at shut down, SET("PROCEDURE") returns this prg file * (among many others), and this procedure runs just fine. PROCEDURE Two LPARAMETERS nParm code, etc., entirely unrelated to anything else. ENDPROC * This procedure has been moved elsewhere, where it works just * fine under all circumstances. (It is only used in isolated * circumstances, and the form is not in existence during the * shutdown process.) *PROCEDURE Three * oForm = CREATEOBJECT("MyForm") * * code, etc. *ENDPROC PROCEDURE Four code, etc. ENDPROC * This class has been moved elsewhere, where it works just fine. * However, commenting it out here causes a call to Two(), above, * to fail during shutdown because the entire procedure file, as * well as every other procedure file, has been removed from memory * at the time. *DEFINE CLASS Myform AS form * code, etc. *ENDDEFINE The commented-out form class definition is NOT my main form. The form it defines is NOT in existence at the time the error occurs. Thanks. Ken Dibble www.stic-cil.org [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/DF1EEF11E586A64FB54A97F22A8BD04423C5D78F26@ACKBWDDQH1.artfact.local ** 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.
