>A THISFORM.Release is not supposed to fire the QueryUnload, but in this case when I call Release, somehow the QueryUnload keeps firing, which calls the code that does the THISFORM.Release. But oddly enough, it's not nesting them because the call-stack window never shows more than one QueryUnload, even after several iterations via trace.

Ok, if anybody is interested, I figured out the problem and the solution. I also got a C0000096 error while tracing, which only happened once, but is worth noting for reference.

The problem was not the form trying to be rendered, but with an event loop gone out of control, brought on by the OLE web control.

First, I had a form with the web browser control in it and was using hyperlinks to trigger the oleWeb.BeforeNavigate2 method (for more info, see Foxpro Advisor, Nov 2003, Rick Strahl's article "Use Internet Explorer With Your VFP Applications").

From within the oleWeb.BeforeNavigate2 method, I was calling my form's "CLOSE" method to cleanup and .Release the form. I also had code in the .QueryUnload to call the same function (and never has been a problem until now...).

Calling THISFORM.Release is not supposed to fire THISFORM.QueryUnload, but since the form was releasing before the oleWeb.BeforeNavigate2 method finished, I believe some collaboration between the OLE control and the form caused the .QueryUnload to fire also. This setup a weird loop (until error occured anyway) that kept cycling from .Release to .QueryUnload without overloading the call stack (one actually finishes, then the other fires to start it all over again).

I solved it by putting a flag right before the .Release and then check for that flag in the .QueryUnload to see if it needed to also call the cleanup method.

I probably could have solved it another way like putting my cleanup code in the .QueryUnload and calling that initially, but then maybe it would have fired twice with this OLE thing going on.