Finding hung References in Visual FoxPro
September 19, 2007 •
The Web Connection Web Control Framework has many places where there are referenced components and components that reference back up to the Page control so it's absolutely vital that controls properly unload. Web Connection handles this via containership and an explicit Dispose() method on all controls that clean up after themselves. This works well for the most part, but it can cause problems in some situations when a) somebody (ie. me <g>) forgets to implement the appropriate Unload code, or b) the controls are referenced in multiple locations and then removed from the collections resulting in the object never destroying and so Dispose() also never firing on the object.
These are known problems in VFP, but they are not obvious. In fact most of the time when you run into a problem with this you're probably far removed from the code that is causing it because most of the time the error is not immediately obivous. For example a Web Control Framework page will be perfectly happy running code. But if references are hung you will not be able to recompile a page with changes because the page will stay locked in memory - when a reference is outstanding the class can't be unloaded meaning the FXP file is locked and can't be unloaded.
So... the real question is how the hell can find out what control or controls are causing this damnable problem.
Just before you exit the application normally and BEFORE you do any final clearing out of the environment or variables add the following to your cleanup code:
SET STEP ON
CLEAR ALL
Clear all will cause all remaining references to be cleared and so you should be able to now step into the Destroy() methods of any objects/controls that have code in the Destroy method. Since all Web Control Framework controls are derived from wwWebControl which has a Destroy method you will step into that Destroy method if or into any that’s higher up the hierarchy.
You can now add the following watches to the debugger:
- THIS.Class
- THIS.Id
It most likely will not show up because it may already have been cleaned up by the finalization process, but Class should always show so at least you can isolate the problem to a particular type of control.