Prevent Visual Studio 2015 from Colorizing Background at Breakpoint in Lambda Expression
Asked Answered
O

2

8

I'm trying to prevent Visual Studio 2015 from colorizing code blocks when at a breakpoint within a lambda expression.

(Screen shot below).

It's very distracting for me, and I would like to prevent this behavior, but can't figure out how to either A) prevent it altogether, or B) change the background color that it's using to black so that the effect is invisible.

I'd greatly appreciate any insight.

To reproduce it, just enter this code, set a breakpoint at the "for" loop, and run it. When the breakpoint is hit, the entire Lambda expression will colorize as shown below (exact colors dependent on your color scheme, presumably).

    public delegate void funcType();
    static void Main(string[] args)
    {
        ((funcType)(() => 
        {
            for (int i=0; i< 10; i++)  // <<== Set Breakpoint Here, and run to it
            {
                Console.WriteLine("Test line to show colorization.");

            }
        }))();
    }

Problematic Colorization

Per Hans Passant's question, here are all the Extensions that are installed in Studio 2015.

It's important to note that this is NOT an EDITOR issue. This happens at runtime only, when the DEBUGGER stops at a breakpoint inside a Lambda expression.

Page 1 of 3

Page 2 of 3

Page 3 of 3

Ostraw answered 2/3, 2018 at 21:45 Comment(5)
I see no sign of this. Nor is it an entry in the Fonts and Colors list nor is the standard Microsoft highlighter smart enough to distinguish this. It feeds off a lexer, not a parser. You need to tell us what kind of add-ins you use.Weirdie
Per HansPassant I've updated the question with screen shots of the extensions installed in Studio 2015.Ostraw
Even Google has never heard of "Dark_BillsBlack". If its author does not provide support then just try another one, lots of dark themes to choose from.Weirdie
Dark_BillsBlack is simply the name of the color scheme that I'm using - it's not an extension at all. Visual Studio 2015 Color Theme Editor uses it, and it must store it in such a way that it shows up in this list.Ostraw
Visual Studio 2017 has a Active Statement display item in Text Editor settings. Does Visual Studio 2015 have this display item?Lunisolar
M
4

For those of you still searching in VS 2019 etc. it's the "Active statement" option in fonts and colors in the tools/Options menu.

Metronymic answered 2/12, 2019 at 10:33 Comment(0)
S
1

To change the background color of the current line, when a normal breakpoint is hit in debugging, you need to alter the value of Item Background under Current Statement.

To do this from the main menu go:

Tools -> Options -> Environment -> Fonts and Colors

and then set the value to black.

enter image description here

I confirmed this by setting a breakpoint in a lambda and setting the property to lime green. e.g.

enter image description here

Scup answered 13/3, 2018 at 14:33 Comment(4)
Thanks for taking a shot at this! This does not address the problem I describe, though; there's a detail that I think you missed: The colorization problem that I'm trying to fix is when you hit a breakpoint WITHIN the code block INSIDE a Lambda expression. If you use my example from the initial question, and set a breakpoint at the location indicated in the comment, you'll see the problem. Any help solving that problem is greatly appreciated!Ostraw
@Ostraw - my example is using a breakpoint hit inside a lambda expression - look at the picture. Clearly an active break-point inside a lambda.Scup
Fraser, it's a looong time later, but I ran across this again, and wanted to add detail for anyone else still searching. Your example shows something different. A breakpoint INSIDE the lambda - say, on "Map.MapProjection = ....." - will show that statement in green (Current Statement, as you noted). All good! ...but ... the entire lambda function itself would ALSO be highlighted a DIFFERENT color - which in my example is that gray color. -->> The correct color to change to fix this is "Active Statement", as @Metronymic noted. Thanks to both of you for helping sort this out.Ostraw
@Ostraw Ah! Ok that makes perfect sense :)Scup

© 2022 - 2024 — McMap. All rights reserved.