You can add commands to the Tools menu, and have their output redirected to a tab on the output window. You can use the project-specific macros as part of the command, so maybe with some fiddling about you could create a tool that runs your program (cmd /c "$(OutputPath)" might do it, I think? -- I don't have VS handy) and prints its output to the output window. This doesn't let you run it under the debugger, though.
The best solution I've found is just to suck it up. Fighting Visual Studio is wasted effort, because Visual Studio always wins. But you can make life easier on yourself. Add the following function:
void pause() {
if(IsDebuggerPresent()) {
printf("press enter.\n");
getchar();
}
}
Then register this on startup as an atexit function (since you'll want it to be called if something calls exit rather than returning from main):
atexit(&pause);
Then, the first time you run your program, and it's waiting at the "press enter" prompt, go to the console's properties and set 9,999 lines of scroll back. (I also recommend Quick Edit mode, and a smaller font, but it's up to you.) Then when you click "Apply", select "Save these options for future console windows with the same title".
This way, on subsequent runs you'll have a nice large scroll buffer, reasonably straightforward copy'n'paste, and on the offchance your program runs to a successful completion, the command prompt won't disappear immediately.
Yes, I know this is the pause solution that you don't want! -- but I've never found anything better, and, as far as it goes, it works OK.
Another approach, which you can use in conjunction with the above, is to have something like the following function, and use it instead of printf wherever possible:
void xprintf(const char *fmt, ...) {
char buf[16384];//16K - tweak to taste
va_list v;
va_start(v, fmt);
if(IsDebuggerPresent()) {
_vsnprintf(buf, sizeof buf, fmt, v);
buf[sizeof buf - 1] = 0;//_vsnprintf is odd
OutputDebugString(buf);
fputs(stdout, buf);
} else {
vprintf(fmt,v);
}
va_end(v);
}
Now anything your program prints will go to the output window, and (until you get tired of the output window's legendary sloth, and remove the OutputDebugString call, or call xprintf more selectively...) you will be able to see your program's output even after its run has ended.
(Personally, I use all of this together. I don't understand why VS's output window is so slow, and I don't understand why it doesn't capture stdout/stderr, but since I've settled on using the above, I've found it less bothersome. The result isn't exactly great, but it's tolerable enough that you can get used to it.)
