>>1) the calling program is not so original... c'mon, we aren't Dostoyevskis.
>>
>>2) and it shouldn't matter: the profiler will display it even if it isn't original at all
>>
>>3) the profiler displays the calling code with the time it took to do the call, but it should display the called code in its own block. It may not be easy to find, because the profiler has some of its own ideas how to split the code into units, specially in the case of objects in a container which have their own overridden code (buttons on a form etc)
>
>I think you are not reading well either, my friend. I wish I could include screenshots. There is a calling program, lets call it MyCallingProgram. It creates an object based on a class. The log file result from SET COVERAGE has many, many lines in it. When I run the Coverage Profiler applicaton on that log file, the only window visible is the MyCallingProgram, with no references to anything else. Not what I usually see when I run the Coverage Profiler.

Then the profiler can't find all the code. Check your path before running the profiler. A thing like this may help:

lparameters lcPjx
	Use (lcPjx) In 0 Alias pjx Shared Again Noupdate
	Select Distinct PADR(Justpath(Name),100) ;
		FROM pjx ;
		INTO Array aPaths
	use in pjx
	For i= 1 To Alen(aPaths)
		do addpath with aPaths[i]
	Endfor

Proc addpath
	Lparam cPath
	cPath=Fullp(Addbs(cPath))
	If Dire(cPath)
		If Atc(cPath+',', Set('path')+',')=0
			cPath=Set('path')+','+cPath
			Set Path To (cPath)
		Endif
	Endif