I am debugging and I hit my break point. I hover over a variable and I get the standard drilldown. I see a Nullable prop and it is null. I right click and choose "edit value". No matter what I seem to type, I get "The value could not be set. Please check your entry."
I have tried 5/1/09, new DateTime(2009, 5, 1), {05/01/2009}... pretty much every flavor I could think of. What the heck am I doing wrong? I would like to code in the value and continue debugging with the new value.
Any suggestions?
Thanks, ~ck
DateTime.Parse("5/1/2009")
Seems easy to me. I had this line:
DateTime dt = DateTime.Parse("01/01/2000");
Hit the breakpoint, and typed this into the immediate window:
dt = DateTime.Parse("02/01/2010")
The same technique also works when editing the value in the debugger tooltip, the locals window, the autos window, the watch window and even the quick watch window.
Try using #5/1/2009#
In a Watch window line, type this in the name field:
dt = new DateTime(2009,5,1)
The line will be disabled so just delete it. In the next line, type in dt and it will be the value you want.
Is this object a "DateTime" or a "Nullable" (which is the same as "DateTime?")?
Related
So my idea is I want to see what an object's members or properties would return/change while I am debugging/tracing. There is Object Browser but it is only to show tree list of an object.
For example, let's say
var cacheDir = cotext.CacheDir;
But I want to change .CacheDir to .ExternalCacheDir while debugging to see what value would be returned to the variable.
var cacheDir = context.ExternalCacheDir;
Otherwise, I have to change it in editing mode and restart the whole debugging process. I think that we can do something like this in browser developer console or Jupyter notebook like CLI environment.
With C# Keyboard settings you press Ctrl+Alt+I - the immediate window. Or via the Command window type Immed.
In the Immediate Window you can do ad-hoc commands.
So in the debugger IDE you'd step over the line of code:
var cacheDir = cotext.CacheDir;
And now you want to tweak it just a once off, Ctrl+Alt+I
Then paste:
cacheDir = cotext.ExternalCacheDir;
And press enter. You can always revert back in the immediate window, eg:
cacheDir = cotext.CacheDir;
If you just want to see the value of a variable you can do a ? cacheDir to see the values. Give it a go :)
While you're debugging, you can use Watch windows to watch variables and expressions.
Open a Watch window by selecting Debug > Windows > Watch > Watch 1,
or pressing Ctrl+Alt+W > 1.
In the Watch window, select an empty row, and type variable or Expression
Continue debugging by selecting Debug > Step Into or pressing F11 as needed to advance.
The variable values in the Watch window change as you iterate through the for loop.
Reference
There are many ways to see variables values in VS. You can use the Watch Window, You can hover a variable and see a Data Tip, you can use the Immediate Window. You can also check OzCode that provides a HUD that shows the variable values without the need to open any Window, and provide a nice way to choose the properties that you like to present, and provides a google like search for variable name and values.
In the next version of OzCode (you can download a preview version of it) you can use OzCode Predict that also support VS Edit&Continue.
Let's say I'm degugging code and I reach a breakpoint where the line of code is something like this:
GetEmpInfo(empName, empLast, empSS, empDept, empBirth, empCity, empState,
empCountry, parm1, moreparms, evenmore, toomanyparms);
Is there a way to know what value each of those parameters has without going through each variable? I know there has to be a way; I just don't know where it is.
Thanks.
There are 7 good ways to do it -
1. Data Tip
2. Autos Window
3. Locals Window
4. Watch Window
5. Quick Watch Window
6. Parallel Watch Window
7. Immediate Window
Check this for more info
You can use the DebuggerDisplay Attribute
[DebuggerDisplay("{Param1} {Param1} {Param1}")]
And when you hover over the object you will see the values that are entered above
They can only be placed on method names. How are they used and what are they for?
The Debugger team has a good blog post on this subject with examples as well: http://blogs.msdn.com/b/visualstudioalm/archive/2013/10/10/tracepoints.aspx
https://web.archive.org/web/20190109221722/https://blogs.msdn.microsoft.com/devops/2013/10/10/tracepoints/
Tracepoints are not a new feature at all (they been in Visual Studio since VS 2005). And they aren't breakpoints per se, as they don't cause the program execution to break. That can be useful when you need to inspect something, but not stop the program as that causes the behavior of a bug not to repro, etc.
Tracepoints are an attempt to overcome the case when you can't stop the program to inspect something as that will cause some behavior not to repro, by allowing a breakpoint to log information to the debug output window and continue, without pausing at the UI. You can also do this with macros, but it can be more time consuming.
To set a tracepoint, first set a breakpoint in code. Then use the context menu on the breakpoint and select the “When Hit...” menu item. You can now add log statements for the breakpoint and switch off the default Stop action, so that you log and go. There is a host of other info you can add to the log string, including static information about the location of the bp, such as file, line, function and address. You can also add dynamic information such as expressions, the calling function or callstack. Things like adding thread info and process info, can help you track down timing bugs when dealing with multiple threads and/or processes.
Use case where it can prove really helpful in debugging:
There could a case when you want to debug a function which gets called numerous number of times (say in hundreds), and you may just want to see the trend in which a local variable is changing. Doing this is possible by putting breakpoint, but think about stopping(while debugging) at that function hundreds of times and taking the pain of noting down the values in notepad. Doing this is so easy by using tracepoint, it directly puts the logs in "Output" window, which can be easily analysed or even cleared. Saving hours of manual effort and patience.
Example log at Output window(can run to hundreds of lines):
keyframeNo = 2, time = 1100
keyframeNo = 1, time = 0
keyframeNo = 1, time = 1
keyframeNo = 1, time = 1
keyframeNo = 1, curTime =22
curTime=1132835, keyframeno=15
keyframeNo = 2, time = 1
keyframeNo = 2, time = 1
How to use it:
right-click mouse at code > BreakPoint > Insert TracePoint
Advantage of using TracePoint:
There is no need to add code for generating logs. So, no tension to build the code, also no overhead of cleaning the code.
It doesn't obstruct the flow of code under execution, unlike breakpoints.
It can print value of local variables as well. Enter {local_variable} after clicking "When Hit"
You can also insert tracepoints in Debugging state, just as you can do for breakpoint.
According to MSDN:
Tracepoints are a new debugger feature in Visual Studio. A tracepoint is a breakpoint with a custom action associated with it. When a tracepoint is hit, the debugger performs the specified tracepoint action instead of, or in addition to, breaking program execution.
All my code works fine until i did some changes that i cant track right now.
when i debugg my code i can see that the converting returning hex instead of number.
I have no idea why its happening or what can cause this.
any ideas please?
Thanks.
It's a VS feature, You can disable it:
You're looking at the value in a debugger. Integer values are not stored "in hex" or even "in decimal". 3 is stored in binary, but viewed based on your debugger settings.
You can disable hexadecimal viewing by right clicking in the Watch or Immediate view and deselecting Hexadecimal Display.
I'm getting this message in watch box.
Actually, my expression doesn't have any side effect, and I need to re-evaluate it automatically each time. How can I achieve that?
You can append ,ac to the watch expression to have it automatically refresh the value
x.ToString(),ac
See http://msdn.microsoft.com/en-us/library/e514eeby.aspx for more information and other format specifiers.
thanks to Scott Visual Studio: Make debugger aware that a function doesn't cause "side effects"