Switching stack frame doesn't change variable scope

Project:VS.Php for Visual Studio 2005
Component:Debugger
Category:bug report
Priority:normal
Assigned:Unassigned
Status:active
Description

When at a breakpoint inside of a function, I expect to be able to double-click on frames in the Call Stack to be able to see the contents of variables which were local to the function I double-click on. (This is the same as right-clicking an entry in the list and choosing 'Switch To Frame').

It's best if I give an example:

<?php
function Test($b)
{
    echo "Test!";    // Break here
}

$a = 2;
Test($a);
?>

If you break on line 7, the debugger defaults to the 'top' stack frame (inside function 'Test'). Hovering over $b shows 2, and $a's value can't be displayed. This is normal.

However, whilst still at the same breakpoint, if I double-click on the next stack frame down ('{main}'), then I believe I should be able to see what the value of $a was when the Test() function was called. In VS.Php this does't seem to work; it still shows $a as undefined and it still (wrongly) allows me to see the value of $b.

It should be possible to do the same thing with classes. By double-clicking on different stack frames, the $this pointer should change depending on the stack frame that is selected. This is the standard behaviour when debugging C++ in VS2005 and I honestly don't think I could manage without it.

I have tried with both Xdebug and DBG and experience the same results. Is this something which is supposed to work? Or is it unimplemented by VS.Php, or perhaps not even implemented by Xdebug/DBG?

Thanks!

Updates

#1 submitted by StevenChamberlain on Sun, 2007-12-30 18:19

If this is just an unimplemented feature, then a little research tells me that Xdebug is capable of this. The 'context_get' command takes a 'stack depth' parameter which would correspond with what Visual Studio displays in the Call Stack pane (the top being zero). That way it returns the addresses of variables within the specified stack frame.

Comments

    This is an unimplemented

    On January 2nd, 2008 webmaster said:

    This is an unimplemented feature.

    Thanks for the sugestion.