Suspendre les events d'un UserControl

Bonjour tout le monde,

j'ai créé un composant graphique (classe héritant du UserControl) et pour laquelle j'ai défini (à cause des besoin de l'application) plusieurs event (KeyPress, ProcessCmdKey, MouseUp, MouseDown, MouseMove, ...)

actuellement, j'essaye de suspendre les event KeyPress et ProcessCmdKey pour les empêcher d'exécuter leurs traitements pendant l'exécution d'un autre event : MonseClick,

seulement je ne sais pas comment faire, puisque la fameuse méthode qui consiste à ajouter ou soustraire l'event à un control ne marche pas !!
et je pense que c'est évident puisqu'elle doit être appliquée sur une instance et non au milieu de la classe du contrôle graphique.

j'espère que j'ai été assez clair,
Merci d'avance
bien cordialement

pour avoir été confronté au problème, la meilleure solution (et surtout la plus simple) consiste à définir une propriété sur ton usercontrol pour indiquer si un traitement doit se faire ou non. Et dans le code des évènements, tu testes la valeur de cette propriété pour savoir ce qu'il faut faire.

Citation:

---

Envoyé par Papy214

pour avoir été confronté au problème, la meilleure solution (et surtout la plus simple) consiste à définir une propriété sur ton usercontrol pour indiquer si un traitement doit se faire ou non. Et dans le code des évènements, tu testes la valeur de cette propriété pour savoir ce qu'il faut faire.

---

salut,

merci pour ta réponse,
je voulais éviter cette solution, j'aurai aimer que cela se fasse de manière plus esthétique :mouarf:

mais s'il n'y a pas d'autre solution, j'ai pas le choix :calim2:

Merci beaucoup
Bien cordialement

ah mais je n'ai pas dis que c'est la seule solution, juste que c'est le plus simple.

J'ai eu le problème récemment. En fait, ce que tu envisageais au départ est réalisable mais difficile si tu as des procédures imbriquées. Par exemple, dans mon code je me suis retrouvé avec un code d'évènement exécuté 2 fois, et je n'ai jamais pu déboguer ça. Chaque procédure désactivait un évènement en faisant un -= d'abord puis un += pour refaire le lien avec l'évènement. Mais parfois tout était imbriqué (mal conçu, d'accord :-( ) et du coup, je devais quelque part en ajouter un de trop.

J'ai résolu ce problème avec la technique (pas propre, ok ;-) ) cité plus haut.

cependant la logique voudrait qu'un composant emette les evenements, et que ce soit le consommateur qui en dispose à sa guise :)

Celà dit, il y a quelques classes dans le Framework .Net (comme par exemple le FileWatcher) qui ont une propriété RaiseEvent utilisé pour lever ou pas certains evenements :)

Perso, je pense que si tu veux que ton composant soit réutilisable par d'autres équipes que la tienne ou d'autre personne que toi, il serait plus "propre" si cela est envisageable et possible, de faire que cette logique d'abonnement soit au niveau de l'utilisateur et non du composant en lui même :)

overrides les void qui déclenchent les évènements (OnQuelqueChose)
et si tu n'est pas en train de faire ton traitement, tu appelle base.OnQuelquechose (si tu ne l'appelles pas, l'évènement ne sera pas déclenché)

Citation:

---

Envoyé par Pol63

overrides les void qui déclenchent les évènements (OnQuelqueChose)
et si tu n'est pas en train de faire ton traitement, tu appelle base.OnQuelquechose (si tu ne l'appelles pas, l'évènement ne sera pas déclenché)

---

bonjour,

Merci à vous tous pour vos réponses,
@Pol63 : ce que j'essaye de faire exactement, c'est de suspendre l'utilisation de l'event OnKeyPress pendant l'appel du OnMouseDown, et de le rétablir à la fin de l'appel de l'event OnMouseUp

Merci d'avance
Bien cordialement

Votre méthode est bien trop fragile face à la réentrance et le multithreading.
Une méthode simple et sûr, qui vient du monde JAVA via l'implémentation des méthodes synchronisées et de verrouillé l’objet courant.
Donc au début de chaque méthode de traitement des évènements :

Code:

---

1 2 3 4

lock(this) { ... }

---

Citation:

---

Envoyé par bacelar

Votre méthode est bien trop fragile face à la réentrance et le multithreading.
Une méthode simple et sûr, qui vient du monde JAVA via l'implémentation des méthodes synchronisées et de verrouillé l’objet courant.
Donc au début de chaque méthode de traitement des évènements :

Code:

---

1 2 3 4

lock(this) { ... }

---

---

Tu pourrais donner un exemple concret stp ?

je vois pas ce que lock vient faire dans cette discussion
de plus il me semble lock n'interdit pas la réantrance du même thread
et puis chose curieuse sur lock, dans msdn ils disent de ne pas faire lock sur this et dans le framework c'est ce que microsoft fait pourtant en général ...

@papy
lock permet de sécuriser du multithreading
le multithreading est quelque chose de simple à comprendre à première vue mais finalement assez complexe aux vues des problèmes que ca peut causer
par exemple si un thread fait un for each sur une collection et qu'un autre thread fait .add sur cette collection, celui qui faisait for each plante
ou encore si 2 thread lisent une propriété pour y ranger +1, il y a des chances pour que ca ne fasse que +1 au lieu de +2 car ils ont auront lu la meme valeur en meme temps
donc il y a des outils pour éviter les soucis, comme lock et les readerwriterlock, les incrément atomiques etc...
lock ca permet qu'une méthode ne soit utilisée par un seul thread à la fois
le 1er thread qui passe sur le lock acquiert le verrou et passe dans le code
ceux qui arrivent derrière reste en attente sur la ligne lock en attendant que le thread qui est dedans sorte, et donc ils passent un par un
le readerwriterlock permet lui de différencier 2 niveaux d'accès, read et write, dans certains cas il est recommandé car il évite de perdre trop de temps

Citation:

---

de plus il me semble lock n'interdit pas la réantrance du même thread

---

Justement, cela permet de correctement gérer les problèmes du style :
Je passe dans un événement donc je fais -= sur mon delegate toto.
En cour de traitement j'appel une méthode qui faut aussi -= sur mon delegate toto.
Ma méthode interne fait += de mon delegate toto.
Ma méthode externe fait += de mon delegate toto.

Résultat : 2 fois le delegate toto sur le même évènement. Cool:aie:

Le fait de faire un lock(this) dans tout les évènements à sérialiser empêche plusieurs threads d'entrer dans l'objet.
Faire des lock(this) peut entraîner des deadlocks si on fait n'importe quoi et justement qu'en on veux avoir la possibilité de faire plusieurs choses en même temps sur un objet. C'est justement le cas que l'on veut éviter.

L'utilisation de se lock simplifie la consultation des propriétés en milieu multithread car la méthode préconisé est extrêmement fragile vis-à-vis de ce problème.

Le lock(this) permet d'implémenter les méthodes synchronised de JAVA.