>So everything is PRG based? No VCXs or other binary source that could
be >part of your object hierarchy?
Oh yes, there are several vcx classes involved but I can see all the code
in them if I step through it. It's just that the debugger Call Stack window
doesn't see them at the time the error occurs.
What I finally did was just start issuing SET STEP ON and stepping through
the code. Unfortunately, as Carl Sagan might have said, there are "billions
and billions" of lines of code that execute during my shutdown process
(well, a few thousand anyway). Eventually I narrowed it down though...at
least enough to draw a conclusion.
(And on the way I also found and fixed a bug in a Timer() method that was
confusing the issue, so that was good news.)
>The behavior you describe does indeed seem puzzling. What about things
like >SET PROC calls in different parts of your framework?
No, I centralize all of those during the start-up process.
>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.
<snip>
>If you're firing off a CLOSE ALL before you do the rest of your
shutdown >housekeeping I would expect the unexpected.
Yeah, in the end that's the real solution. I changed that line to CLOSE
DATABASES ALL, which is the really important part.
I think I added CLOSE ALL early on in framework development when I was
trying force VFP to release all of its stored classes from memory, so I
wouldn't get "Remove object from memory?" when I tried to edit something
after testing the program. Turns out there is no real way to force a
running program to do that, as many have pointed out over the years. Even
if I issue all the magic shutdown words as the program shuts down, I still
have to (re) do
CLOSE ALL
CLEAR ALL
RELEASE ALL
(or shut down and restart the IDE)
after the program ends (or just answer the annoying question affirmatively
and move on). So there's no point in a CLOSE ALL in my shutdown routine.
You are right that the main window isn't getting released; there is no
explicit code that does it. The only object reference to it exists in the
form manager, which does get explicitly released--but that doesn't cause
the form itself to be released. So after everything else is done, that form
is still there. In the normal course of things, before I moved that
*completely unrelated* class definition out of my general procedure file,
it would not error out, even though the code in it executed after CLOSE ALL
had allegedly cleared the required procedure file out of memory.
(I think SET PROCEDURE just creates a "path" statement. I think actual code
in those procedure files gets loaded into memory the first time it is
executed, and remains there without regard to the contents of the "path",
so that it can still run--at least at times.)
So, problem solved, and thank you VERY much for helping me think about it.
However, I still have no answers for the following issues, though I have a
theory about the second one. (I don't need answers; it is, as George Carlin
used to say, "a mystery".)
Why does the main form return to its Resize() method (actually, its parent
class's Resize() method) as the last thing it does, apparently as a
consequence of being removed from memory by the garbage collector?
Why did moving that *completely unrelated* class definition from one .prg
file to another cause this problem to start happening?
I have seen strange things in VFP. In particular, I have seen typos and
other errors in the code run just fine without causing any problems until I
change something relatively nearby, though not necessarily related. Then
the bad code suddenly starts throwing errors. In particular, missing
ENDPROCs, ENDFUNCs, and ENDIFs can be ignored, and then suddenly be
detected, in this way.
I can't find any of these in the procedure file in question, nor do I want
to spend hours counting and comparing beginning and ending code-block
lines. The thing works as compiled now, with the code reorganization I
wanted, so I'm satisfied.
But my theory is that the compiler, when taking a particular path through
the code, sometimes can "infer" the required keyword and stick the
appropriate token into the object code and "fix" the bug on the fly.
However, if I change something that causes the compiler to take a slightly
different path, it no longer makes that "inference" and the bug is detected.
Thanks to all who helped!
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.20141008103024.01f75...@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.
