Hi all,
I've recently had to change my script structure due to a large amount of code duplication to avoid circular includes. The structure is better now, but some of the functions get called alot. Sometimes from scripts, sometimes from Visualizer. I'm hoping to report to myself - not the user - for a while until all the references are highlighted, which of the KWTs and scripts are running when these obsolte functions where called. I have experienced that Find Usages on the context menu of the function has missed a few so I thought I'd do something like this to mop up the remaining ones:
function CallObsolete()
{
Log.Message("Obsolete function used");
return CallNew();
}
function CallNew()
{
return true;
}
The new code & structure allows this to work. What would be handy is if TC could tell me who called this function this time around. It's one thing getting a message in the log telling me that the obsolete method was called, but trying to pinpoint which specific place in a block of code the 6th instance of this warning comes from is an entirely different matter. What would be handy would be a call stack 
. It's similar, but not identical to of my previous question here:
call stack on application exception not returning full stack
It just happens to also include references to the Call stack. If I Log.Error I get a call stack, but if I Log.Message, there's no call stack. Problem is though, I don't want the entire test to fail just because somewhere there was a neglected piece of code still calling the obsolete methods, so I stick to Log.Message. In some cases I have even found that the work involved in redoing some of these old pieces of code isn't justified and a function can happily keep calling the obsolete function. I could use the page's picture to help pinpoint where in the KWT it happens, but that would slow down the tests more than I would like to. Any thoughts on how I can better identify these orphan obsolete function calls ?
I tried this experiment... and here's what I got.
I created the following code:
function root(){
Log.Message(root.caller);
}
function oneUp(){
Log.Message(oneUp.caller);
root();
}
function twoUp(){
Log.Message(twoUp.caller);
oneUp();
}
function top(){
Log.Message(top.caller);
twoUp();
}
I then ran the top function. My test log, on completion, looks like this.
If you replace <function>.caller with <function>.caller.name you get just the name of the calling function.
We use Jscript. I have tried a direct implementation of the Javascript call as you suggested, since they are theorhetically just about interchangeable. I have tried .caller before, but it appears there are some differences though.
It doesn't encounter errors. It can't pick up the caller though - it's just null
I thought you'd find it amusing that I also tried ObsoleteFunction().caller - and ended up with a Stackoverflow, doh !
Just to be clear. The call stack would be a nice to have, not a critical - I could use the page picture if needs be (it might slow down the tests massively, so will only add the picture if I have my verbose logging project variable as true 
). I won't be spending much time on this myself if it's not a trivial implementation .
@tristaanogre wrote:
Honestly, I'd consider converting your project to JavaScript.
I would if it was within my power to do so...
All that standard reasons for not being able to: More than one product, different teams etc. etc. No legacy stuff though - it's too new
