✔ Konsole abschalten bei WinForms

[keltas]

Hallo,
nach langem Hickhack ist es mir endlich gelungen, unter VS2013prof eine c++/CLI WINForms Anwendung zu projektieren. Jetzt geht aber beim Starten immer zuerst eine Konsole auf, die dann vom Formular überlagert wird. Ich brauche die Konsole nicht. Wie kann man die Ausgabe der Konsole unterdrücken?
Danke und Gruß
Keltas

 

[sheel]

Hi

Sollte definitv nicht so sein.
Ich glaub, die schellste Lösung wäre ein neues Projekt anzulegen
Wobei gabs denn da so Probleme? Bzw. wie hast du es gemacht, dass da ungefragt die Konsole dazukommt?

 

[keltas]

... danke für's Threadaufnehmen.
Ich bin VS2008 Umsteiger. da konnte man noch direkt aus der CLR eine C++ FormsAnwedung projektieren. Bei 2013 scheint das nicht mehr zu gehen, offenbar soll den Leuten C++ abgewöhnt werden. Nach längerem Suchen habe ich dann bei R. Kaiser, dem Verfasser einschlägiger C++ Bücher, eine Methode gefunden. Dazu wird zunächst der Rumpf einer Konsolenanwendung erzeugt. Dann werden über "Projekt | Neues Element hinzufügen | Visuals C++ | UI | Windows Form offenbar die entsprechenden Klassen zugeladen (?) aber wie wird man die Konsole danach wieder los?
Gruß
Keltas

 

[sheel]

Ah sorry, hatte zuerst an C# gedacht (zu schlampig gelesen).
Für C++/CLI gibts in den Projektvorlagen wirklich kein Winformszeug mehr.
Also eine Form hast du schon, was noch fehlt:

In den Projekteinstellungen (vom schon angelegten Projekt), bei der Kategorie Linker
kann man das Subsystem auf "Windows" stellen, und bei den erweiteren Linkersachen den Einstiegspunkt auf main
(heißt evt. leicht anders, weiß es nur auf English)

Dann neu kompilieren und fertig.

 

[keltas]

Windows(/SUBSYSTEM:WINDOWS) - genau, das hab ich auch schon so umgestellt, hilft aber nichts.
Für das Problem muss es doch eine Lösung geben, oder kann man jetzt tatsächlich keine .NET WinForms Anwendungen mehr mit C++ erstellen ohne die Konsole mitzuschleppen? Das sieht vielleicht aus, mannomann!
Bei dem Link unten wird das Problem auch beschrieben und irgend jemand muss auch eine Lösung gefunden haben (in einer Spache, die ich nicht lesen kann), aber da werde ich nicht schlau daraus, zumal mein Browser weissderhimmelwarum die Seite nur plain darstellt:

https://social.msdn.microsoft.com/F...s-application-in-vs-c-2013-rc?forum=vcgeneral

 

[Endurion]

Tut's die Beschreibung aus dem Link von deinem Link nicht?

http://www.bogotobogo.com/cplusplus/application_visual_studio_2013.php

 

[Cromon]

Bei 2013 scheint das nicht mehr zu gehen, offenbar soll den Leuten C++ abgewöhnt werden.

Nö, aber ausser wenn du irgendwelche Bindings zu nativen Libraries machen willst, die sich mit P-Invoke in C# nicht realisieren lassen ist C++/CLI jetzt nicht unbedingt DIE verwaltete Sprache. Ist in C# halt einfach angenehmer und flexibler. C++/CLI wurde vor allem dafür entwickelt den Umstieg von unverwaltet zu verwaltet zu vereinfachen indem man mit relativ wenig Aufwand Wrapper schreiben kann, die dann in C# nutzbar sind. Für C++/CLI mit UI-Elementen findest du eine riesige Palette an Vorlagen für Windows Store Apps.

Was dein Konsolenproblem anbelangt: Du machst es halt grundsätzlich so wie du es auch bei einem normalen C++-Projekt mit Fenster machst. Nicht Konsole als Target sondern Fenster. Wenn du sagst, dass das ändern des Subsystems keine Wirkung hatte, dann hast du das falsch gemacht. Bei dem entsprechenden Target Fenster wird vom Betriebssystem unter keinen Umständen automatisch eine Konsole alloziert. Du kannst dies relativ einfach verifizieren indem du bei einer bestehenden Konsolenapplikation in der exe drin ohne neu zu kompilieren im NT-Header entsprechend das Subsystem von Konsole auf Windows änderst. Keine Konsole wird erscheinen (ausser natürlich der Programmierer hat aus irgendwelchen Gründen selber eine Konsole alloziert). Analog erscheint bei einer Applikation mit Subsystem Windows wieder eine Konsole, wenn du nachträglich manuell es auf Konsole stellst.

Wenn du jedoch nichts an deinem Programm änderst ausser in den Einstellungen das Target erhälst du vermutlich einen Linkerfehler, weil der Compiler je nach Subsystem nach einem anderen Entrypoint sucht. Für Console ist das int main(<int, const char**>), für Windows BOOL WinMain(HINSTANCE, HINSTANCE, LPSTR, INT). Wie im Link von Endurion geschrieben kannst du aber den Entrypoint manuell festlegen und wenn du CLR-Support hast kannst du auch einen CLR-Entrypoint der Form void (*)(array<String^>^) angeben.

Viele Grüsse
Cromon

 

[keltas]

Bingo !!
der Link zu bogotobogo führt zum Rezept. Wie Cromon schreibt, der Fehler oder besser Umweg war, zu Anfang ein Konsolenprojekt anstatt eines leeren CLR Projekts genommen zu haben. Kleine Ursache große Wirkung, darum brauchte man sich bei 2008 nicht kümmern ... Damit ist die Eingangsfrage beantwortet. Euch vielen Dank
Keltas

 

[keltas]

P.S.
Es ist immer suboptimal wenn die Lösung zu einer Frage aus dem Thread herauszeigt, daher kann's nicht schaden, hier noch einmal alles zusammenzutragen und einen kompakten Workflow zum Thema Create a .NET Windows Forms Application using C++/CLI with VS2012 | VS2013 comm | prof abzulegen ... und um nachzusehen, wenn der Text verbummel ist
Danke nochmals
Keltas