I'd highly recommend using ASSERTS for this kind of stuff instead of SET STEP. ASSERTS are ignored in the runtime environment so you avoid feature not supported errors in your EXE while still enjoying dev debugging on demand. ASSERTS and TRY...CATCH were some of the best things ever added to the product, imho.
You just taught me something. At some point the ALL keyword for CLOSE DATABASES would throw an error. Now it seems to work just as you might expect. :-) All the relative pathing and inferring can definitely cause agita. I think I mentioned in this or some other recent thread, I try to be as explicit as possible now whenever the language allows me to do so; IN clauses and alias/workarea references inside function/method calls and so on. And if you use INCLUDE files things can get even more fun. I forget who it was, maybe Bernard Bout, wrote some good blog post about INCLUDE files and pathing. The other tool besides the coverage log you can have a play with is event logging. That should at least show you when the RESIZE method is getting called. -- rk -----Original Message----- From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Ken Dibble Sent: Wednesday, October 08, 2014 11:00 AM To: profoxt...@leafe.com Subject: RE: Extreme Case of PRG File Corruption? >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 [excessive quoting removed by server] _______________________________________________ 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/DF1EEF11E586A64FB54A97F22A8BD04423C5D793AB@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.
