Bonjour,
Je voulais savoir comment afficher une MessageBox à partir d'une application console?
Je ne peux pas importer System.Window.Form
:?
Merci!
Version imprimable
Bonjour,
Je voulais savoir comment afficher une MessageBox à partir d'une application console?
Je ne peux pas importer System.Window.Form
:?
Merci!
Une application console n'est pas censé afficher de boite de dialogue.
Pourquoi tu ne peux pas utiliser System.Window.Form ?
Une messagebox est une forme, alors sans System.Window.Form on ne doit pas pouvoir en créer une.
Enfin rien ne t'empeches de rechercher sur le web l'équivalent de la msgbox, mais je crois que tout ce que tu trouveras utiliseras le namespace cité.
Ta question est un non-sens, désolé.
Le MessageBox étant une classe de l'espace de nom System.Windows.Forms que tu ne veux pas importer (pourquoi ? 8O enfin, ça te regarde) tu dois te douter qu'il n'y a pas de solution à un problème posé de cette manière.
Bon, tu peux toujours appeler la fonction MessageBox de l'API du SDK, mais je ne vois vraiment pas l'avantage.
Non ne "peux" pas, c'est cela qui est étrange.Citation:
tu ne veux pas importer
Désolé, mais ce genre de formulation (sans argument) me laisse de glace :DCitation:
Envoyé par ced600
Je parie que pour lui, "importer" c'est mettre un using dans le code.
Il manque donc la référence vers la DLL de WinForms...
Le non sens c'est bien d'afficher une messagebox dans une appli console...
C'est une appli console, même si on importe Windows.Forms, et que l'on demande l'affichage de la messagebox, je doute qu'il se passe quelque chose...
Pour moi aussi :mrgreen:Citation:
Envoyé par Kaidan
Faut que le compilo me gueule dessus pour que je pense à aller voir si l'assemblie est présente, ou si faux que je lui dise d'aller la chercher :D
Et pourquoi ? les MessageBox sont d'usage universel, même en "last resort" dans les services, y compris dans l'OS (regarde l'utilitaire RegSvr32 par exemple)Citation:
Envoyé par Chubyone
N'importe quoi ... :lol:Citation:
C'est une appli console, même si on importe Windows.Forms, et que l'on demande l'affichage de la messagebox, je doute qu'il se passe quelque chose...
N'oublie pas de signaler cela à Microsoft.Citation:
Envoyé par ced600
Blague à part, cette affirmation est un non sens : les boites de dialogues sont utilisées partout, alors pourquoi pas dans la console. C'est pratiquement la seule manière de s'assurer que, en cas de problème, un process console, demandera une interaction utilisateur stoppera sans continuer à lire depuis les redirections (par exemple).
Affirmer cela démontre juste un oubli complet de l'usage des appli console avec redirections des I/O dans les scripts.
Right (en plus je l'avais deja fais en transformant la sortie d'un projet winform en console tester son lancement :roll: ) (:aie:owned)Citation:
Envoyé par Bluedeep
Je me suis mélangé les pinceaux avec le type de sortie, en fait c'est lorsque l'on choisis une sortie Windows Forms que la console ne s'affiche pas meme si on "Console.W.."
Mais je trouve toujours ca idiot si à la base c'est un projet console... (ca doit etre des restes psychologiques du monde ligne de commande qui me dit "pas de souris ni de fenetres"...)
D'un point de vu conceptuelle cela n'a pas de sens.
Une application console n'a pas pour but d'afficher des msgbox.
L'affichage tu le fait en texte dans la console.
Ok pour le débugage, c'est sympas d'avoir un msgbox qui te saute à la figure, mais après on les supprime toutes.
Si tu fais une appli console c'est justement pour ne pas t'enmerder avec les formes.
Du genre un projet où tu est chargé de développer un composant qui fait divers calcul. Tu montes un projet consoles pour tester facilement les résultats de tes calculs.
bref si le projet doit contenir des formes, et que l'on veut un affichage dans une console dos par nostalgie, tu te fais une application windows donc avec les formes, et tu utilises une riche text box pour écrire le texte dedans.
Tu mets un fond noir et tu écris en blanc et ça le fait !!!
Bon, alors explique moi comment tu gère l'interaction utilisateur optionelle lors de redirection d'I/O. (le but d'une appli console est souvent de pouvoir être scriptée, donc d'utiliser les "<" et les ">"" et les "|").
Un TextBox classique aussi :roll:
On recup pas comme args les redirections genre > et | ?
Non, c'est pour pouvoir faire des redirections via script.Citation:
Envoyé par ced600
POur cela, il y a une solution simple : redirection des sorties Console sur un pipe que tu lis dans tes formes.Citation:
bref si le projet doit contenir des formes, et que l'on veut un affichage dans une console dos par nostalgie, tu te fais une application windows donc avec les formes, et tu utilises une riche text box pour écrire le texte dedans.
Tu mets un fond noir et tu écris en blanc et ça le fait !!!
Heu... en général si tu fais ce genre de chose c'est que tu ne comptes pas utiliser les forms non ?Citation:
Envoyé par Bluedeep
Surtout si tu l'utilises dans un script pour automatiser un procéder.
Donc tu utilises un projet console, sans y mettre de form.
Mais si tu veux il est possible de recréer une console dos dans un projet windows application.
Comment repéré les < >, ..... bah tu les recherche dans la string que tu récupères de la RTB, et tu associes une action à un symbole particulier :D
Bon, j'ai l'impression de parler à un mur.Citation:
Envoyé par ced600
Mais cela n'a rien à voir !!!! je te parles de redirection des IO.Citation:
Mais si tu veux il est possible de recréer une console dos dans un projet windows application.
Comment repéré les < >, ..... bah tu les recherche dans la string que tu récupères de la RTB, et tu associes une action à un symbole particulier :D
Et cela n'est possible qu'en mode Console et n'exclue nullement la possibilité d'envoyer un message d'erreur ou de warning utilisateur, qui serait si tu n'utilises pas les MessageBox redirigé vers le fichier de sortie, ce qui est absurde.
On ne voit pas ce que les symboles viennent faire ici.
Cette discussion vient d'ailleurs surtout de me montrer une chose : les messagebox dans les appli consoles sont indispensables (je ne l'avais jamais vu sous cet angle avant, mais l'erreur des autres éclaire parfois :D )
Attends je ne suis pas un pro des instructions en ligne de commande mais
dir > toto.txt cela t'écrit dans un fichier le resultat du dir.
C'est faisable dans une application windows.
Tu peux te faire une classe pour gérer les redirections. C'est juste envoyé le contenu de la string vers ailleurs.
Mais je ne dis pas amusé vous à refaire une console dos, ça sert à rien de réinventer la roue, je dit juste que c'est possible.
Et lors que tu veux utiliser une application console dans un script notemment pour faire des redirections entrées/sorties, tu te contrefiche des form.
Donc d'un point de vue conception il n'y a pas de sens à imaginer utiliser des box dans une application console !!!!!
Faux !!!!! Je ne suis pas d'accord.Citation:
Cette discussion vient d'ailleurs surtout de me montrer une chose : les messagebox dans les appli consoles sont indispensables (je ne l'avais jamais vu sous cet angle avant, mais l'erreur des autres éclaire parfois )
C'est même une hérésie je dirais.
Va pas commencer à me foutre plein de fenetre dans une application console me.....
C'est pas parce que windows n'a plus de dos, et que la console dos n'est qu'une fenetre comme une autre que cela change les choses d'un point de vue conception !!!!!!
Visiblement, tu ne comprends pas à quoi sert une appli console.Citation:
Envoyé par ced600
Donc, je te repose la question : comment gére tu une erreur récupérable utilisateur (type "File in use") dans une appli console s'exécutant en redirection ?
[diplomate]
Je pense que n'ayant pas les même expériences de développement ni les même besoins de développement, les opinions divergent quand à la meilleure façon d'obtenir un résultat semblable.
Pour amener tout le monde à cloturer un débat stérile nécessitant trop de démonstrations réelles pour apporter des arguments de poids je vous propose de nous satisfaire tous ensemble sous la même croix :
"Si on réponds au besoin en prévoyant le maximum de divergences, d'erreurs, et d'évolutions possibles, nous avons déjà fait du bon boulot..."
Le vrai problème est que je parle de concept, et que Bluedeep me parle de réalisations technique.
Je fait une rapelle :
1) un soft se conçois.
2) un soft se réalise.
La réalisation à l'aide d'une technologie précise peut différer de la conception du fait des spécifications de la technologie.
Faux dire là que je n'ai pas compris ton histoire.Citation:
comment gére tu une erreur récupérable utilisateur (type "File in use") dans une appli console s'exécutant en redirection ?
Tu veux mettre en attente le soft jusqu'à ce que l'utilisateur libère le fichier, alors qu'il ne vois pas le texte car redirigé dans un fichier ?
Je dirais qu'il faut déjà comprendre pouquoi on fait une redirection vers un fichier. Créer un fichier log ? Le soft devrait gérer cela lui même et pas besoin de redirection.
Donc tu voudrais lui balancer une msgbox pour qu'il réagisse ?
Tu fais quoi si tu doit développer la même application sous un système d'exploitation qui n'a pas de fenêtre ? Qui est juste un mode console. Dos par exemple ?
Moi je pense que dans un cas comme cela lors de la conception on prévois que le soft doit pouvoir intéragir avec l'utilisateur tout en offrant la possibilité de rediriger le résultat afficher dans fichier.
Une solution est de passer en argument le nom d'un fichier pour activer un log auto des messages afficher à l'écran, laissant ainsi l'écran pour l'interaction avec l'utilisateur.
Une autre solution peut être la tienne, redirection de la sortie et utilisation de msgbox pour alerter l'utilisateur.
Toutes solutions proposés doit être justifiés de toute façon et en fonction du contexte on choisis l'une ou l'autre.
Mais on est bien à deux niveaux différents. Entre la conception de l'architecture, une conception préliminaire, et la partie réalisation une conception plus détaillé.
Tout logiciel doit être conçu de façon indépendant de la technologie et affininé en fonction des choix technologiques !!!!
C'est un point sur lequel je suis d'accord.Citation:
Envoyé par ced600
Pas forcément un fichier.Citation:
Tu veux mettre en attente le soft jusqu'à ce que l'utilisateur libère le fichier, alors qu'il ne vois pas le texte car redirigé dans un fichier ?
Un truc du style
Une redirection via pipe.Code:MyConsoleApp1 < dataentryfile.txt | MyConsoleApp2
Tu associe redirection et log. C'est très réducteur.Citation:
Je dirais qu'il faut déjà comprendre pouquoi on fait une redirection vers un fichier. Créer un fichier log ? Le soft devrait gérer cela lui même et pas besoin de redirection.
Par exemple tu faisCitation:
Donc tu voudrais lui balancer une msgbox pour qu'il réagisse ?
C'est du microsoft pure et tu peux afficher une messagebox si ton action se passe mal.Code:For(%%I in XYZ) RegSvr32 %I
Je n'ai pas souvenir d'avoir développé quoique ce soit en DOS de ma vie.Citation:
Tu fais quoi si tu doit développer la même application sous un système d'exploitation qui n'a pas de fenêtre ? Qui est juste un mode console. Dos par exemple ?
Et la question n'est d'ailleurs pas là, car on a un système qui a des fenêtres. C'est comme demander comment gérer les switchs de context si tu as un processeur Intel 4004.
Tout à fait et les MessageBox constitue une solution parfaire à cet enoncé.Citation:
Moi je pense que dans un cas comme cela lors de la conception on prévois que le soft doit pouvoir intéragir avec l'utilisateur tout en offrant la possibilité de rediriger le résultat afficher dans fichier.
Tu contraints ton développement en introduisant une contrainte de contexte d'exploitation gérée nativement par le système; c'est pas très logique.Citation:
Une solution est de passer en argument le nom d'un fichier pour activer un log auto des messages afficher à l'écran, laissant ainsi l'écran pour l'interaction avec l'utilisateur.
La nature des interactions utilisateurs est quelque chose qui s'aborde assez tardivement dans la conception. A ce moment, les choix technologiques "macro" sont faits (client lourd ou léger, par exemple).Citation:
Tout logiciel doit être conçu de façon indépendant de la technologie et affininé en fonction des choix technologiques !!!!
Arreter de vous b..... le cerveau avec ces concepts philosophiques, sous tout les OS il y a des programmes console qui affichent des forms. Un messagebox n'est rien d'autre qu'un standalone form.
Qui n'a jamais fait sous linux de mon "programme_console /gui" en ligne de commande ? Pourtant ça affiche bien la gui et personne ne va se plaindre chez le développeur avec une ceinture de dynamite. Faut arrêter de vous prendre la tête pour rien. :roll:
Je te rapelles que ta redirection ne va faire qu'écire les données afficher sur la console ailleurs.Citation:
Tu associe redirection et log. C'est très réducteur.Citation:
Citation:
Je dirais qu'il faut déjà comprendre pouquoi on fait une redirection vers un fichier. Créer un fichier log ? Le soft devrait gérer cela lui même et pas besoin de redirection.
Le log est à définir, dans ton cas cela pourrais les affichages sur la sortie standards.
Tu fais déjà un choix de technologie là.Citation:
C'est du microsoft pure et tu peux afficher une messagebox si ton action se passe mal.
A ce que je sache l'UML qui est prévu pour la conception se place dans un contexte hors choix d'un OS. Les diagrammes UML sont correctes quelque soit l'OS.
Si la question est là, dans les premières phases de conception, notemment celle ou tu définis l'architecture sous forme de composants ne doit pas prendre en compte l'OS. Cela arrive après.Citation:
Je n'ai pas souvenir d'avoir développé quoique ce soit en DOS de ma vie.Citation:
Citation:
Tu fais quoi si tu doit développer la même application sous un système d'exploitation qui n'a pas de fenêtre ? Qui est juste un mode console. Dos par exemple ?
Et la question n'est d'ailleurs pas là, car on a un système qui a des fenêtres. C'est comme demander comment gérer les switchs de context si tu as un processeur Intel 4004.
En ce qui concerne ce post, on propose une solution adpaté à un OS, un langage. Mais je me plaçais au dessus de cela dans mes réponses. Pour mettre peut être en évidence une erreur dans la conception.
Bah tu es d'accord avec moi alors, c'est une solution. Mais ce n'est pas la seul. Et le problème amenant à ces solutions est exposé dans la phase de conception préliminaire. Je dirais même que c plus un souhait.Citation:
Tout à fait et les MessageBox constitue une solution parfaire à cet enoncé.
En fait c même pas cela, la spec pose les problème, la coneption préliminaire pose le modèle pour leur résolution, la conception détaillé propose une implémentation de ces problèmes en fonction des choix technologique fait.
Ce n'est pas illogique c'est une autre solution qui a ses avantages et ses inconvenients.Citation:
Tu contraints ton développement en introduisant une contrainte de contexte d'exploitation gérée nativement par le système; c'est pas très logique.Citation:
Citation:
Une solution est de passer en argument le nom d'un fichier pour activer un log auto des messages afficher à l'écran, laissant ainsi l'écran pour l'interaction avec l'utilisateur.
Avec ma solution tu faire des choses plus fines qu'avec les redirections.
Tout ce qui est interfacage entre composant ou système est définis très tot !!!!Citation:
La nature des interactions utilisateurs est quelque chose qui s'aborde assez tardivement dans la conception. A ce moment, les choix technologiques "macro" sont faits (client lourd ou léger, par exemple).
voilà la solution en simple :
sur ton projet/references,
- click droit : ajouter une référence
- System.Windows.Forms
ensuite tu peux avoir quelque chose du style :
using System;
using System.Collections.Generic;
using System.Text;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
new MessageBoxConsole();
}
}
class MessageBoxConsole
{
public MessageBoxConsole()
{
System.Windows.Forms.MessageBox.Show("salut");
}
}
}
là t'as un beau salut qui s'affiche.
;) Quel Newb :?
c'était les vacances... j'avais oublié la référence
J'ai glissé chef !
Merci !!!
Pas grave cela a généré un débat qui s'est par un :
:mrgreen:Citation:
Nous sommes d'accord sur le fait que nous ne sommes pas d'accord