>>>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
>

That was a neat utility, thanks for that. Unfortunately I have every imaginable path included before I run the Profiler and it still only displays the calling program. Not sure what the problem is, but I'm just going to do it the hard way and trace through every line of code until I can find what runs just before the procedure that I'm concerned with.