Ouvrir une Form aussi bien à partir d'une appli Console que d'une Windows FormRésolu

Question

Bonjour,
j'ai besoin de créer une classe dans une Dll qui peut ouvrir une Windows Form. Cette classe peut aussi bien être appelée d'une application en mode console que d'une Windows Form. Pour les besoins de l'exemple, nous appellerons cette classe 'CalledForm'.
Pour l'instant, voici les options autour desquelles j'ai prospecté:

1/ la Form est ouverte avec Application.Run(CalledForm):
   a. mode Console: il faut que CalledForm soit fermée pour que ce qui est envoyé à la console soit lu.
   b. mode Form: plein de problèmes, soit des exceptions, soit CalledForm s'affiche à la place de l'autre Form, etc.

2/ la Form est ouvert avec CalledForm.Show()
   a. mode Console: CalledForm s'ouvre, mais ne se dessine pas, et le curseur se met en sablier (la Form se bloque)
   b. mode Form: tout va bien. Ca semble bien la méthode idoine.

après investigation sur le net, j'ai mis en place une solution tierce, qui consiste à 'threader' l'appel à Application.Run, dont voici les bases:
public partial class CalledForm: Form  , ----
{                 , ----
        private Thread m_localThread = new Thread(Run);  , ----
        private static void Run(Object frm)  , ----
        {  , ----
            Application.EnableVisualStyles();  , ----
            Application.Run((Form)frm);  , ----
        }  , ----
        public void ThreadedShow()  , ----
        {  , ----
            if (!m_localThread.IsAlive)  , ----
                m_localThread.Start(this);  , ----
        }  , ----
 }
 
3/ dans ce cas là, si la Form est ouverte avec CalledForm.ThreadedShow()
   a. mode Console. Tout va bien. C'est clairement la méthode recommandée.
   b. mode Form: ça marche, mais ce n'est pas optimale (CalledForm est clairement plus lente) et elle n'est pas fermée quand on quitte l'appli principale.

Ma question est donc, comment puis-je, par programmation, savoir dans quel mode je suis, pour pouvoir appeler la bonne méthode (Show() ouThreadedShow()) ?

A savoir:
 j'ai essayé Application.OpenForms, qui s'avère peu fiable, on peut se trouver dans des cas ou ça renvoie 0 alors que des formes sont en construction.
 j'ai égalemet essayé GetStdHandle et GetConsoleModemais ce n'est pas plus fiable non plus.

cs_eldim · Accepted Answer

Merci de l'indication j'aurai jamais trouvé...

-- Y a autant de bugs dans un programme que de malles-façons dans une maison. Tout dépend de la taille --

cs_eldim · Answer

Bonjour,

je ne vois pas bien la subtilité... sur mes applis, que l'appelle se fasse sous DOS ou Windows les form s'affichent pareil...
sans passer par un intermédiaire... suffit d'avoir winodws form en référence et de commencer ton programme par un static void main

-- Pourquoi faire simple quand on peut faire compliquer  --

eTill · Answer

Bonjour eldim.
De mon côté, les Forms ne réagissent pas pareilles, justement, c'est bien là le problème.
J'ai essayé de décrire les problèmes que je rencontre, et pour quelles raisons.

Attention, il ne s'agit pas d'un appelle d'une même Application à partir de la console (écrire le chemin de l'exe dans une fenêtre .cmd) vs son appel GUI (double click sur l'icône ou autre). Là, effectivement, c'est simple.

Le problème survient quand deux appli qui ont un mode d'exécution différents (CUI vs GUI) s'appuient sur une même DLL avec Form. Quelle méthode cette Dll doit offrir à l'application appellante pour que la fenêtre s'ouvre proprement Application.Run(CalledForm) ? CalledForm.Show() ? CalledForm.ThreadedShow() ?

C'est effectivement compliqué, et je m'en serais bien passé...

cs_eldim · Answer

je dois être mal réveillé car j'ai aussi une appli (par contre en vb.net mais c'est pareil)dont le corps est dans une dll et qui est appelée de plusieurs façon y compris en DOS et windows et en mettant le show directement dans la dll et non dans l'application et j'ai aucun souci
j'appel juste une procedure de la dll qui fait elle même le show

-- Pourquoi faire simple quand on peut faire compliquer  --

eTill · Answer

Ce dont je parle est assez facilement reproduisible:
Créer une nouvelle solution
Créer un premier projet de type ClassLibrairy avec juste une Form nommée 'CalledForm' dedans.
C'est plus flagrant si la Form a au moins un contrôle dedans (un simple Label suffit).
Créer un deuxième projet de type ConsoleApplication, avec ce code dedans:

class
Program
{

   static
void Main(
string[] args)
   {
   
CalledForm calledForm = 
new
CalledForm();
   calledForm.Show();

   //System.Windows.Forms.Application.Run(calledForm);
   Console.WriteLine(
"Ouvert!");

   Console.ReadKey(
false);
   }
}

cs_eldim · Answer

ben désolé chez moi ça marche nickel
juste que ton show serait mieux avec un showdialog... (mais bon c'est le ba-ba)

-- Pourquoi faire simple quand on peut faire compliquer  --

eTill · Answer

C'est bien un Show() que je veux faire.
Un ShowDialog() rend la fenêtre modale, à savoir que la fenêtre doit être fermée pour que le programme principal continue de tourner, ce qui n'est pas ce dont j'ai besoin.
Effectivement, avec un ShowDialog (ou Application.Run(CalledForm)) la form s'ouvre. Mais fenêtre et console ne peuvent interagir.
Et c'est de façon certaine ce que je ne veux pas dans le cas où le module appelant est une Form.

Tu trouveras description de pb similaire dans le sujet de discussions Windows Form depuis application appli Console
http://www.csharpfr.com/infomsg_WINDOWS-FORM-DEPUIS-APPLICATION-APPLI-CONSOLE_1083719.aspx

cs_eldim · Answer

dans ce cas il te faut passer par un thread différent
et dans le load de ta form tu rajout un threading.thread.sleep(1)




-- Pourquoi faire simple quand on peut faire compliquer  --

eTill · Answer

Oui,
d'où la mise en place du 'ThreadShow'.
Mais l'utiliser systématiquement n'est pas efficace, en tout cas il dessert mes besoins dans le cas où le module appelant possède une Form.
Voilà où j'en suis arrivé et pourquoi je poste ce sujet.

Sinon, à quoi servirait le Sleep(1)?

cs_eldim · Answer

je connais pas le threadshow
c'est juste que je l'aurais fait comme ça:
Threading.Thread TH=new threading.thread( AdresseDeTaProcQui lance ta form)
TH.Start

et dans ta proc qui lance ta form ou dans le load de ta form
le sleep qui rend la main à ta procedure dos (ce qui fait que tu as deux procedures en parallèle)

-- Pourquoi faire simple quand on peut faire compliquer  --

cs_eldim · Answer

oups j'avais pas fait gaffe
c'est là que j'aurai pas fait comme toi..
mais j'ai pas les neurones connectés ce matin

-- Pourquoi faire simple quand on peut faire compliquer  --

cs_eldim · Answer

tu peux toujours tester si ton appli dispose d'un mainwindowhandle pour savoir quel type d'ouverture utiliser

-- Pourquoi faire simple quand on peut faire compliquer  --

eTill · Answer

Je n'ai pas essayé directement avec MainWindowHandle, mais avec Application.OpenForms(). Malheureusement, ce n'est pas un test fiable, entre autre au moment des differentes initialisations, où les fenêtres ne sont pas toutes forcément ouvertes. Je soupçonne que le pb risque d'être le même, mais je vais essayer.

eTill · Answer

Une appli console me retourne un MainWindowHandle non nul, malheureusement.

static
void Main(
string[] args)
{
System.Diagnostics.
Process cp = System.Diagnostics.
Process.GetCurrentProcess();

IntPtr wh = cp.MainWindowHandle;
Console
.WriteLine(
wh.ToString());

Console.ReadKey(
false);

}

cs_eldim · Answer

c'est du bricolage mais tu peux essayer de vérifier si une référence à windowsform est présente avec ça
system.Reflection.Assembly.GetCallingAssembly.GetReferencedAssemblies

-- Pourquoi faire simple quand on peut faire compliquer  --

eTill · Answer

Hmm, c'est très risqué, car cette info est très peu représentative de la réalité.
Je peux imaginer d'ores et déjà plein de cas de figure où une référence à une WindowsForm existe mais où je suis dans le cas d'un appel 'Console'.
Encore moins fiable que Application.OpenForms().
J'aimerais trouver un jeu de tests totalement fiables.
Merci tout de même.

cs_eldim · Answer

essai de regarder du coté des flux
lorsque l'appli est en mode console les flux de sortie sont redirigé par une api (je ne sais plus laquelle)
le tout c'est de trouver comment j'ai pas trop de temps cet aprem... mais je vai chercher

-- Pourquoi faire simple quand on peut faire compliquer  --

cs_eldim · Answer

essai ça
Process.GetCurrentProcess.StartInfo.RedirectStandardOutput

-- Pourquoi faire simple quand on peut faire compliquer  --

eTill · Answer

Il me retourne false dans tous les cas...

cs_eldim · Answer

tu peux faire un truc pas très propre en attendant de trouver mieux
si ça ça plante : Process.GetCurrentProcess.StandardOutput

c'est que c'est pas du dos

-- Pourquoi faire simple quand on peut faire compliquer  --

eTill · Answer

Non, c'est pas ça. ça plante dans tous les cas. Ces options n'ont de sens que lorsqu'on veut récupérer/rediriger la sortie standard. Ce n'est pas ce qu'on cherche, ça peut être activé/désactivé aussi bien pour des appli CUI que GUI. Mais je vois que tu t'accroche . J'apprécie.

cs_eldim · Answer

tiens ça devrait être mieux
[DllImport("kernel32.dll")]
public static extern int GetConsoleWindow();

-- Pourquoi faire simple quand on peut faire compliquer  --

cs_eldim · Answer

aussi si tu test avec une winform : console.Title


ça plante mais pas avec une appli console

-- Pourquoi faire simple quand on peut faire compliquer  --

eTill · Answer

Il faudrait que j'essaye un peu plus avant ces solutions (du moins l'avant dernière), car je les ai vues suggérées pour des questions similaires aux miennes.
Mais mon analyse est que ça donne des infos sur la console du process en cours.
Or dans mon cas de figure, quand bien même la fenêtre est appelée par une appli en mode GUI (donc c'est un Show() qui doit être utilisé), rien ne me dit qu'il n'y a pas quand même de Console d'ouverte (il suffit d'avoir fait un AllocConsole pour ça).
Donc si je m'appuie sur une info de ce genre, je lancerais un 'ThreadedShow()' ce que je veux éviter...

cs_eldim · Answer

j'ai testé l'api pour voir et ça semble marcher

-- Pourquoi faire simple quand on peut faire compliquer  --

eTill · Answer

Tu aurais un bout de code pour ça?

cs_eldim · Answer

en fait c'est pas comliqué
[DllImport("kernel32.dll")]
public static extern int GetConsoleWindow();

ensuite si GetConsoleWindow==0 alors c'est une application windows

-- Y a autant de bugs dans un programme que de malles-façons dans une maison. Tout dépend de la taille --

eTill · Answer

A creuser, mais il y a des cas de figures où GetConsoleWindow!=0 et c'est une appli windows quand même (cf précédement, un AllocConsole a été appellé juste avant)...
J'ai testé, c'est bien ce qui se passe. Donc l'info n'est pas 100% équivalente.

cs_eldim · Answer

purée...  on est pas rendu si tu te mets à faire un switch par cas existant dans le monde
si tu fais juste ce qui suit tu t'emmerderas moins :) (même si c'est un showdialog, le fait qu'il soit dans un thread à part te laisse la main pour continuer ton programme)
void A()
{
   Threading.Thread TH=new Threading.Thread(B);
   Th.Start
   /*Code de ton programme dos ou windows*/
}
void B()
{
   Threading.Thread.Sleep(1)
   System.Windows.Forms.Form F=new Form;
   F.ShowDialog();
}

-- Y a autant de bugs dans un programme que de malles-façons dans une maison. Tout dépend de la taille --

eTill · Answer

Comprends bien que le but est de faire une Dll robuste, utilisable par tout le monde sans trop de 'Flags' obscures. Donc je me dois de penser à tous les cas de figure dans lesquels elle peut être utilisée, au minimum détecter les raisons de son malfonctionnement.
Ce que tu me proposes est équivalent à la solution ThreadedShow que je proposais dans le début de la discussion (donc tout à fait pertinente ).
Comme je m'en suis apperçu, cette solution n'est pas performante dans 90% des cas, à savoir une bonne appli GUI standard (comparée à un simple Show)
C'est bien pour ça que je pose la question, je me suis rendu compte que la réponse à mon problème était assez tordue, et que j'avais besoin de la comunautée et des experts pour aller jusqu'au bout du truc.

J'ai tj considéré que mon rôle de programmeur n'était pas de me faire chier le moins possible à programmer, mais d'utiliser toutes les ressources à ma disposition pour faciliter la vie de l'utilisateur.
Si on peut faire du code simple et élégant, tant mieux. Si on doit un peu mettre la main dans le cambouis, et bien... tant pis, on retrousse ses manches, et on y va.
Ca n'engage que moi, évidemment...

cs_eldim · Answer

ben tu comprendras d'ici quelques années qu'un code simple est beaucoup plus robuste qu'une usine à gaz... (à méditer longuement)

-- Y a autant de bugs dans un programme que de malles-façons dans une maison. Tout dépend de la taille --

eTill · Answer

Ta remarque est très vraie en général, mais ça ne m'aide pas beaucoup dans le cas présent.
Bon, tâchons de simplifier le pb.

1/ La Dll est appellée à partir d'une Appli qui va executer un Application.Run à un moment où à un autre (90% des cas de figure, voire plus) => il me semble bien que la meilleure solution est un simple Show(). Me trompe-je?

2/ La Dll est appellée et sera la seule à lancer un Application.Run, (je pense que c'est préférable à ShowDialog) => ThreadedShow ou équivalent.

Y a-t-il un moyen simple pour savoir si on est dans un des deux cas?

Suis-je passé à côté de qq chose et on peut aborder le pb autrement?

Il y a évidement une solution très simple, c'est que le module appellant choisisse.
Si je post, c'est pour savoir si on peu envisager une alternative automatisable.

eTill · Answer

J'avais également posté la même question sur le forum de 'developpez.com' (Ici.).
SirJulio m'a proposé une solution qui m'a l'air tout à fait acceptable, je l'en remercie. Je vais tâcher de la résumer ici.

Une application de type Console a priori ne gère pas de boucle de message. Donc l'information Application.MessageLoop donne une info très pertinente dans 99 % des cas. Du moins au sein d'un même Thread.
J'ai fait qq tests un peu tordus, en mixant des Threads, et ça réagit bien. Pour la robustesse, il va falloir border tout ça, mais ça me semble une bonne base de départ, et ça m'évite de pousser l'utilisateur (de la Dll) à gérer le contexte d'utilisation (jusqu'à ce que je me trouve face à un cas extrêmement tarabiscoté, ceci dit...).

Sinon, il a une recommandation également à prendre en compte en ce qui concerne le mode 'threaded'. A savoir que toute la gestion de la Form devrait être 'threaded' plutôt que seulement l'affichage (instantiation et autre manipulation comprises). Ce qui rend l'implantation un peu plus complexe que ce qu'on avait envisagé.
Un certain degré de complexité visiblement difficile à ignorer.

Merci à toi eldim pour avoir suivi cette discussion et creusé comme tu l'as fait.

Ouvrir une Form aussi bien à partir d'une appli Console que d'une Windows Form

33 réponses

Votre réponse

Discussions similaires