VB: Immediate Window should render strings containing vbCrLf as multi-line strings.

[ericmutta]

Version Used:

Visual Studio Community 2017 v15.3.3

Steps to Reproduce:

When stopped under the debugger, if you view a string variable using the Text Visualizer, the Carriage Return + Line Feed combination causes the string to appear over multiple lines as it would in Notepad. However printing the value of the string in the Immediate Window will render the string with vbCrLf instead:

Expected Behavior:

Printing a string variable in the Immediate Window should render it over multiple lines like it does in the Text Visualizer (see green rectangle in the above image).

Actual Behavior:

The string is rendered using vbCrLf which removes the WYSIWYG aspect of a new-line and makes it awkward to view (see red rectangle in the above image). I am not sure when this behaviour appeared in Visual Studio but I don't remember it ever doing this with prior versions (probably 2015 and earlier versions had the expected behaviour).

[AnthonyDGreen]

The behavior was never really consistent. In VS2013 both windows would display most primitive values using the literal syntax. So if you typed ? Date.Today the Immediate window would display #9/6/2017# (at least it would where I am).

For strings in particular there were special rules. The Immediate window would give you the quoted "raw" value of the string, so quotes weren't escaped, but it would strip out any newlines so all the content would run together in a single line even if it was multiline:

This isn't exactly WYSIWYG and outright hides newlines if you don't know what the string should look like before hand. The Watch window would also use this display format when showing you string values but if you clicked to edit the value it would switch to a round-trip-able format that constructs the literal using vbCrLf and has escaped quotes:

Which makes sense on a lot of fronts. For one, the Watch windows only accept single-line input so there would be no way to directly insert a newline. In those contexts Enter means "submit this new value" and in the Immediate window it means submit line. The Text visualizer is read-only and doesn't have those constraints.

In 2017, and presumably 2015, all windows use the round-trip-able literal format in all situations for all primitive types.

[AnthonyDGreen]

So that leaves the question of what to do moving forward. Presumably we want something reasonable and consistent. We could have all windows not use the literal format (like the text visualizer) for read-only display contexts for all types. So ? " " would print an invisible ` not" "`. And the Watch windows could revert to the literal format for all primitive types, using vbCrLf for strings in that context because it's single-line. It shouldn't strip out newlines though, since that's misleading.

The advantage is less visual clutter on strings and dates. The disadvantage is that if you're operating inside the Immediate window there's no way to query a value and then feed an updated value back in a future submission without manually reconstructing the literal, e.g.

? s
Line 1
Line 3
s = "Line 1" & vbCrLf & "Line 2"

vs

? s
"Line 1" & vbCrLf & "Line 3"
s = "Line 1" & vbCrLf & "Line 2"

That puts people who use the Immediate window in a bad spot.

Or we can keep doing what we do today and everyone's in a less than idea but simpler place. How do we decide?

[ericmutta]

@AnthonyDGreen Or we can keep doing what we do today and everyone's in a less than idea but simpler place. How do we decide?

In my personal experience, the Immediate Window is inherently multi-line and is probably used more for output (either via Debug.WriteLine() or by querying variables using ?) than it is used for input. In fact I can't remember the last time I used the Immediate Window to set a value since I can usually do it directly using those debugger "value tooltips" that pop-up near a variable when you hover over it.

I propose that for strings in the Immediate Window, we render vbCrLf visually so it easier to inspect objects like StringBuilder by calling .ToString(). In fact this is what I was doing: I had a string builder collecting lines of log output. Mid-way through debugging I wanted to inspect what's in the log, so I went to the Immediate Window and typed ?myLogStringBuilder.ToString() and what came out was impossible to read because it wasn't what I would see in Notepad when the log was finally written to file.

I could have inspected the StringBuilder by going to the watch window and doing the same thing, but then you have to use the Text Visualizer to view the output and you run into #21894 (can't scroll through the lines with mousepad...a feature which works just fine in the Immediate Window probably because going through hundreds of lines in that window is common).

[tmat]

@ericmutta We should definitely fix #21894. Long-term we would like to replace Immediate Window with Interactive Window that is connected to your debugging session. Interactive Window has much better support for multi-line input and output, so we can then reconsider how we print out multi-line strings. Sound reasonable?

[ericmutta]

@tmat Interactive Window has much better support for multi-line input and output, so we can then reconsider how we print out multi-line strings. Sound reasonable?

Sounds good, many thanks for following up. Will there be an Interactive Window for VB long-term? Right now all I see is for C# and F# and I am yet to try that window since I don't use those languages much!

[tmat]

@ericmutta Having standalone Interactive Window (that is not connected to a debugging session) for VB in the same way C# has today is not required for using Interactive Window UI component for evaluation while debugging. What I meant above was using the UI component. The engine that's evaluating the input typed to the window would be different from the one C# interactive has today. It would be performing evaluation in the context of the debugged process, not in a standalone context. I'd like to have the standalone VB Interactive Window as well, but I can't tell when we'll be able to implement it.

[ericmutta]

@tmat What I meant above was using the UI component.

OK, that sounds good 👍 Meanwhile, hopefully @AnthonyDGreen will figure something out for the Immediate Window as it stands right now....for as long as I can remember (going back to 2003) it always rendered multi-line strings in a WYSIWYG fashion.

[paul1956]

I actually like the current way the immediate window works especially for writing tests. It is easy to see where two strings differ. But for debugging a WYSIWYG would be better. No matter which you pick it is going to be bad for someone. What about a built in function like ?? gives you WYISWYG or way to set your preference under options.

[ericmutta]

@paul1956 What about a built in function like ?? gives you WYISWYG or way to set your preference under options.

Was thinking the same thing too! We could have the current ?someVariableHere mean show the "programmatic" literal value (i,e what you would type in valid code), while ??someVariableHere show the WYSIWYG variant that you would see, for example, by calling .ToString().

@AnthonyDGreen how does the above sound, is it workable?

[ghost]

So it's now broken then?

[paul1956]

@AlanSteadman I don't understand your comment but I am guessing that it refers to the death of VB's interactive window.

[austinhiggs2]

2024 still not "fixed" to remove the VBCRLF or give us the ? or ?? that was mentioned. I like that idea

[CyrusNajmabadi]

@austinhiggs2 this is on the backlog. If you'd like to contribute a fix here though, we'd be happy to take that. Thanks.