So everything is PRG based? No VCXs or other binary source that could be part of your object hierarchy? The behavior you describe does indeed seem puzzling. What about things like SET PROC calls in different parts of your framework?
FWIW my shutdown routine uses a different sequence than what you've shown. First I loop through the forms collection and RELEASE any open forms. I then explicitly release various procedure files in the order I want them released. From painful experience I learned to be explicit instead of RELEASE or CLOSE ALL. (I have not used the EXTENDED keyword on the RELEASE. Gotta go look that up...) You never know what order VFP will RELEASE things and that's a recipe for C5 errors. After that I release a specific library that handles a bunch of Windows API type stuff. Only after all that finishes do I start to take out the sledge hammer and do: SET SYSMENU TO DEFAULT CLOSE TABLES ALL CLEAR PROGRAM CLEAR RESOURCES RELEASE ALL SET PROCEDURE TO SET CLASSLIB TO SET LIBRARY TO ACTIVATE SCREEN CLEAR CLEAR EVENTS CLEAR ALL CANCEL As you can see nearly the last thing I do is clear the event loop. If you're firing off a CLOSE ALL before you do the rest of your shutdown housekeeping I would expect the unexpected. -- rk -----Original Message----- From: ProfoxTech [mailto:[email protected]] On Behalf Of Ken Dibble Sent: Tuesday, October 07, 2014 5:07 PM To: [email protected] Subject: RE: Extreme Case of PRG File Corruption? >I tend to not directly call the Destroy event. I don't recall exactly >why but calling Release will trigger the Destroy event. Nothing is explicitly calling the Destroy() event method. I just know it has run because the form has already disappeared when the error occurs. Because I have a framework that has several built-in shutdown processes, I can't just issue CLEAR EVENTS in the main form's QueryUnload() either. It is, unfortunately, more complicated than that. But when everything works properly (which, it ALWAYS DOES except if I comment out that--I repeat--*completely unrelated* form class definition in the general procedure file), then it goes something like this: User presses "X" button. QueryUnload() runs, issues NODEFAULT, executes an ApplicationManager method that asks the user "Are you sure you want to shut down?" (Yeah, I know, I know... except that people do close the window accidentally and then get mad because nobody stopped them and now they have to log back in. Sometimes you just can't win...) If the user says s/he is sure, then the ApplicationManager starts the shutdown process. That process will execute code in various non-visual objects to close windows, do backups, etc., then calls a procedure that issues CLEAR EVENTS and does all of the final exit code. Eventually, control returns to QueryUnload() again. It has to, because that method has to know if the user said s/he wasn't sure. Anyway, at that point, all QueryUnload() does is call THISFORM.Release(). There is no clear reason why the debugger ends up at Resize(). And if an error occurs at any point in the process the system bails: It sets a PUBLIC variable to .T., which causes all of the nonessential processes in the chain to be skipped and we go right to the final shutdown steps. >Are you using any 3rd party classes or framework? Nope. >Is there possibly some inherited method code that you're not seeing >because the parent class source is not available? Well, normally I would get "source code unavailable" in the debugger then, but just to make sure, I deleted all the .fxp files in the framework and in the project and retested. I don't get any more information in the debugger from doing that (see below for what I get). >Have you tried generating a coverage log to see exactly what's firing >and in what sequence? I haven't. I can try that tomorrow. >Any code in the form level error method? Yes there is. All it does is call the framework error handler procedure though and pass through the parms. >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. Well I have debug code in my framework so I can invoke the debugger when an error occurs. At the point during the shutdown sequence when this happens, the debugger insists that the stack goes directly from the READ EVENTS in my main loop method (that is invoked when the program starts) directly to the Resize() of the main window. The debugger obviously is lying, and something is destroying or obscuring the rest of the stack--or maybe it's just that after CANCEL, the entire thing is supposed to be out of memory and most of it is. Anyway...all this is not my real problem. My real problem is, how can moving a completely unrelated class definition from one .prg file to another trigger this insane error? 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/DF1EEF11E586A64FB54A97F22A8BD04423C5D791BC@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.
