Discussion :

[Conscious Ape]

Bonjour à tous,

J'ai un petit soucis avec mon application. Sous Visual Studio 2008 à chaque fois que je la lance, et aussi quelques fois lors de son fonctionnement, l'appli s'arrête, retourne au code et m'affiche:
"L'exception InvalidOperationException n'a pas été gérée"
En précisant:
"Opération inter-threads non valide : le contrôle 'Usb_InfoMain' a fait l'objet d'un accès à partir d'un thread autre que celui sur lequel il a été créé."
Et en surlignant:
"this.uiMain.Usb_InfoMain.Panels[2].Text = "Etat : Connecté";"
dans une de mes méthodes qui se lancent au lancement de l'appli et qui est donc dans ma page CtrlMain.cs.

Je suis allé me renseigner sur les aides indiquées par l'utilitaire concernant les appels inter-threads et cette exception mais je ne sais pas trop par ou commencer.

Quelqu'un a une idée?

[infosam76]

Problème assez connu et déjà discuter plusieurs fois sur le forum, un thread lancé en arrière plan ne peut pas avoir accès un des composants graphiques du thread principal.

Il semblerait donc que vous ayez ce genre de problème, travaillez-vous sur une application multi-thread ?

[Conscious Ape]

Merci infosam76 pour votre réponse,

A vrai dire ce n'est pas moi qui ait développé l'application mais vu sa nature, il me semblerait légitime qu'elle soit multi-thread: C'est un agenda multiutilisateur et ceci :

"this.uiMain.Usb_InfoMain.Panels[2].Text = "Etat : Connecté";"

sert à changer la valeur d'une petite barre d'état en bas de l'application (elle peut afficher par exemple "Mise à jour en cours" et "Envoi des SMS de rappels").
Il me semble que ça serait logique que ce soit du multi-thread, cependant, j'ai été me renseigné sur ces composants et j'ai donc recherché dans mon appli les déclarations de thread, afin de trouver lesquels pouvaient bien être en conflit(je ne savais pas quoi faire d'autre ) bizarrement on dirait qu'il n'y a qu'un seul thread. J'en conclu que je dois mal m'y prendre pour chercher les threads existants.

Pour info, j'ai simplement fais "rechercher toutes les références" de "System.Threading.Thread" et j'ai eu pour résultat:

C:\Users\a.pradel\Documents\ID2 Agenda\src\Controller\CtrlMain.cs - (196, 37) : RapelSMS = new System.Threading.Thread( new System.Threading.ThreadStart( RapelRendezVousParSms ) );
C:\Users\a.pradel\Documents\ID2 Agenda\src\Controller\CtrlMain.cs - (39, 28) : private System.Threading.Thread RapelSMS = null;
C:\Users\a.pradel\Documents\ID2 Agenda\src\MainEntry.cs - (26, 4) : Thread.CurrentThread.CurrentCulture = new CultureInfo( "fr-FR", false );
C:\Users\a.pradel\Documents\ID2 Agenda\src\MainEntry.cs - (39, 46) : System.Threading.Thread.CurrentThread.SetApartmentState(System.Threading.ApartmentState.MTA);
C:\Users\a.pradel\Documents\ID2 Agenda\src\MainEntry.cs - (44, 42) : System.Threading.Thread.CurrentThread.SetApartmentState(System.Threading.ApartmentState.MTA);

Il semble qu'il n'y ait que RapelSMS comme thread... Je ne sais plus trop quoi faire là
Pour info RapelRendezVousParSms, la méthode qui d'après ces lignes, s'exécute sur le thread, est la méthode dans laquelle l'exception est levée.

[infosam76]

Il suffit qu'un seul thread "secondaire" essaie d'accéder à un contrôle UI est vous avez l'erreur

[Conscious Ape]

D'accord, donc une interaction avec un contrôle UI constitue un thread principal implicitement(sans qu'on ait besoin de le déclarer etc...)?

[DotNetMatt]

Ce qu'il faut comprendre c'est qu'une application C# va utiliser un thread pour l'UI (le thread principal), et un nombre variable de threads "secondaires" (les worker threads).

Par défaut, si tu ne gères pas les threads, tu vas travailler exclusivement sur le thread principal, c'est-à-dire celui qui contrôle l'UI. Chacune des tâches va donc s'exécuter l'une après l'autre (ex. faire un calcul puis mettre à jour l'UI). Si le calcul est long, l'UI sera donc freezée tant qu'il ne sera pas terminé...

Pour éviter les freezes, il faut donc déporter les opérations lourdes dans les worker threads. Ainsi si je reprends l'exemple précédent, on va lancer le calcul dans un worker thread, puis quand il sera terminé, le worker thread indiquera au thread principal qu'il faut rafraichir l'UI. Cela permet de ne pas freezer l'UI pendant qu'on calcule puisque le thread principal reste disponible.

Il existe différentes manières de gérer les threads, parmi lesquelles le BackgroundWorker, qui implémente nativement un certain nombre de fonctionnalités qui rendent son utilisation plutôt simple.

Une recherche sur Google avec les mots clefs "c# ui thread and worker thread" te permettra d'approfondir le sujet.

[Conscious Ape]

Merci beaucoup J'ai un petit peu galéré à comprendre mais finalement je suis arriver à corriger le problème en remplaçant cette partie (qui était dans la méthode Load() - Charge les données et l'interface principale de l'agenda):

//Thread pour l'envoi des SMS rappel sur les rendez-vous
RapelSMS = new System.Threading.Thread( new System.Threading.ThreadStart( RapelRendezVousParSms ) );
RapelSMS.Start();

par celle-ci:

BackgroundWorker worker = new BackgroundWorker();
worker.RunWorkerCompleted += new RunWorkerCompletedEventHandler(RapelRendezVousParSms);
worker.RunWorkerAsync();

Et en rajoutant "object sender, RunWorkerCompletedEventArgs args" dans les paramètres de RapelRendezVousParSms()