Déclencher la méthode d'un évènement

Bonjour

Je voudrais déclencher la méthode liée à un évènement "On_click", lors du Load d'une page, Si j'ai un Request["mode"]=="insert". Cette méthode me mets ma page dans la configuration "insertion". Code de ma méthode à déclancher :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

protected void NewButton_Click(object sender, EventArgs e) { Interlo interlo = new Interlo(); interlo.SetIdClient(txtidclient.Text); Session["objet_interlo"] = interlo; InsertButton.Visible = true; UpdateButton.Visible = false; DeleteButton.Visible = false; NewButton.Visible = false; initView(interlo); }

---

Voici le code qui fait le test et déclencherait la méthode :

Code:

---

1 2	if (Request["mode"] == "insert") this.NewButton_Click(NewButton, "");

---

çà mets un message d'erreur :

Code:

---

La méthode surchargée correspondant le mieux à 'interloclient.NewButton_Click(object, System.EventArgs)' possède des arguments non valides

---

Je ne comprends pas très bien comment utiliser ces System.EventArgs.

merci de votre aide

EventArgs est un objet et tu lui passe une chaine de caractère ce qui posait probleme.

Code:

---

this.NewButton_Click(NewButton, EventArgs.Empty);

---

Cela dit, même si la solution de SoBaKa fonctionne dans le cas présent, je te conseillerai plutôt de mettre le code que tu veux appeler dans une méthode séparée, et d'appeler cette méthode depuis ton évènement OnLoad et dans ton test.

Citation:

---

Envoyé par Nikoui

Cela dit, même si la solution de SoBaKa fonctionne dans le cas présent, je te conseillerai plutôt de mettre le code que tu veux appeler dans une méthode séparée, et d'appeler cette méthode depuis ton évènement OnLoad et dans ton test.

---

+1

Appeler directement les handlers d'event, c'est vraiment "bricolo crade".

Citation:

---

Envoyé par Bluedeep

+1

Appeler directement les handlers d'event, c'est vraiment "bricolo crade".

---

+1 je suis bricolo crade :p lol

mais plus sérieusement si il veut coder proprement faut lui expliquer que la méthode qu'il va faire faudra l'utiliser aussi dans l'event button_click... Parce que la réécriture du code c'est encore pire que d'être "bricolo crade" :mouarf:

Merci pour ta réponse rapide, SoBaKa, elle m'a permis d'avancer et résoudre mon problème.
Pour info (avant de mettre "résolu") à quoi sert ce paramètre généralement ? Quelles sont ses utilisations les plus courantes, son intérêt ?
Merci

le EventsArgs en lui même comme il est la ne sert à rien (tu aurais pu mettre null a la place de EventsArgs.Empty) mais il est utile si tu fais tes propres événements (la tu hérites de EventsArgs) pour faire passer certaines valeurs par événements.

En gros c'est ça ^^

Citation:

---

Envoyé par patbeautifulday1

Merci pour ta réponse rapide, SoBaKa, elle m'a permis d'avancer et résoudre mon problème.

---

Pour information, la réponse de SoBaKa (sauf son respect) est une rustine. Celle de Bluedeep est une solution acceptable.

Et avoir deux fois le même code dans le même fichier, c'est pas "bricolo-crade" ?
Moi je préfère cette "rustine", plutôt que d'avoir du code redondant dans 10 fichiers, ou à l'infini...
Ceci dit je ne suis pas un pro du Génie Logiciel, mais enfin appeler une méthode déjà codée, çà me paraît être du bon sens, et c'est plus élégant.
Qu'en pensez-vous ?

Citation:

---

Envoyé par patbeautifulday1

Et avoir deux fois le même code dans le même fichier, c'est pas "bricolo-crade" ?
Moi je préfère cette "rustine", plutôt que d'avoir du code redondant dans 10 fichiers, ou à l'infini...

---

Et pourquoi écrire deux fois le même code ? ca n'a pas de sens ...

Citation:

---

Ceci dit je ne suis pas un pro du Génie Logiciel, mais enfin appeler une méthode déjà codée, çà me paraît être du bon sens, et c'est plus élégant.
Qu'en pensez-vous ?

---

Qu'appeler un event handler directement n'a strictement rien d'élégant.

(pour au dessus, je ne comprends strictement rien à ce que tu dis).

Citation:

---

Envoyé par patbeautifulday1

Et avoir deux fois le même code dans le même fichier, c'est pas "bricolo-crade" ?

---

Je ne lui ai jamais conseiller de dédoubler le code (quelle idée!) mais de mettre le code dans une fonction dédié et de l'appeler dans son évènement et dans son test (2 appels d'une même fonction donc).

Et c'est je pense plus propre qu'appeler une méthode "OnClick" en lui passant un event handler, alors qu'aucun évènement Click ne s'est produit...

Ah oui, excuses-moi, Nikoui je n'avais pas bien lu ton post. C'est effectivement plus propre comme celà.
Merci à tous, le problème est résolu...

Citation:

---

Envoyé par Nikoui

Je ne lui ai jamais conseiller de dédoubler le code (quelle idée!) mais de mettre le code dans une fonction dédié et de l'appeler dans son évènement et dans son test (2 appels d'une même fonction donc).

---

C'est ce que j'ai dit aussi, Je précisais juste qu'il fallait faire une méthode qui serait appellée aussi dans l'événement Click et j'ai vu tellement de code où le code était réalisé 2 fois (voir même 3...) dans un même fichier source qu'il me semblait normal de préciser ^^

Mais j'utilises l'autres techniques de temps à autre car dans l'entreprise où je bosse (ca fait que 3 mois que j'y suis), il code de cette manière (voir même encore pire certaines sources me font mal à la tête)...

Même si appeller le handler est une rustine (et j'en suis conscient), c'est surtout par niveau de facilité qu'on l'utilise dans la boîte... Projet souvent à modifier pour des partenaires commerciaux où un paramètre passé fait que ça agit comme un événement... ce qui est exactement le cas ici...
Ensuite, il y a aussi, je trouve, une facilité au niveau de la lecture du code. Quand on voit Button_Click(null, null), on sait tout de suite que quand on passe tel paramètre agira exactement comme si on cliquait sur tel bouton (dans l'entreprise où je bosse les nom des variables et autres ne sont pas forcément très explicite...)

Maintenant, même si c'est vrai que la solution de BlueDeep est plus propre, appeller MaMethodeQuiFaitCa() ou appeller MonButton_Click(null, null) n'est juste qu'appeller une méthode et rien de plus non? (ou je me trompe? ^^)

Citation:

---

Envoyé par SoBaKa

Mais j'utilises l'autres techniques de temps à autre car dans l'entreprise où je bosse (ca fait que 3 mois que j'y suis), il code de cette manière (voir même encore pire certaines sources me font mal à la tête)...

---

C'est une des plus mauvaises excuses que j'ai jamais entendues... ;)

Citation:

---

Envoyé par SoBaKa

Même si appeller le handler est une rustine (et j'en suis conscient), c'est surtout par niveau de facilité qu'on l'utilise dans la boîte... Projet souvent à modifier pour des partenaires commerciaux où un paramètre passé fait que ça agit comme un événement... ce qui est exactement le cas ici...
Ensuite, il y a aussi, je trouve, une facilité au niveau de la lecture du code. Quand on voit Button_Click(null, null), on sait tout de suite que quand on passe tel paramètre agira exactement comme si on cliquait sur tel bouton (dans l'entreprise où je bosse les nom des variables et autres ne sont pas forcément très explicite...)

---

Tu as une notion toute personnelle de la simplicité et de la facilité. Pour moin la facilité, ce n'est pas de devoir passer des paramètres inutiles à une fonction. Ce n'est pas non de rajouter des gardes fous partout dans le code, simplement parce qu'un feignant a décidé de passer des valeurs farfelues dans un handler...

Citation:

---

Envoyé par SoBaKa

Maintenant, même si c'est vrai que la solution de BlueDeep est plus propre, appeller MaMethodeQuiFaitCa() ou appeller MonButton_Click(null, null) n'est juste qu'appeller une méthode et rien de plus non? (ou je me trompe? ^^)

---

Si pour toi utiliser une handler d'événement comme une méthode en lui passant une pelle de paramètres inutiles n'est pas choquant. Sémantiquement, ça revient à écrire "fais comme si un événement était sorti de nulle part".

Il ne me reste plus qu'à prier de ne jamais tomber dans la même société que toi. ;)

Citation:

---

Envoyé par SaumonAgile

Si pour toi utiliser une handler d'événement comme une méthode en lui passant une pelle de paramètres inutiles n'est pas choquant. Sémantiquement, ça revient à écrire "fais comme si un événement était sorti de nulle part".

---

Sauf erreur de ma part, je ne passe par par l'event handler mais par une méthode qui est enregistrée auprès de l'event handler (ce qui est différent il me semble).
Il est clair qu'il y a 2 paramètres inutiles à passer mais à part cela, il n'y a rien d'autres qui diffère (ou alors je me trompe quelque part ce qui est fort possible :p)

Citation:

---

Envoyé par SaumonAgile

Il ne me reste plus qu'à prier de ne jamais tomber dans la même société que toi. ;)

---

Ca fait que 3 mois que travaille professionnellement dans le domaine sinon j'ai 7 ans d'autodidacte derrière moi et j'avoue que j'ai des mauvaises habitudes qu'il faut changer mais si on vient sur ce forum c'est pour aider/être aider/apprendre il me semble non? :p

Citation:

---

Envoyé par SoBaKa

Il est clair qu'il y a 2 paramètres inutiles à passer mais à part cela, il n'y a rien d'autres qui diffère (ou alors je me trompe quelque part ce qui est fort possible :p)

---

La méthode 'OnClick' comme son nom l'indique est là pour gérer les Clicks. L'appeler alors qu'aucun click n'a eu lieu c'est :
- pas logique du tout (donc mauvais pour la compréhension du code)
- dangereux

Pour le second point je détail un peu:
Si la méthode OnClick prend en parametre un "click event handler arguments" ce n'est pas pour rien. Ces arguments contiennent des informations liées au click. Si la méthode OnClick utilise ces informations pour faire ce qu'elle a à faire, et que tu lui envoie un event handler null (ou vide) alors elle va planter, alors qu'elle n'a aucune raison de planter.

Certe ce n'est pas le cas dans cet exemple (les arguments ne sont pas utilisés) mais appeler une méthode en suposant que ces arguments ne sont pas utilisé et ne seront jamais utilisé est très dangeureux.

Si tu veux faire 2 fois (ou plus) le même traitement, tu isoles ce traitement (et uniquement ce traitement) dans une fonction par exemple. Ensuite tu peux être sur que cette méthode dédiée fait ce que tu veux et que les arguments qu'elle prend lui sont tous utiles.

Est ce que c'est plus clair comme cela?

Citation:

---

Envoyé par SoBaKa

Sauf erreur de ma part, je ne passe par par l'event handler mais par une méthode qui est enregistrée auprès de l'event handler

---

C'est quoi cette bête là : "une méthode qui est enregistrée auprès de l'event handler" ????

Moi, je connais les event et les méthodes qu'on abonne dessus, qui sont les event handlers, mais "une méthode qui est enregistrée auprès de l'event handler" ca ne fait pas vraiment parti de mon catalogue.

Citation:

---

Envoyé par SoBaKa

j'avoue que j'ai des mauvaises habitudes qu'il faut changer mais si on vient sur ce forum c'est pour aider/être aider/apprendre il me semble non? :p

---

Tu as entièrement raison, d'ou la nécessité de se débarrasser de la mauvaise habitude d'appeler directement des handlers d'événement. ;)

Merci nikoui... c'est bien ce qui est dit y a 2/3 messages, les paramètres sont inutiles... mais tu n'appelles jamais une méthode en pensant que les paramètres ne seront pas utilisés... mais tu fais ton test dans la méthode qui vérifie si le paramètre est bon... non? :p

De plus je suis d'accord que la solution de Bluedeep est plus propre mais c'est sur des termes plus technique que je bloques plutôt la... :p

Citation:

---

Envoyé par Bluedeep

C'est quoi cette bête là : "une méthode qui est enregistrée auprès de l'event handler" ????

Moi, je connais les event et les méthodes qu'on abonne dessus, qui sont les event handlers, mais "une méthode qui est enregistrée auprès de l'event handler" ca ne fait pas vraiment parti de mon catalogue.

---

event handler = gestionnaire d'événement... non?

le gestionnaire d'événement contient les méthodes à appliquer quand un événement à lieu... pour ajouter la méthode au gestionnaire d'événement c'est grâce au +=

un exemple vaut mieux qu'un long discours je pense ^^

Code:

---

1 2	int a = 0; a += 1;

---

d'accord avec moi tu rajoutes un entier à 'a' ;)

Code:

---

1 2	Button b; b.Click += new ButtonClickEventHandler(b_OnClick);

---

tu rajoutes quoi la et a quoi? :p

.Click = Event Handler
b_OnClick = Méthode

donc b_OnClick n'est pas un Event Handler mais une Méthode
donc on rajoute à l'Event Handler un nouvel Event Handler qui quand le Click sur le bouton sera déclencé appellera la méthode b_OnClick

Ai-je bon ou alors mon analyse est totalement foireuse? ^^

encore un donc :p, donc si j'appelle b_OnClick je n'appelle pas l'event handler mais une méthode classique :p

(désolé pour tout surtout que ce n'est pas important vu que la solution de bluedeep est quand même plus propre mais me fais chi** au boulot la :p lol)

Click : event
button1_Click : event handler

Comme ça, tout est clarifié.

:D

Citation:

---

Envoyé par SaumonAgile

Click : event
button1_Click : event handler

Comme ça, tout est clarifié.

:D

---

Ca veut pas rentrer dans ma logique comme ça... suis-je mal programmé? :p

j'aurais été d'accord sans problème si :

b.Click = new ButtonClickEventHandler(b_OnClick);

:p

Bon alors, je reprends :
dans la méthode Form_Load par exemple (qui se trouve aussi être un event handler par ailleurs) :

Code:

---

monButton1.Click += monButton1_Click;

---

Plus loin dans le code :

Code:

---

1 2	private void monButton1_Click(object sender, EventArgs e) {}

---

Maintenant la terminologie :
- monButton1_Click est une méthode particulière appelée event handler car associée à un delegate (de la classe Button). Mais oui, cela reste une méthode.
- Click (dans monButton1.Click) est un event.

Voila.

ouh la viens de voir une faute dans ma stupidité ^^

.Click est bien un event auquel on ajoute un event handler qui lui appelle la méthode b_Click ^^

Citation:

---

Envoyé par SoBaKa

ouh la viens de voir une faute dans ma stupidité ^^

.Click est bien un event auquel on ajoute un event handler qui lui appelle la méthode b_Click ^^

---

Tu es têtu comme garçon... b_Click EST un event handler. ButtonClickEventHandler n'est qu'un delegate.