Hey all,

I recently posted about a problem I was having with a screen becoming non-closable under certain scenarios. The screen would go completely dormant and could not be unloaded (and the app could not be closed). Clearly a case of stubborn, dangling references.

I got great advice from several folks, and one tip was particularly pertinent...look for WITH...ENDWITH statements where ActiveX controls are involved. That helped me isolate code down to a single construct that was making the form unclosable -- a FOR EACH loop involving an ActiveX ListView component.

I went from something like:

FOR EACH ListItem IN THISFORM.ListView.ListItems
  IF ListItem.Checked
    llFoundOne = .T.
    EXIT  
  ENDIF
ENDFOR

to:

LOCAL loPointer
loPointer = THISFORM.ListView.ListItems
FOR EACH ListItem IN loPointer
  IF ListItem.Checked
    llFoundOne = .T.
    EXIT  
  ENDIF
ENDFOR

and my troubles disappeared. I didn't even have to explicitly RELEASE loPointer...having it go naturally out of scope was enough to take care of it. I changed all of my WITH...ENDWITH and FOR EACH contructs to use a local pointer when an ActiveX control was involved, and now my form closes under all scenarios.

I should mention that in VFP 6.0 (before I made all of these changes), the form always closed just fine and no aberrant behavior was apparent. But in VFP 7.0 the problem manifested itself.

So, is this a bug? Are there issues with VFP 7.0 when it uses implicit references in WITH...ENDWITH and FOR EACH constructs? Are there other implicit references that I should watch out for? I would build a sample to show this more specifically, but it appears to require a combination of events for the scenario to arise... In many cases there would be a FOR EACH in use but the screen _would_ close just fine. It was only when a FOR EACH got used and then another form got called up that the closing seemed to have problems...

Any enlightenment would be vastly appreciated...

Thanks,
JoeK