J'ai une application simple que je voudrais traiter d'automatiser via des commutateurs. Mais quand je l'exécute via des commutateurs, je ne veux pas vraiment une interface utilisateur. Je veux juste qu'il fonctionne, faisons son travail, imprime des choses dans la console et sortez. D'autre part si je ne l'exécute pas avec des commutateurs, je souhaite que l'interface utilisateur apparaisse. Et dans ce cas, je ne veux pas vraiment une fenêtre de console accrochée à l'arrière-plan.
Y a-t-il un moyen de faire cela, ou dois-je créer deux projets distincts, une application de console et une application Windows?
7 Réponses :
Bien sûr, il suffit de mettre une instruction de commutation (ou si sinon la construction) dans la principale statique (chaîne [] args), en fonction des arguments passés dans la ligne de commande. Je fais aussi cela pour basculer entre exécuter en tant que service ou sous forme de console ...
Remarque: Définissez le type de projet comme application de console éditer: Merci à Adrian Bank's Réponse, Freeconsole () est une approche bien meilleure de "distribuer" avec la fenêtre de la console que de les minimiser ...
Comment proposez-vous de la mettre en œuvre exactement?
Je pense que la "course en tant que console" et "courir comme Winforms" sont les points intéressants ici cependant. L'OP aurait pu deviner autant.
+1: Je ne vois pas pourquoi cela aurait été évolué ... c'est assez simple et efficace. Si chaque type d'interface utilisateur (formes VS console) est sa propre assemblage, puis le commutateur / si elle chargera l'assemblage approprié et l'exécutera.
System.Windows.Forms.dll devra être référencée pour que cela fonctionne.
Je suppose que les gens descendent parce que ce n'est pas une vraie application de console (ce sont impossibles selon Raymond Chen: blogs.msdn.com/oldnewthing/archive/2009/01/01/9259142.aspx ), mais je pense que l'approche convient au problème de l'OP. Je pense juste que la condition si elle est complètement fausse - devrait être un || Je pense.
Toujours pas de mise en œuvre, Raymond Chen semble penser que c'est une mauvaise idée, et c'est toujours en haut.
Si vous faites ceci à partir d'une application Windows, vous n'aurez pas accès à Stdin et à Stdout pour lire ou écrire des choses à la console. Si vous marquez votre EXE en tant qu'application de console, vous aurez une console suspendue.
Honnêtement ... cela ne dit rien à l'OP.
En effet, cela exécute l'application avec une interface graphique ou la masque ne permettant aucune entrée ou sortie de l'utilisateur comme prévu à partir d'une couche de console.
Ajout de plus de mise en œuvre, en cours d'exécution lorsque l'application Windows provoque l'apparition de la fenêtre de la console, alors j'ai ajouté du code pour la dispenser.
@CHARLES BRETANA: Non, vous avez ajouté le code pour minimiser la fenêtre de la console, non pas "Dispenser avec elle". Ce que vous voulez vraiment, c'est freeconsole (comme dans la réponse de Adrianbanks), mais qui a ses propres problèmes ...
@Daniel, je suis sûr que je savais que mon code a fait, mais j'apprécie votre clarification de moi pour moi {Grin} ... En fait, je voulais dire "DISPENDER" comme dans "Supprimer" de l'écran ". Mais je n'ai pas fait 't sais que "freeconsole" - c'est une meilleure approche ...
Ce sont deux paradigmes différents, je ne pense pas qu'à utiliser un commutateur de ligne de commande comme celui-ci est une bonne idée. Pourquoi ne pas construire la logique principale dans une application de console, puis appeler cela de l'interface graphique en cas de besoin? Cela séparerait judicieusement l'interface utilisateur de la mise en œuvre mais permettrait toujours d'utiliser l'application de console autonome si nécessaire.
Bien que je suis d'accord avec cela, il est parfois utile de disposer d'une seule application qui fonctionne comme console ou gui-visuel studio est un exemple commun de cette ...
Point juste, n'avait pas pensé à cela. Je suppose que c'est une chose assez rare à avoir besoin cependant.
Je pense à faire deux UIS, une console et un graphique, mais oui. La meilleure solution est de les avoir dans un. De cette façon, vous pouvez l'utiliser comme application régulière et utiliser dans un script par exemple.
Mais vous pouvez toujours le faire si vous avez deux programmes distincts, je ne vois pas le besoin de tout embellir en un.
Je crois que la réponse est non, sinon c'était la dernière fois que j'ai examiné ce problème.
L'exécutable est marqué comme une application vitrée ou une application de console. Vous pouvez le voir dans les propriétés pour votre projet dans Visual Studio, sous application, type de sortie
Vous pouvez simuler le comportement en ayant deux applications, une application de console que si elle est exécutée sans argument ne lance l'application GUI. Vous pouvez voir une fenêtre de la console flash, sauf si vous avez couru dans une console déjà ouverte.
Visual Studio fait cette astuce, il existe une application devenv.exe Windows et a application de console devenv.com .
de '"l'ancienne nouvelle chose" < / p>
vous ne pouvez pas.
(Je vais vous laisser cliquer sur l'article pour les détails de la façon de simuler)
sans implémenter votre propre version d'une fenêtre de console, la réponse est non. Lorsque Windows charge vous exécutable, il décide de vous donner ou non une fenêtre de console en fonction de données dans l'en-tête PE. Donc, vous pouvez faire une application vitrée ne pas avoir une fenêtre, mais vous ne pouvez pas faire une application venteuse avoir une console.
Bien que ce ne soit pas exactement ce que vous avez demandé, j'ai atteint l'apparence em> de ce comportement dans le passé en utilisant le freeconsole Pinvoke Pour supprimer la fenêtre de la console.
Vous définissez le type de sortie du projet pour être une application de console. Vous définissez ensuite l'appel externe à puis, dans vous freeconsole code>: p> Méthode principale code> Méthode basé sur vos conditions . Si vous voulez une interface utilisateur, appelez freeconsole code> avant d'ouvrir le formulaire pour effacer la fenêtre de la console. P> if (asWinForms)
{
FreeConsole();
Application.Run(new MainForm());
}
else
{
// console logic here
}
C'est une très bonne approche pour cette situation. Vous pouvez également alloconsole (mon post supprimé l'a montré ceci), mais votre console est détachée de la coque appelante, si elle s'appelle depuis une coquille.
Ne courira plus bien sous Mono, alors cependant, le fera-t-il?
Cela ne fonctionnera pas dans tous les cas, car l'exécutable aura le même en-tête PE qui indique au système s'il est console ou non. Voir Stackoverflow.com/Questtions/7613880/...
Vous pouvez, mais avec des inconvénients:
Vous pouvez empêcher que cette fenêtre noire au démarrage si vous compilez pour les fenêtres du sous-système.
Mais vous devez alors attacher le processus à la console d'appel (cmd.exe) manuellement via Attachconsole (-1) http://msdn.microsoft .Com / fr-US / Bibliothèque / Windows / Bureau / MS681952% 28v = vs.85% 29.aspx
Ce seul ne fait pas le travail. Vous devez également rediriger les trois flux STD à la console via ces appels: échantillon de: http://cygwin.com/ml/cygwin/2004-05/msg00215.html Le problème avec votre WinMain L'appel est que Windows a déjà été adapté à votre processus afin que la console CMD.EXE appelante soit déjà renvoyée de votre fichier .exe et procédez à la commande suivante.
Pour éviter que vous puissiez appeler votre exe avec S'il y a un moyen d'empêcher que le processus de recherche de fenêtres de sous-système, faites-moi savoir. J'espère que cela aide. start / wait myexe.exe
De cette façon, vous obtenez également la valeur de retour de votre application et vous pouvez le vérifier avec% errorLelvel% comme d'habitude.
Avez-vous essayé simplement d'insérer votre code dans la fonction principale () générée lorsque vous créez une application WinForms? Au lieu d'appeler Application.Run ()?
Un peu connexe, surtout si vous souhaitez écrire à la console à partir d'une application Windows: Stackoverflow.com/questions/666823/...