Possibilité de "spin off" plusieurs threads GUI? (Pas arrêter le système à Application.Run)

voix
20

Mon but

Je voudrais avoir un fil de traitement principal (GUI non), et être en mesure de spin off dans leurs propres interfaces graphiques fils de fond, au besoin, et ayant mon thread principal non GUI continuer à travailler. Autrement dit, je veux que mon principal non GUI-fil pour être le propriétaire de l'interface graphique-fil et non vice versa. Je ne suis pas sûr que cela est encore possible avec Windows Forms (?)

Contexte

J'ai un système à base de composants , dans lequel un dispositif de commande charger dynamiquement les assemblages et les classes instantiates et exécuter une mise en oeuvre commune d' IComponentinterface avec un seul procédé DoStuff().

Quels sont les composants qui est chargé est configuré via un fichier de configuration XML et en ajoutant de nouveaux assemblages contenant différentes implémentations de IComponent. Les composants fournit des fonctions d'utilité de l'application principale. Alors que le programme principal fait c'est chose, par exemple le contrôle d' une centrale nucléaire, les composants peuvent remplir des fonctions d'utilité (dans leurs propres fils), par exemple , le nettoyage de la base de données, l' envoi de courriels, l' impression des blagues drôles sur l'imprimante, ce que vous avez. Ce que je voudrais, est d'avoir un de ces composants pour pouvoir afficher une interface graphique, par exemple avec des informations d'état pour ledit composant l' envoi d' e - mail.

La durée de vie du système complet ressemble à ceci

  1. Application démarre.
  2. Vérifiez le fichier de configuration pour les composants à charger. Chargez.
  3. Pour chaque composant, exécutez DoStuff()pour initialiser et faire vivre sa propre vie dans leurs propres fils.
  4. Continuez à faire principale king-thingy application de travail, pour toujours.

Je ne l' ai pas encore été en mesure d'exécuter avec succès le point 3 si le composant déclenche une interface graphique en DoStuff(). Il suffit simplement arrête jusqu'à ce que l'interface graphique est fermée. Et pas jusqu'à ce que l'interface graphique est fermée le fait la progression du programme au point 4.

Ce serait bien si ces éléments ont été autorisés à démarrer leur propre Windows Forms GUIs.

Problème

Lorsqu'un composant essaie de tirer une interface graphique dans DoStuff()(la ligne exacte du code est lorsque le composant fonctionne Application.Run(theForm)), le composant et donc notre système « gèlera » à la Application.Run()ligne jusqu'à ce que l'interface graphique est fermée. Eh bien, l'interface utilisateur graphique juste tiré au fonctionne très bien, comme prévu.

Exemple de composants. On n'a rien à voir avec l'interface graphique, tandis que les deuxième feux jusqu'à un fenêtres mignon avec des lapins roses moelleux en eux.

public class MyComponent1: IComponent
{
    public string DoStuff(...) { // write something to the database  }
}

public class MyComponent2: IComponent
{
    public void DoStuff()
    {
        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);
        Application.Run(new Form());

        // I want the thread to immediately return after the GUI 
        // is fired up, so that my main thread can continue to work.
    }
}

Je l'ai essayé sans succès. Même lorsque je tente de tirer l'interface graphique dans son propre fil, l'exécution arrête jusqu'à ce que l'interface graphique comme fermé.

public void DoStuff()
{
    new Thread(ThreadedInitialize).Start()
}

private void ThreadedInitialize()
{
    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);
    Application.Run(new Form());
}

Est - il possible d'essaimer une interface graphique et revenir après Application.Run()?

Créé 05/08/2008 à 22:19
source utilisateur
Dans d'autres langues...                            


3 réponses

voix
11

Application.Run méthode affiche un (ou plusieurs) des formes et déclenche la boucle de message standard qui se déroule jusqu'à ce que toutes les formes sont fermés. Vous ne pouvez pas forcer un retour de cette méthode , sauf en fermant toutes vos formes ou forcer un arrêt de l' application.

Vous pouvez cependant passer un ApplicationContext (instad d'un nouveau formulaire ()) à la méthode Application.Run et ApplicationContext peut être utilisé pour lancer plusieurs formes à la fois. Votre application ne prendra fin que lorsque tous ceux -ci sont fermés. Voir ici: http://msdn.microsoft.com/en-us/library/system.windows.forms.application.run.aspx

En outre, toutes les formes que vous montrer non modalement continueront à courir à côté de votre formulaire principal, qui vous permettra d'avoir plus d'une fenêtre qui ne bloquent pas. Je crois que c'est en fait ce que vous essayez d'accomplir.

Créé 05/08/2008 à 22:45
source utilisateur

voix
0

Je ne sais pas si cela est juste, mais je me souviens de la fenêtre en cours d'exécution des formulaires à partir d'une application console simplement en Newing le formulaire et appeler newForm.Show () sur, si vos composants utilisent qu'au lieu de Application.Run (), la nouvelle forme ne doit pas bloquer.

Bien sûr, la composante sera responsable du maintien d'une référence aux formes qu'il crée

Créé 23/05/2009 à 22:57
source utilisateur

voix
0

Je suis sûr que cela est possible si vous pirater à assez dur, mais je vous suggère qu'il est pas une bonne idée.

« Windows » (que vous voyez à l'écran) sont fortement couplés à des processus. Autrement dit, chaque processus qui affiche une interface graphique devrait avoir un message en boucle, qui traite tous les messages qui sont liés à la création et les fenêtres de gestion (des choses comme « cliqué sur le bouton », « fermé l'application », « redessiner l'écran ' etc.

Pour cette raison, il est plus ou moins supposé que si vous avez une boucle de message, il doit être disponible pour la durée de vie de votre processus. Pour exemple les fenêtres peuvent vous envoyer un « quitter » un message, et vous devez avoir une boucle de message disponible pour gérer cela, même si vous avez rien à l'écran.

Votre meilleur pari est faire comme ceci:

Faire un faux formulaire qui est jamais montré qui est votre « application principale » Démarrer appel Application.Run et passer sous cette forme fausse. Faites votre travail dans un autre thread, et les incendies au thread principal lorsque vous avez besoin de faire des choses Gui.

Créé 06/08/2008 à 00:22
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more