>Well, I remember there was the same problem in my application where I required to track all temporary document files opened in Word for read-only viewing by user. Because user might want to see many documents at once, I cashed them in temporary files, as well as allowed user to see them for entire session of application work. However, after application shutdown, I try to delete all files and then show warning to user if some files are still opened in thw Word about some files could be left on disk in temporary files folder. (Well, this could be changed to use closing of all Word instances, but this was not quite a good idea.) In your case it is even more simple because you're sure that after closing the form with WEB Browser Control temporary files could be deleted at all.

Right, the approach is similar but the use is different - the browser shows only one document at a time, and on browser's destroy I should do the cleanup.

>The approach is simple - make a public object in the application that will track all temporary filenames of files created in the application and that you cannot delete immediately. In that object use method like "RegisterTempFile" to register temporary file in this object's array. Then in the Destroy event of that object delete all temporary files if they're not already deleted and if it is possible to delete.
>
>Just a housekeeping...

I know, and I already have a class which does that - creates temp filenames, keeps them in an array property and deletes them on destroy. This time, I had a feeling that I could completely avoid the disk. It didn't seem natural that a form should communicate with an object it contains using external files - unless the object was an entirely unfriendly OCX.

Seems to be Marcus was on the right track.