It depends on how you app is designed. If it is not designed using accessor
methods (properties) then adding them will be more painful. Ordinarily, any
public member variables should use properties to control access to them.
That leaves you with private member variables and variables with local
scope. If they have local scope then you already know when they will change
their value, i.e when the method is called that declares them.
So, are these global variables you are trying to observe?
Incidentally, I am not suggesting that the only way to trace these variables
is by attaching an external debugger. The Trace statements will execute and
display the value in the Output window in the IDE.
But to answer the actual question, I suspect that showing the Watch window
when not in break mode would add a tremendous computational overhead to the
application that would slow it down.
Charles
"Ricky W. Hunt" <rh*****@hotmail.com> wrote in message
news:8SqPc.216003$JR4.86577@attbi_s54...
"Charles Law" <bl***@nowhere.com> wrote in message
news:uV**************@TK2MSFTNGP10.phx.gbl... Hi Ricky
If you control access to your variable through a property, you would be
able to add a single Trace statement to the property Set method to write out
your variable when it changes. You could even leave the Trace statement in
your production build, and anytime you wanted to see the value change just
attach the debugger to a running instance of your application.
HTH
Man this sounds like a lot of trouble to go to. Why in the world can't we
see the Watch window without being in break mode?
