>PMFJI but you can actually change the values right in the watch window
One exception to this is in direct interation with elements of the _screen system variable - the _screen reference itself doesn't permit direct, detailed interaction with many of its internal collections, like _screen.forms.
A neat workaround for this is to assign screen to a private variable at the top level of your mainline program (or a public variable if you aren't PUBLIC-phobic) to provide a manipulatable object hook to the _screen object for use in the debugger; the members of the _screen object are just as happy referenced through the variable, and the variable's object content can be manipulated directly in the LOCALs window. This is a huge aid in debugging, where you'd like to directly explore and examine the Forms collection, or properties like activeform and activecontrol. It also can be used to get around some seemingly inconsistent behavior of _screen for addobject() and addproperty(); I've at times been able to use the memvar object reference where the same operation against _screen was disallowed. The same works for other internal VFP objects that don't show up in the LOCALS window; part of my standard debug setup code looke like:
PUBLIC go_Screen, go_VFP
go_Screen = _Screen
go_VFP = _VFP
It's a nifty trick that should make debugging where you'd like to deal with the _screen object just like any other system object easier; the one thing I make certain to do is to release the memvar references explicitly before I shut down if I can.
