>>I gave them a test build with one line commented out in .SaveTableToWorkbookEx():
>>

>>	* DEBUG
>>*!*		this.RemoveWorkingDirectories(lcTempPath)
>>	* ENDDEBUG
>>

This fixes the hanging issue on the test system, but leaves the temp folders. If necessary this is an acceptable workaround but in a perfect world it would be nice to clean up those folders.
>>
>>I see that method uses the Kernel32 RemoveDirectory API function. I haven't tried replacing it with the native VFP RD|RMDIR function or anything else, I thought I'd bounce this off you first.
>>
>>It's worth noting that the tester also uses another system with Windows 7 and AVG antivirus (with default settings), without seeing this issue.
>
>How about postponing this purge to just once, before oExcel.quit()? I mean, it may have to recreate the same folders over and over if you keep deleting them (just like I have to start refilling the ashtray every time the waiter brings a fresh one).
>
>My way of purging is to purge anything that's older than three days, and I use that since 2001. Three days is old enough for anything that may still be of some use to some piece of software using the same location; after that it's game. I don't go for subfolders but perhaps I should.

Greg's class builds XLSX from scratch, without needing to have Excel installed or use automation: https://github.com/ggreen86/XLXS-Workbook-Class

The idea of deleting working folders just once, after multiple XLSX creations is good but not well suited to this particular use case. In the app there's no way to know if the user will want to create Excel output at all, or just one, or multiple. Making folders on spec/just in case might be possible but would break encapsulation a bit, since Greg's class does its own thing and cleans up after itself.