13

I'm developing a gcc application using Visual Studio 2015 as an IDE. The debugger is gdb.

The application creates it's own window. When I compile with a DEBUG switch, I need the application to also spawn a console window. It's used for debugging and outputing printf's from multiple threads. Thanks to the "-mwindows" switch, this works correctly when I execute the application from outside Visual Studio.

Unfortunately, when I run the application from within Visual Studio, it seem to steal the console window. No console is spawned, and the printf's output are redirected to the Output Debug window.

This wouldn't be much of a problem if the VS console actually printed the "\n" correctly instead of stripping them out of the ouput. Everything gets printed on the same line, and the output becomes unreadable. Try as I may, I couldn't get VS to insert a newline in the Output Debug window. I searched online a lot, and this problem seems to be well documented, but I couldn't find a satisfying answer.

At this point, either of these solutions would work for me :

  1. Prevent Visual Studio from stealing the application's console window;
  2. Add special characters to all my printf in order to make the Output Debug print line feeds and carriage returns.

EDIT : Ideally, the solution should be cross-plateform, in a sense that it should not add dependency to WinAPI.

EDIT2 : "\t" seems to work as intended. Why does "\n" doesn't work? I also tried "\r\n" to no avail.

Guilherme Fidelis
  • 1,022
  • 11
  • 20
MartinVeronneau
  • 1,296
  • 7
  • 24
  • Trying to use 2 debugging tools at the same time? – Weather Vane Jan 20 '16 at 20:00
  • 2
    I suspect `-mwindows` sets the subsystem field in the PE header to "GUI". How about you use `AllocConsole` at runtime and redirect `stdout` to be able to print? That might help. See here: http://stackoverflow.com/questions/311955/redirecting-cout-to-a-console-in-windows (the question is about C++'s `std::cout` but it also has a C solution). – user4520 Jan 20 '16 at 20:01
  • 2
    @WeatherVane : GDB is now supported by Visual Studio. I suggest you look at [this blog post](http://blogs.msdn.com/b/vcblog/archive/2015/11/18/announcing-the-vs-gdb-debugger-extension.aspx). The VS debugger has a lot of great features, so it's good that it now supports being a GDB front-end. My problem, though, is not with the actual debugging, which works great. I would just like to see my console output in a readable way. – MartinVeronneau Jan 20 '16 at 20:09
  • 2
    @szczurcio : Using AllocConsole adds a dependency on window.h to my project. I'd prefer if the solution didn't involve adding WinAPI code. – MartinVeronneau Jan 20 '16 at 20:14
  • @MartinVéronneau Oh, okay then. I assumed you were using `Windows.h` because you are doing Windows programming. – user4520 Jan 20 '16 at 20:21
  • 3
    @szczurcio : That wasn't expressly stated, but it's cross-plateform development. I'm just using VS2015 under Windows. – MartinVeronneau Jan 20 '16 at 20:32
  • 1
    On Windows, AllocConsole is the only way for a GUI application to get a console window. If you need cross-platform compatibility, you'll have to hide that detail in an abstraction. – Adrian McCarthy Jan 21 '16 at 00:20
  • The other option is to build your application as a console application, since console applications can create GUI windows. – Adrian McCarthy Jan 21 '16 at 00:21
  • 2
    @AdrianMcCarthy That's what I'm doing when I omit the -mwindows parameter. Keep in mind, as I said, that I have a working console, as long as I don't run from Visual Studio. – MartinVeronneau Jan 21 '16 at 14:28
  • Have you looked in `Menu->Tools->Options..." then "Debugging" for some setting which might control this? – Ben Jan 21 '16 at 15:54
  • 2
    @Ben Yes I did. The only settings I thought would be helpful was "Redirect all Output Window text to the Immediate Window". Unfortunately, the Immediate Windows has the same probleme than the Debug Console, so I reverted the option back. From my search in SO, I understand the console is supposed to be used for debugging variables, so it gets a special formatting to support that. Why in blazes did Microsoft thought it could replace a proper console is beyond me... – MartinVeronneau Jan 21 '16 at 16:17
  • 1
    Maybe write to a file and use tail on it from elsewhere – rep_movsd Apr 30 '16 at 21:31
  • 1
    That's a good workaround, @rep_movsd. Thanks! But I'd much prefer Visual Studio to not try to be clevere than me. – MartinVeronneau May 02 '16 at 17:43
  • The framework I use a lot calls "https://msdn.microsoft.com/en-us/library/windows/desktop/aa363362%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396" OutputDebugString to handle printing to the VS output window and successfully handles a \n. Maybe that'll help? – JCx May 09 '16 at 20:47
  • Add an option to your program to `popen` a logger (another configurable program) and output to the resulting `FILE`. A logger can be a one-line shell script, or it can be as complicated as you need. Now if you want to change logging behaviour, you only need to substitute the right logger without touching the main program. – n. m. could be an AI Jun 07 '16 at 15:22
  • @n.m. That's actually pretty clever, and I think I'll use this approach in the future. – MartinVeronneau Jun 07 '16 at 15:25

1 Answers1

1

I was contacted by a Senior PM Manager for Visual Studio at Microsoft regarding this issue. I posted it as a "feedback" inside Visual Studio, about four months ago (around the time I posted it here)..

He acknowledged the problem, and said they're gonna try to add support for external consoles with Update 3.

MartinVeronneau
  • 1,296
  • 7
  • 24
  • Is there a public issue ID? E.g. a URL to the issue report. – bahrep Jul 18 '16 at 13:01
  • Unfortunately, not one that I'm aware of. The discussion with the PM Manager (sic) was very formal. I was glad he reached out, though. This shows that you can actually get something out of sending feedback by VS. – MartinVeronneau Jul 18 '16 at 13:52
  • I just thought about some issue entry like this one https://connect.microsoft.com/VisualStudio/feedback/details/807715/making-any-change-to-a-resource-only-dll-project-causes-a-dialog-definition-to-change-an-become-invalid – bahrep Jul 18 '16 at 13:54
  • No, there is nothing like that. – MartinVeronneau Jul 18 '16 at 14:00