Discussion :

[viniboy]

Bonjour à tous,

Je me pose une question, j'aimerais avoir les retours de personnes plus habituées que moi :

Si l'on doit simplifier, un événement, c'est tout simplement une méthode qui lance une autre méthode (la méthode événementielle) en fonction de la survenue de tel ou tel cas de figure pendant l'exécution de la méthode principale, en envoyant à la méthode lancée des paramètres standards que sont le lanceur de la méthode ( sender ) et la description de l'événement ( e )

Il y a bien sûr un mécanisme plus évolué (délégué, abonnements des méthodes...) mais est-ce que cette analyse vous parait juste ?

D'ailleurs pour aller plus loin, pourrait on selon vous remplacer toute la gestion événementielle par des appels à des méthodes faites pour réagir en fonction de différents cas de figure ou y a t'il quelque chose de plus dans la gestion d'événement dotnet ?

Bonne journée et merci pour vos retours d'éxpérience,
Vincent

[dev01]

Bonjour à tous,

Salut.

Si l'on doit simplifier, un événement, c'est tout simplement une méthode qui lance une autre méthode (la méthode événementielle) en fonction de la survenue de tel ou tel cas de figure pendant l'exécution de la méthode principale, en envoyant à la méthode lancée des paramètres standards que sont le lanceur de la méthode ( sender ) et la description de l'événement ( e )

Euhhhh .... on va pas trop simplifier et surtout on va reprendre.
Un évènement n'est pas une méthode. un évènement est un élément du langage qui est appelé par une méthode afin de signaler que quelque chose se passe ou s'est passé. La signature des évènements est "standardisé" mais rien n'empêche d'écrire des évènements qui, par exemple, ne prennent aucun paramètres.

Il y a bien sûr un mécanisme plus évolué (délégué, abonnements des méthodes...) mais est-ce que cette analyse vous parait juste ?

Encore une fois ... non . Les délégués et ce que tu appelles les "abonnements" sont partie intégrantes des évènements. Sans eux la notion d'évènement n'existerait pas.

D'ailleurs pour aller plus loin, pourrait on selon vous remplacer toute la gestion événementielle par des appels à des méthodes faites pour réagir en fonction de différents cas de figure ou y a t'il quelque chose de plus dans la gestion d'événement dotnet ?

Non on ne pourrait. La plus grosse différence c'est que les évènements sont asynchrone. La deuxième différences vient du fait qu'un évènement peut avoir plusieurs "écouteurs".

[viniboy]

Et bien merci beaucoup, c'est exactement les précisons dont j'avais besoin. En plus je ne savais pas qu'un événement était crée sur un thread séparé. Je pensais que par défaut ils étaient synchrones en fait. Que tous simplement, le temps de leur exécution ils bloquaient l'exécution de la méthode l'ayant lancé, pour ensuite rendre la main une fois la réaction à l'événement effectuée.

Bonne après midi,
Vincent.

[Guulh]

Non on ne pourrait. La plus grosse différence c'est que les évènements sont asynchrone.

Gni ? quand n méthodes sont abonnées à un event, elles sont exécutées les unes après les autres au moment même où l'événement est levé. C'est tout ce qu'il y a de plus synchrone.