Using Visual Studio 2010 Professional, I have a ToString() method that looks like this:
public override string ToString()
{
return "something" + "\n" + "something";
}
Because there are several "something"'s and each is long, I'd like to see
something
something
Sadly, I'm seeing
"something\nsomething"
Is there a way to get what I want?
Actually there is a way. You can use format specifiers in the immediate window to change the format of the display. If you have a string with carriage returns and linefeeds in it ("\r\n") you can follow the print request with the 'no quotes' format specifier.
In the immediate window type:
?MyObj.ToString(),nq
and the \r\n will cause newlines in the immediate window.
For more info on format specifiers see:
http://msdn.microsoft.com/en-us/library/e514eeby.aspx
Unfortunately no there is not. What's happening here is an artifact of the design of the debugger APIs.
The component responsible for processing the ToString() call is the expression evaluator. It's the data source for the majority of the debugger windows (watch, locals, immediate, etc ...).
For every window but the immediate the value is displayed on a single line. Displaying a multiline string on a single line doesn't make much sense. Hence the expression evaluator makes the string slightly more displayable by escaping newline characters into a displayable version.
This technique works pretty well for the locals and watch window. But in the immediate window where it makes more sense to display the multiline value it makes a lot less sense. Unfortunately the expression evaluator doesn't know the context of where it's data will be displayed and hence does the safe operation which is to escape the newlines.
Related
So I am copying some raw string from chrome inspect tab which after pasting, the result seems to be altered: the "/n" has been replaced with unicode symbol "⏎".
My question is, is clipboard supposed to parse and interprete? why?
Is there any way to prevent this from happening?
Thanks
When eagerly evaluating expressions, Chrome puts the entire output on one line. Hit enter to (uneagerly) evaluate the expression for real to get the actual value without ⏎s.
Is there any way to change the default behavior of Visual Studio's debugger such that when hovering over a null-terminated, dynamically allocated character array (C++), it will display the full content of the string, rather than the first character only?
I should mention that I am using Visual Studio 2010. If there is a way to achieve this in VS2012 only though, I would be interested to know that as well!
There's a useful link for visual studio, C++ Debugger Tips:
To interpret a pointer expression as a string, you can use ‘,s’ for an simple null-terminated string, ‘,s8‘ for a UTF-8 string, or ‘,su‘ for a Unicode string. (Note that the expression has to be a pointer type for this to work).
For example you break in the following function
void function(char* s)
{
// break here
}
in the MSVC watch window (or debugger), you would first try to just add s but it will only display the first character. But with the above information, you could append the following suffixes to the variables in the watch window:
s,s8
or if you know it's unicode, try:
s,su
This even works for arbitrary pointers, or say for other data types, e.g. debugging the content of a QString:
QString str("Test");
// break here
For this, possible watch window (or debugger) statements are:
((str).d)->array,su <-- debug QString (Qt4) as unicode char string
(char*)str.d + str.d->offset,su <-- debug QString (Qt5) as unicode char string
0x0c5eae82,su <-- debug any memory location as unicode char string
If appending ,s8 or, respectively ,su does not work, try the other variant.
I'm trying to understand exactly who among the set of TTY, kernel, line discipline, and shell actually deals with any given part of my input. In particular, I've been working through this article:
The TTY demystified
My question: if I want to have the actual delete character show up in BASH, I can use ^V to make it verbatim. E.g. I can use Ctrl+V then Ctrl+H to have a backspace character. Pretty neat!
echo '3^H'
3
My question is this: if I'm in something that reads in canonical mode (I believe cat does this) I can put a null character in there by doing Ctrl+V then Ctrl+2 (basically Ctrl+#, which is the caret notation for the null character).
BASH won't allow me to have a verbatim null character on one of its lines, though, and it looks like python and other readline programs won't either.
Does anybody know why this is, or a general-purpose workaround?
The C library uses a literal null as a string terminator, so anything using that is unable to represent strings containing literal nulls.
Programs which need to support literal nulls define their own string data type.
I have a specific method for my bash prompt, let's say it looks like this:
CHAR="༇ "
my_function="
prompt=\" \[\$CHAR\]\"
echo -e \$prompt"
PS1="\$(${my_function}) \$ "
To explain the above, I'm builidng my bash prompt by executing a function stored in a string, which was a decision made as the result of this question. Let's pretend like it works fine, because it does, except when unicode characters get involved
I am trying to find the proper way to escape a unicode character, because right now it messes with the bash line length. An easy way to test if it's broken is to type a long command, execute it, press CTRL-R and type to find it, and then pressing CTRL-A CTRL-E to jump to the beginning / end of the line. If the text gets garbled then it's not working.
I have tried several things to properly escape the unicode character in the function string, but nothing seems to be working.
Special characters like this work:
COLOR_BLUE=$(tput sgr0 && tput setaf 6)
my_function="
prompt="\\[\$COLOR_BLUE\\] \"
echo -e \$prompt"
Which is the main reason I made the prompt a function string. That escape sequence does NOT mess with the line length, it's just the unicode character.
The \[...\] sequence says to ignore this part of the string completely, which is useful when your prompt contains a zero-length sequence, such as a control sequence which changes the text color or the title bar, say. But in this case, you are printing a character, so the length of it is not zero. Perhaps you could work around this by, say, using a no-op escape sequence to fool Bash into calculating the correct line length, but it sounds like that way lies madness.
The correct solution would be for the line length calculations in Bash to correctly grok UTF-8 (or whichever Unicode encoding it is that you are using). Uhm, have you tried without the \[...\] sequence?
Edit: The following implements the solution I propose in the comments below. The cursor position is saved, then two spaces are printed, outside of \[...\], then the cursor position is restored, and the Unicode character is printed on top of the two spaces. This assumes a fixed font width, with double width for the Unicode character.
PS1='\['"`tput sc`"'\] \['"`tput rc`"'༇ \] \$ '
At least in the OSX Terminal, Bash 3.2.17(1)-release, this passes cursory [sic] testing.
In the interest of transparency and legibility, I have ignored the requirement to have the prompt's functionality inside a function, and the color coding; this just changes the prompt to the character, space, dollar prompt, space. Adapt to suit your somewhat more complex needs.
#tripleee wins it, posting the final solution here because it's a pain to post code in comments:
CHAR="༇"
my_function="
prompt=\" \\[`tput sc`\\] \\[`tput rc`\\]\\[\$CHAR\\] \"
echo -e \$prompt"
PS1="\$(${my_function}) \$ "
The trick as pointed out in #tripleee's link is the use of the commands tput sc and tput rc which save and then restore the cursor position. The code is effectively saving the cursor position, printing two spaces for width, restoring the cursor position to before the spaces, then printing the special character so that the width of the line is from the two spaces, not the character.
(Not the answer to your problem, but some pointers and general experience related to your issue.)
I see the behaviour you describe about cmd-line editing (Ctrl-R, ... Cntrl-A Ctrl-E ...) all the time, even without unicode chars.
At one work-site, I spent the time to figure out the diff between the terminals interpretation of the TERM setting VS the TERM definition used by the OS (well, stty I suppose).
NOW, when I have this problem, I escape out of my current attempt to edit the line, bring the line up again, and then immediately go to the 'vi' mode, which opens the vi editor. (press just the 'v' char, right?). All the ease of use of a full-fledged session of vi; why go with less ;-)?
Looking again at your problem description, when you say
my_function="
prompt=\" \[\$CHAR\]\"
echo -e \$prompt"
That is just a string definition, right? and I'm assuming your simplifying the problem definition by assuming this is the output of your my_function. It seems very likely in the steps of creating the function definition, calling the function AND using the values returned are a lot of opportunities for shell-quoting to not work the way you want it to.
If you edit your question to include the my_function definition, and its complete use (reducing your function to just what is causing the problem), it may be easier for others to help with this too. Finally, do you use set -vx regularly? It can help show how/wnen/what of variable expansions, you may find something there.
Failing all of those, look at Orielly termcap & terminfo. You may need to look at the man page for your local systems stty and related cmds AND you may do well to look for user groups specific to you Linux system (I'm assuming you use a Linux variant).
I hope this helps.
I have a Win32 Edit window (i.e. CreateWindow with classname "EDIT").
Every time I add a line to the control I append '\r\n' (i.e new line).
However, when I call WM_GETTEXT to get the text of the EDIT window, it is always missing the last '\n'.
If I add 1 to the result of WM_GETTEXTLENGTH, it returns the correct character count, thus WM_GETTEXT returns the final '\n'.
MSDN says this about WM_GETTEXTLENGTH:
When the WM_GETTEXTLENGTH message is
sent, the DefWindowProc function
returns the length, in characters, of
the text. Under certain conditions,
the DefWindowProc function returns a
value that is larger than the actual
length of the text. This occurs with
certain mixtures of ANSI and Unicode,
and is due to the system allowing for
the possible existence of double-byte
character set (DBCS) characters within
the text. The return value, however,
will always be at least as large as
the actual length of the text; you can
thus always use it to guide buffer
allocation. This behavior can occur
when an application uses both ANSI
functions and common dialogs, which
use Unicode.
... but that doesn't explain the off by 1 conundrum.
Why does this occur and is safe for me to just add an unexplained 1 to the text length?
Edit
After disabling the unicode compile, I can get it working with an ASCII build, however, I would like to get this working with a UNICODE build, perhaps the EDIT window control does not behave well with UNICODE?
Try to set ES_MULTILINE and ES_WANTRETURN styles for your edit control.
\r and \n map to byte constructs, which work when you compile for ASCII.
Because \r, \n are not guaranteed to represent carriage return, line feed (both could map to line feed, for example), it is best to use the hexadecimal code points when building the string. (You would probably use the TCHAR functions.)
Compile for ASCII - sprintf(dest, "%s\x0D\x0A", str);
Compile for UNICODE - wsprintf(dest, "%s\0x000D\x000A", str);
When you call WM_GETTEXT to retrieve the text you might need to call WideCharToMultiByte to convert it to a certain code page or character set such as ASCII or UTF8 in order to save it to a file.
http://msdn.microsoft.com/en-us/library/aa450989.aspx
The documentation for WM_GETTEXT says the supplied buffer has to be large enough to include the null terminator. The documentation for WM_GETTEXTLENGTH says the return value does not include the null terminator. So you have to include room for an extra character when allocating the buffer that receives the text.
You have to add one character for your string terminator \0 character.