>Not that I know of. I don't know how you could possibly specify a different config.fpw for a COM object since the registration is for a very specific load behavior.

If you don't know, I surely don't :).

Just had to check whether there was some trick to influence the environment in which a COM object is instantiated, simply because it would be really easy if it was possible. Just love to check for simple things before trying the complicated - if one of them works...

>>>Interesting.
>>>
>>>But I think that the registry settings aren't being used in COM objects - those settings are for the IDE version of VFP AFAIK.
>>>
>>>I just tried this and even in VFP it doesn't appear to actually affect the temp path. SYS(2023) still returns the original path even after the registry was changed and SYS(2056) was called.
>>>
>>>Even if it did work I think it'd be hard to do this reliably. The problem is that the servers load asynchronously off different threads so the order is not guaranteed nor the timing. You'd never know when to change the registry explicitly.
>>
>>I'll have to confess here that I'm quite rusty on the subject - didn't have to build a COM server for some five years now - but it's been said there are no stupid questions, save those that weren't asked. So... is it possible to serve the COM server .exe (or .dll, for that matter) a brand new config.fpw on each instantiation? In that config it could have a tmpfiles= set to some spanking new temp directory of its own - and then we'd be able to purge these more intelligently (i.e. whichever directory is older than n days, shoot to kill).