Frank!

>One of them should be enough. However, if You issue Thisform.Release
>the QueryUnload is not called
>
>If ThisForm.QueryUnload()
> ThisForm.Release
>endif
>
>could be used or the release, You have used.

I just filled in Release() and QueryUnload() to cover my Close button as well as the system "X" closure...will add to Destroy though...sounds like a good idea...

I installed the latest service pack and finally got InstallShield Express to build me a runtime setup. Installed that on the target machine and I have the latest build now (9465) and still no luck, so I know it is just something I am doing wrong...

>Unload might be too late as there are all objects destroyed already.
>I use the destroy() as it always gets called and for most purposes
>not too late.
>
>Still I don't think this is the Hook, that hangs things up
>
>If You like (and possible with little effort) you can send me the
>form in doubt. Maybe I see something.

It is part of a larger app, and I don't want to put anyone else through the torture of wading through my framework. *smile* I will be able to find something, or will come up with a workaround. This is the only form I have this happening on as far as I can see, so at least it is a nice isolated case to learn from and firgure stuff out!

>What I hate about this is that it's really trial and error as
>I found no way to see *what* actually is dangling around. An error
>message like "Hey You idiot, You can't destroy object x as there
>is still a reference to it from Y" or something thelike would be
>*very* helpful.

No kidding...at least in design mode they could give us something like that.

>Even worse is that the variables in doubt show You a value of
>.NULL. or pretend to be not existent anymore while they or parts
>of them actually *are* still hanging around.

YES! I have seen that...says everything is NULLed out and yet there the form is...still hanging and worse, not letting the app close. If the app were able to close I would do a kludge fix and just hide this problem form instead of trying to destroy it, but since it prevents exiting from the app, I have to get this figured out...

>OH!
>
>Here is another Idea. I just had that lately. Maybe this leads to
>something.
>
>In this case I am using a VSFlexGrid - Control from a method
>FillGrid() (tried as method of the grid as well as of the form).
>When an error occured within this method (or was provoced by me)
>- while filling the Grid - My Error-Handler grabbed it, informed
>the user, and told him /her it would restart the application now.
>After that: nothing. Processor up to 100% and that was it.
>
>Forget about clear all, close all and quit. Nothing helped.
>
>There was nothing to find. Everything was programmed so clean.
>However filling the Control was covered by
>
>with this.Grid1 && or With this respectively
> ...
>
>endwith
>
>As soon as I took this away and changed it to
>
>This.Grid1.Blah
>This.Grid.Blub
>...
>
>The problem was gone.
>
>With ... seems to keep an object-Reference somewhere in the
>background (witch seems to be absolutely clear if You look at
>it closely)

I am not much of a WITH...ENDWITH user, but I will _definitely_ keep this in mind if I am troubleshooting in the future...thank you for the tip, and thanks for all your help so far!

JoeK