textbox et deadlockRésolu

Question

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....

leprov · Accepted Answer

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?

cs_coq · Answer

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
*/

Textbox et deadlock

2 réponses

Votre réponse

Discussions similaires