Textbox et deadlock [Résolu]

leprov 1163 Messages postés vendredi 23 juillet 2004Date d'inscription 21 octobre 2010 Dernière intervention - 4 févr. 2008 à 08:56 - Dernière réponse : cs_coq 6366 Messages postés samedi 1 juin 2002Date d'inscription 2 août 2014 Dernière intervention
- 10 févr. 2008 à 15:36
Bonjour a tous,

Bon comme d'habitude j'ai un soucis tordu et tiré par les cheveux...
Bon j'ai une architecture qui ressemble grosso modo a un truc comme ca :
Thread principal avec IHM
Thread secondaire qui execute un tas de trucs
IHM capte keypress et envoie un event system (autoreset) au thread secondaire qui est en WaitForSingleObject sur l'event
Thread secondaire capte l'event, se débloque et passe par un BeginInvoke sur la textbox pour changer le texte de la textbox.

Le problème est que parfois, dans un cas que je ne comprend pas, l'application se bloque sur l'instruction de modification du texte. Ca se bloque dans les cas ou la nouvelle taille de texte est inférieure ou égale a celle actuelle (mais pas tout le tps).
En bref, les instructions suivantes me font partir en deadlock :
textbox.Text += string.Empty;
textbox.Clear();
textbox.Text = string.Empty;
textbox.Text = "test"; //avec textbox.Text.Length > 4

A priori ca ne me le fais que dans ces cas la (et principalement dans le cas de clear et de += string.Empty -cas que je me suis empressé d'éviter), dans des circonstances que je n'arrive pas a déterminer. A priori, le deadlock ne se produit que si je "brutalise" l'appli (si je maintiens une touche appuyée et que ca déclenche le clear pendant ce temps).

J'ai beau regarder l'état de l'appli, ce que j'observe :
Le thread principal est bloqué sur l'instruction textbox.Clear(). Le thread secondaire est (selon les chemins de code), soit bloqué en attente de invoke (le thread principal étant déjà occupé puisque bloqué) soit en WaitForSingleObject. Je n'ai pas l'impression d'être bloqué a cause d'un lock malencontreux ou ce genre de choses...
Serait-ce un bug du framework? Un truc bête et méchant que je loupe? Ca fait déjà un bout de temps que je cherche, mais j'arrive décidement pas à comprendre ce qu'il se passe....
Afficher la suite 

Votre réponse

2 réponses

Meilleure réponse
leprov 1163 Messages postés vendredi 23 juillet 2004Date d'inscription 21 octobre 2010 Dernière intervention - 6 févr. 2008 à 08:19
3
Merci
On dirait que j'ai résolu ce problème. En fait, j'avais au départ créé mon projet en tant que projet console, puis j'ai modifié a la main pour en faire un projet windows forms (i.e. j'ai refait le main).
Le problème est que j'ai laissé le main qualifié par l'attribut MTAThread (pas franchement compatible avec une appli avec IHM a la base). Bref, il a fallu que je rétablisse STAThread (plus logique).
Cependant, par curiosité et si qqun a la réponse, j'aimerais savoir ce qui fait que la CLR a besoin de m'initialiser COM...Les RichTextBox peut-être?

Merci leprov 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 97 internautes ce mois-ci

Commenter la réponse de leprov
cs_coq 6366 Messages postés samedi 1 juin 2002Date d'inscription 2 août 2014 Dernière intervention - 10 févr. 2008 à 15:36
0
Merci
Salut,

Disons qu'au lieu de travailler avec la CLR, tu as failli travailler avec "COM 2.0", si le groupe de départ n'avait pas été scindé en 2 : COM+ et CLR.
Sinon de ce que je sais le CLR, sous Windows, est implementé sous forme d'un serveur COM.

/*
coq
MVP Visual C#
CoqBlog
*/
Commenter la réponse de cs_coq

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.