Délégation de code à exécuter à partir du thread principal pour gérer gui à partir du thread principal

Question

J'ai du code qui est en cours d'exécution par un arrière-plan Je voudrais un code spécifique qui montre une interface graphique à exécuter dans le contexte thread principal (2 raisons 1. il devrait être bloquant 2. Je sais qu'il est problématique de gérer les contrôles gui à partir d'un travailleur de fond) Je lève un événement passer la classe et écouter l'événement dans la mainForm à partir de là je vérifie si invoquer requis et réinviter. Puis appelez la méthode publique de l'instance que je veux exécuter dans le thread principal. J'ai quelques questions:

1. est-il un problème pour traiter membre de données qui sont créés dans le cadre de backgoundworker du thread principal - pour la lecture et chaning valuse

2. est-il un modèle de conception pour un tel problème? Idealy je voudrais exécuter n'importe quel délégué - n'importe quelle valeur de retour et quelques paramètres de genric - comme func built in delegate - c'est problématique car cela signifie que si je veux supporter jusqu'à 3 paramètres avec ou sans valeurs de retour, je devrai avoir 6 événements et 6 auditeurs qui font la même chose - est-ce que quelqu'un a une idée de comment faire cela correctement? Merci!

Answer 1

Je viens d'écrire ceci pour une question similaire.

J'utilise des fils pour ce genre de choses.

quelque part dans mon code:

// Definition 
private static Thread TH; 

....

// When process starts 
TH = new Thread(new ThreadStart(Splash_MyCallBack)); 
TH.Start(); 

....

// This method starts the form that shows progress and other data 
static private void Splash_MyCallBack() 
{ 
    frmLoading FL; 

    FL = new frmLoading(); 

    FL.ShowDialog(); 

} /* Splash_MyCallBack*/ 

// Your process calls Splash_Stop when it is done. 
static public void Splash_Stop() 
{ 
    TH.Abort(); 
} /* Splash_Stop*/ 

frmLoading effectue la substance visuelle, alors que dans le fond je une tâche très exigeante pour le processeur. Mon processus signale à une interface sa progression. frmLoading implémente cette interface de sorte qu'il en est conscient et peut montrer whaever il est nécessaire (2 barres de progression dans mon cas) Tha seul hic est-frmLoading doit avoir ce dans le constructeur:

Control.CheckForIllegalCrossThreadCalls= false; 

qui peut être risqué dans certains scénarios (pas mon cas).

Je pense que le fait que le processus principal appelle une interface pour mettre à jour la progression, et l'interface réelle consomme un motif. J'espère que cela aide, je peux ajouter plus de choses si vous le souhaitez.

Cordialement,

Answer 2

Pour répondre à votre première question:

Il ne devrait pas y avoir de problèmes de traitement des données créées dans le travailleur de fond. Je l'ai fait dans quelques applications et je n'ai eu aucun problème.