I want to create a simple ternary expression similar to the following:
Convert.ToInt32(stringname.Substring(0,2)) != 99 ?
Convert.ToInt32(stringname.Substring(0,2)) : 15
I get an error about incompatibilities between int and bool. Is there a simple workaround?
Does it have to be a single line? Apparently you already know the logic. Why do you need to cram it into a single code line? Cramming too much code into a single line will only make reading and debugging unessesarily hard.
Debugging will be hard, because you never know wich of those 4(four!) function calls is throwing the exception. It is also unessesarily slow, as you are doing the same two operations twice in a row. Just do it once and store the result.
My advise is to split up the code using temporary variables. One command + 1 assingment per line. This will make debugging and reading doable. Do not worry about performance. Between Compiler Optimisations and the JiT compiler, there is decent chance any underused variables will be cut out at runtime in a release build.
Is there a way to get statements execution counter in Visual Studio in C#?
So that when I encounter a bug after long digging into code with debugger, with many loops, and I want to step into function that caused the problem and I already went past it with debugger. So I could put this line before the problematic function:
if (Global_execution_counter == 5484984)
int d = 0; // put debug breakpoint here
execute_problematic_function (); // wanna step into this function
Yes you can and without any global variable counter.
The solution is using a hit count breakpoint.
Set a breakpoint at execute_problematic_function ();; right click it to bring up the context menu:
Then click "Conditions", select "Hit count" and set it to whatever value you want.
If you still don't know what's the hit count that you need to set the breakpoint to, you can take advantage of the breakpoints window, which will tell you the current value of the breakpoint:
There is huge amount of code in my project which already debugged 50% of it.
Every time I try to debug it I have to manually set breakpoints after unwanted piece of code to skip it.
Is there a way to tell debugger not to debug that part of code ?
Any extension for this ?
Let's face debugger is on line 1500.
Method1(){
Line 1500 CODE
Line 1501 CODE
...
Line 1726 CODE
Line 1727 CODE
...
Line 2200 CODE
}
I won't need to debug lines between 1727 and 2200.
NOTE : It's not just one piece. Otherwise I would be fine with manual breakpoints
Don't know why it's not in the answer but you can set next statement by CTRL+SHIFT+F10 or dragging the yellow arrow to wanted line and code before next statement will not be executed.
Found it here
If the code in question is encapsulated in a method, you can skip the method by applying the DebuggerStepThroughAttribute on it.
Other than that, setting breakpoints is how to do it.
So, extract this code into a method and apply the attribute to it ;)
You can also click on the line you want to skip to and hit Ctrl+F10 (Run to Cursor). It will jump directly to that line.
Other than setting a debug variable and incrementing it every time you start the foreach, when you break in with the Visual Studio debugger connected, is there a way to tell that this is the Xth time through the loop?
I guess this would be a feature of Visual Studio if anything, not something that would be added to the compiled code.
Set a breakpoint inside the loop, then right click on the breakpoint to set the conditions. You can also right click to see the hit count while debugging and reset it if you want. You can set a boolean expression that is evaluated when the breakpoint hits to conditionally break (or just pass over).
You can also use Visual Studio's Immediate Window, which allows you to write C# expressions against any variables in scope while debugging. Use the List.IndexOf() method, like so:
Expanding on Garo Yeriazarian's answer...
A quick and dirty way without recompiling. Example code:
var ints = new[] {5, 6, 0, 1};
foreach (var i in ints)
{
Debug.WriteLine(100 / i);
}
Add one breakpoint before the loop and one inside it. When the first is hit and you want to start counting, set a Hit Count condition:
Set some large hit count condition and reset the counter and continue. Then when the exception or whatever fires, you can check the "Current hit count" again.
Heres a previous Stack Overflow question that seems to be what your looking for:
get-index-of-current-foreach-iteration
Answer quoted from that link:
Foreach is for iterating over collections that implement IEnumerable.
It does this by calling GetEnumerator on the collection, which will
return an Enumerator.
This Enumerator has a method and a property:
MoveNext()
Current
Current returns the object that Enumerator is currently on, MoveNext
updates Current to the next object.
Obviously, the concept of an index is foreign to the concept of
enumeration, and cannot be done.
Because of that, most collections are able to be traversed using an
indexer and the for loop construct.
I greatly prefer using a for loop in this situation compared to
tracking the index with a local variable.
May be you can use breakpoint hit count. Not exactly what you want, but may be helpful.
Also is there any serious reason why you don't want to use for loop in this case.
Update Feb 2017, six years later - the extension mentioned below is now called OzCode. The feature is now called Foresee, but is only supported in VS2013.
I also felt that this could be a very useful feature, so I created it as part of a commercial extension I made for the Visual Studio debugging experience called BugAid.
The extension shows you exactly which iteration you are whenever you are inside a foreach loop:
When you click the "Iteration x of y" button, you'll see a new window, showing the complete list of items, with the your current location in the loop highlighted (this list is only shown if evaluating the collection in the debugger does not cause any side effects).
Once you open ths Foreach Visualization window, you can even right click any of the upcoming items and choose "Skip to Item", to run forward until you hit that item (this can save you from manually setting-up and messing with hit-count breakpoint):
Let's say your code is
foreach (String line in lines){
Console.WriteLine(line);//breakpoint here
}
Put a breakpoint inside foreach loop, launch "Immediate window" and execute following code Array.IndexOf(lines, line);
Here's how I do it [in VS 2017] :
Set a break point inside the foreach loop
Right click the break point and select 'Actions'
In the text box, enter the following: $FUNCTION {list.Items.IndexOf(item)} where 'list' is the name of your list and 'item' is the current item
Continue running the code and watch the output window
Hit count in Visual Studio 2017:
Set the breakpoint anywhere inside the foreach loop.
Right-click your breakpoint and click "Conditions...".
Check "Conditions" box, switch dropdown to "Hit Count" and edit your Hit Count settings.
On halt, hover the breakpoint to see your settings and the Hit Count reached so far.
Don't forget that your hit count is not automatically reset to zero when you enter the loop for the 2nd time in the same session. ;-) But you can reset it manually:
Have you tried using assertion in debugging? The debugger will be launched at that exact point in your code:
For example: System.Diagnostics.Debug.Assert (myValue >=0)
If whatever you are iterating supports the IndexOf() method, you don't have to set a debug variable.
Like in this example:
foreach (var i in myList)
{
reportprogress(myList, i);
//Do stuff
}
private void reportprogress<T>(List<T> l, T i)
{
progressBar1.Value = ((l.IndexOf(i)) * 100) / l.Count;
Application.DoEvents();
}
Using C# in Visual Studio 2008 and stepping through a function in the debugger I get to the end of a function and am on the final curly brace } and about to return. Is there a way to find out what value the function is about to return?
This is necessary if the return value is calculated such as:
return (x.Func() > y.Func());
It's a little low level, but if you switch to disassembly then you can single step through the instructions and see what the return value is being set to. It is typically set in the #eax register.
You can place a breakpoint on the ret instructions and inspect the register at that point if you don't want to single step through it.
You can put
(x.Func() > y.Func())
in a watch window to evaluate it, and see the result. Unless the statement is
return ValueChangesAfterEveryCall();
you should be fine.
I am still using VS 2003 with C++, so this may or may not apply. If you use the "auto" tab (near the "locals" and "watch" tabs), it will tell you the return value of a function once you return.
I'd actually recommend refactoring the code to put the individual function returns in local variables. That way, yourself and others don't have to jump through hoops when debugging the code to figure out a particular evaluation. Generally, this produces code that is easier to debug and, consequently, easier for others to understand and maintain.
int sumOfSomething = x.Func();
int pendingSomethings = y.Func();
return (sumOfSomething > pendingSomethings);