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
_______________________________________________
Post Messages to: ProFox@leafe.com
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/5.2.1.1.1.20141007163353.01f4f...@pop-server.stny.rr.com
** 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.
