Maybe because it's early, but I don't see how that would work.
This is where my code stands now:

Calling Function snippet:

   oProc = "proc" + Sys(2015)
   &oProc = CreateObject("sqlsql.obj")
   cResponse = &oProc..Receive ( cValue )
   ? cResponse

Called Function. This is living inside an out-of-process COM object that should log to disk whatever it gets. Because it is a MTDLL, each instance should have its own log and not step on the others.

Parameter lcString 
Declare INTEGER GetCurrentThreadId IN WIN32API
lcString = Alltrim( Transform( lcString ) ) + Chr(13)+Chr(10)
cLogName = "-Log-PID" + Alltrim( Transform( _VFP.ProcessId ) ) + ;
   "-ThreadID-" + Alltrim( Transform(GetCurrentThreadId()) ) + ".txt"
cLogPath = "c:\"
lcString = lcString + "Seconds since midnight: "+;
   AllTrim(Str(Seconds(),10,3) ) + Chr(13)+Chr(10)
If This.iNewLog = 1
     StrToFile (lcString , cLogPath + cLogName , .f. )
     This.iNewLog = 0
Else
     StrToFile (lcString  , cLogPath + cLogName , .t. )
EndIf
Flush

Thanks.


>Your object can have a property, filled with sys(2015), which will keep the name of the log file. Thus you wouldn't really care if your objects had same names; just make sure you include the sys(1272) based information in the first line of the log. Then each object will have its own log file, and you'll have their hierarchical names inside the logs, and you won't have to fiddle with macros and fancy object names to achieve this.