2015-12-07 4 views
5

Ich habe vor kurzem die Lösung eines älteren Projekts auf Visual Studio 2015 aktualisiert. Die Anwendung führt eine OpenGL-Anwendung. Die Anwendung weist eine separate Konsole für die Ausgabe zu. Ich verwende die Konsole, um relevante Debug-Informationen aus meiner OpenGL-Anwendung auszugeben.Visual Studio 2015 Probleme mit einer angeschlossenen Konsole I/O

Ich habe mein Projekt vollständig aktualisiert und es funktioniert ordnungsgemäß. Mein Problem besteht darin, dass die Konsole bei der Aktualisierung meines Projekts zur Verwendung des Visual Studio 2015 (v140) -Toolset aus dem Visual Studio 2013 (v120) -Toolset keine Informationen anzeigt, wenn ich Konsolenausgabefunktionen (stdio.h oder iostream) verwende. Dies macht das Debuggen ein bisschen mehr zu einem Schmerz.

Um klar zu sein, ich kann mein Projekt zurück, um die Visual Studio 2013 (v120) -Toolset verwenden und die Konsole wird Informationen angezeigt, wenn ich an die Konsole ausgeben.

Hat jemand einen Einblick in einen Grund, warum das neuere Toolset verhindert, dass ich Informationen in meinem Konsolenfenster sehe? Soll ich eine Konsole anders aufbauen?


Link mit gut klar, einfaches Beispiel der Konsolenausgabe Umleitung. (Ich würde mehr Beispiele geben, aber ich bin verknüpfen begrenzt) http://asawicki.info/news_1326_redirecting_standard_io_to_windows_console.html

Beispiel meiner Konsolenausgabe Erstellung:

AllocConsole(); 
long lStdHandle = (long)GetStdHandle(STD_OUTPUT_HANDLE); 
int hConHandle = _open_osfhandle(lStdHandle, _O_TEXT); 
FILE *fp = _fdopen(hConHandle, "w"); 
*stdout = *fp; 
setvbuf(stdout, NULL, _IONBF, 0); 

Antwort

6

Dies:

*stdout = *fp; 

ist ungültig. FILE ist ein undurchsichtiger Typ. Sie dürfen nur einen FILE über die Funktionen der stdio-Bibliothek manipulieren (fopen, freopen, fread, usw.).

Wenn Sie eine der Standard-Streams wieder öffnen möchten, die Konsole zu beziehen, eine unterstützte Möglichkeit, dass zu tun wäre:

freopen("CONOUT$", "w", stdout); 
+0

Vielen Dank für die Bereitstellung einer Lösung für mein Problem. Ein sehr kleines Problem ist ich muss #define _CRT_SECURE_NO_WARNINGS , weil es unsicher ist. Warum sollte ich davor gewarnt werden, dass es unsicher ist, ob es der standardmäßige korrekte Weg ist, den Stream umzuleiten? – Jakey113G

+0

Vor einem Jahrzehnt entschied eine Gruppe bei Microsoft, dass einige Funktionen "unsicher" seien und veraltet sein sollten. Sie "verwarf" einige wirklich gefährliche Dinge (wie bekommt), aber sie waren ein bisschen ... übereifrig. Das Deaktivieren der Verwarnungswarnung ist in Ordnung. Alternativ betrachten Sie 'freopen_s'. –

+0

@JamesMcNellis ist das "CONOUT $" Token dokumentiert? Wäre der offizielle Weg nicht mit _dup2? (https://msdn.microsoft.com/en-us/library/8syseb29.aspx) –

0

prüfen, was in Ihnen ist Debug-> Optionen und Einstellungen-> Debugging-> Ausgabefenster in VS.

Für mich funktioniert gut, wenn im ersten Etikett alles an ist und zweites Etikett aus (Fehler in der Datenbindung).

Die Hoffnung wird funktionieren.

+0

Alles in meinem Debug-> Optionen-> Debuggen -> Ausgabefenster ist wie du es beschrieben hast. Alle allgemeinen Ausgabeeinstellungen sind aktiviert, während alle WPF-Trace-Einstellungen deaktiviert sind. Nur Ausnahmen sind Databinding auf Warning und Natvis Diagnostic messages off gesetzt. Haben Sie es mit dem Toolset Visual Studio 2015 (v140) getestet? – Jakey113G