je désire simuler le click sur un bouton par programme,
mon bouton se nomme bp_precedent ( par exemple).
je fait bp_precedent.PerformClick();
mai cela ne marche pas !
une idée ?
je désire simuler le click sur un bouton par programme,
mon bouton se nomme bp_precedent ( par exemple).
je fait bp_precedent.PerformClick();
mai cela ne marche pas !
une idée ?
je désire simuler le click sur un bouton par programme,
mon bouton se nomme bp_precedent ( par exemple).
je fait bp_precedent.PerformClick();
mai cela ne marche pas !
une idée ?
Didier wrote:
> je désire simuler le click sur un bouton par programme,
>
> mon bouton se nomme bp_precedent ( par exemple).
>
> je fait bp_precedent.PerformClick();
>
> mai cela ne marche pas !
> une idée ?
Bonjour,
Qu'est-ce qui ne marche pas? L'événement n'est pas déclenché? Si vous
mettez un breakpoint dans l'event handler correspondant, le programme
s'arrête-t-il dessus? A priori cette méthode ne pose pas de problème
connu.
[DESCENTE EN FLAMME DE PERFORMCLICK ON]
J'en profite pour faire une remarque, si vous le permettez. Je suis
personnellement *résolument opposé* à l'utilisation de cette méthode. Si
à un endroit de votre programme, vous devez déclencher le même
traitement que celui qui est déclenché quand un bouton est cliqué, vous
devez:
1. Définir ce traitement dans une méthode séparée (MonTraitement)
2. Appeler MonTraitement dans l'event handler du click sur le bouton.
3. Appeler MonTraitement partout ailleurs dans votre code quand vous en
avez besoin.
Pourquoi? Parce qu'en utilisant PerformClick, vous créez ce qu'on
appelle un couplage fort entre votre interface et vos traitements. La
conséquence directe est que tout changement ultérieur dans votre
interface va immédiatement provoquer des changements inutiles dans vos
traitements. Imaginez que vous supprimiez ce bouton pour une raison
quelconque. Vous devez découpler au maximum la partie présentation
(interaction avec l'utilisateur) de la partie traitements proprement
dite. Il est bien dommage que le framework .Net ne propose pas, comme
dans les MFC par exemple, un moyen structurel et natif de se conformer à
cette règle essentielle. Si je devais faire une critique de .Net, c'est
probablement le point que je mettrais en évidence.
[DESCENTE EN FLAMME DE PERFORMCLICK OFF]
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Didier wrote:
> je désire simuler le click sur un bouton par programme,
>
> mon bouton se nomme bp_precedent ( par exemple).
>
> je fait bp_precedent.PerformClick();
>
> mai cela ne marche pas !
> une idée ?
Bonjour,
Qu'est-ce qui ne marche pas? L'événement n'est pas déclenché? Si vous
mettez un breakpoint dans l'event handler correspondant, le programme
s'arrête-t-il dessus? A priori cette méthode ne pose pas de problème
connu.
[DESCENTE EN FLAMME DE PERFORMCLICK ON]
J'en profite pour faire une remarque, si vous le permettez. Je suis
personnellement *résolument opposé* à l'utilisation de cette méthode. Si
à un endroit de votre programme, vous devez déclencher le même
traitement que celui qui est déclenché quand un bouton est cliqué, vous
devez:
1. Définir ce traitement dans une méthode séparée (MonTraitement)
2. Appeler MonTraitement dans l'event handler du click sur le bouton.
3. Appeler MonTraitement partout ailleurs dans votre code quand vous en
avez besoin.
Pourquoi? Parce qu'en utilisant PerformClick, vous créez ce qu'on
appelle un couplage fort entre votre interface et vos traitements. La
conséquence directe est que tout changement ultérieur dans votre
interface va immédiatement provoquer des changements inutiles dans vos
traitements. Imaginez que vous supprimiez ce bouton pour une raison
quelconque. Vous devez découpler au maximum la partie présentation
(interaction avec l'utilisateur) de la partie traitements proprement
dite. Il est bien dommage que le framework .Net ne propose pas, comme
dans les MFC par exemple, un moyen structurel et natif de se conformer à
cette règle essentielle. Si je devais faire une critique de .Net, c'est
probablement le point que je mettrais en évidence.
[DESCENTE EN FLAMME DE PERFORMCLICK OFF]
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Didier wrote:
> je désire simuler le click sur un bouton par programme,
>
> mon bouton se nomme bp_precedent ( par exemple).
>
> je fait bp_precedent.PerformClick();
>
> mai cela ne marche pas !
> une idée ?
Bonjour,
Qu'est-ce qui ne marche pas? L'événement n'est pas déclenché? Si vous
mettez un breakpoint dans l'event handler correspondant, le programme
s'arrête-t-il dessus? A priori cette méthode ne pose pas de problème
connu.
[DESCENTE EN FLAMME DE PERFORMCLICK ON]
J'en profite pour faire une remarque, si vous le permettez. Je suis
personnellement *résolument opposé* à l'utilisation de cette méthode. Si
à un endroit de votre programme, vous devez déclencher le même
traitement que celui qui est déclenché quand un bouton est cliqué, vous
devez:
1. Définir ce traitement dans une méthode séparée (MonTraitement)
2. Appeler MonTraitement dans l'event handler du click sur le bouton.
3. Appeler MonTraitement partout ailleurs dans votre code quand vous en
avez besoin.
Pourquoi? Parce qu'en utilisant PerformClick, vous créez ce qu'on
appelle un couplage fort entre votre interface et vos traitements. La
conséquence directe est que tout changement ultérieur dans votre
interface va immédiatement provoquer des changements inutiles dans vos
traitements. Imaginez que vous supprimiez ce bouton pour une raison
quelconque. Vous devez découpler au maximum la partie présentation
(interaction avec l'utilisateur) de la partie traitements proprement
dite. Il est bien dommage que le framework .Net ne propose pas, comme
dans les MFC par exemple, un moyen structurel et natif de se conformer à
cette règle essentielle. Si je devais faire une critique de .Net, c'est
probablement le point que je mettrais en évidence.
[DESCENTE EN FLAMME DE PERFORMCLICK OFF]
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Oui chef !
Oui chef !
Oui chef !
bonjour,
je désire simuler le click sur un bouton par programme,
mon bouton se nomme bp_precedent ( par exemple).
je fait bp_precedent.PerformClick();
mai cela ne marche pas !
une idée ?
merci
vincent
bonjour,
je désire simuler le click sur un bouton par programme,
mon bouton se nomme bp_precedent ( par exemple).
je fait bp_precedent.PerformClick();
mai cela ne marche pas !
une idée ?
merci
vincent
bonjour,
je désire simuler le click sur un bouton par programme,
mon bouton se nomme bp_precedent ( par exemple).
je fait bp_precedent.PerformClick();
mai cela ne marche pas !
une idée ?
merci
vincent
et pourquoi ne pas appeller directement l'evenement
"bp_precedent_Click(object sender, System.EventArgs e)" par (par
exemple) bp_precedent_Click (null, null);
(Je parle en Winforms, comme tu n'as pas précisé...)
et pourquoi ne pas appeller directement l'evenement
"bp_precedent_Click(object sender, System.EventArgs e)" par (par
exemple) bp_precedent_Click (null, null);
(Je parle en Winforms, comme tu n'as pas précisé...)
et pourquoi ne pas appeller directement l'evenement
"bp_precedent_Click(object sender, System.EventArgs e)" par (par
exemple) bp_precedent_Click (null, null);
(Je parle en Winforms, comme tu n'as pas précisé...)
Bonjour,
Tamahome wrote:
> et pourquoi ne pas appeller directement l'evenement
> "bp_precedent_Click(object sender, System.EventArgs e)" par (par
> exemple) bp_precedent_Click (null, null);
> (Je parle en Winforms, comme tu n'as pas précisé...)
Pour les mêmes raisons que celles que j'ai précisées au-dessus. Si le
bouton disparaît un jour de l'interface, cet appel sera invalide.
Bonjour,
Tamahome wrote:
> et pourquoi ne pas appeller directement l'evenement
> "bp_precedent_Click(object sender, System.EventArgs e)" par (par
> exemple) bp_precedent_Click (null, null);
> (Je parle en Winforms, comme tu n'as pas précisé...)
Pour les mêmes raisons que celles que j'ai précisées au-dessus. Si le
bouton disparaît un jour de l'interface, cet appel sera invalide.
Bonjour,
Tamahome wrote:
> et pourquoi ne pas appeller directement l'evenement
> "bp_precedent_Click(object sender, System.EventArgs e)" par (par
> exemple) bp_precedent_Click (null, null);
> (Je parle en Winforms, comme tu n'as pas précisé...)
Pour les mêmes raisons que celles que j'ai précisées au-dessus. Si le
bouton disparaît un jour de l'interface, cet appel sera invalide.
Ouais,... enfin si le bouton disparaît il semble logique que le
traitement qui était lié à ce bouton va disparaître aussi donc si ce
traitement était appelé il a toutes les chances de disparaître
aussi...
Personnellement je préfère encore le couplage qui va me
donner une erreur de compilation et éviter de laisser du code mort
plutôt que la solution que vous préconisez.
Ouais,... enfin si le bouton disparaît il semble logique que le
traitement qui était lié à ce bouton va disparaître aussi donc si ce
traitement était appelé il a toutes les chances de disparaître
aussi...
Personnellement je préfère encore le couplage qui va me
donner une erreur de compilation et éviter de laisser du code mort
plutôt que la solution que vous préconisez.
Ouais,... enfin si le bouton disparaît il semble logique que le
traitement qui était lié à ce bouton va disparaître aussi donc si ce
traitement était appelé il a toutes les chances de disparaître
aussi...
Personnellement je préfère encore le couplage qui va me
donner une erreur de compilation et éviter de laisser du code mort
plutôt que la solution que vous préconisez.
Lio wrote:
> Ouais,... enfin si le bouton disparaît il semble logique que le
> traitement qui était lié à ce bouton va disparaître aussi donc si ce
> traitement était appelé il a toutes les chances de disparaître
> aussi...
Absolument pas d'accord. Ce n'est pas du tout logique. Si vous
considérez que l'interface utilisateur est directement et
systématiquement couplée aux traitements que l'application met en
oeuvre, vous êtes dans l'erreur, sauf votre respect.
Le fait de supprimer le bouton ne veut pas nécessairement dire que le
traitement correspondant ne sera plus déclenché dans l'application.
Peut-être qu'il sera activé par un autre élément d'interface ou
automatiquement?
> Personnellement je préfère encore le couplage qui va me
> donner une erreur de compilation et éviter de laisser du code mort
> plutôt que la solution que vous préconisez.
C'est une manière de voir les choses. Chacun voit midi à sa porte. En ce
qui me concerne, s'il y avait dans une équipe dont j'aurais la
responsabilité un développeur qui agissait sciemment de la sorte, je
crois qu'il aurait des soucis et qu'il serait candidat à une formation
sur la conception de logiciels. Votre approche conduit nécessairement à
un design problématique et va rendre le travail de maintenance plus
difficile.
Que dîtes vous de la situation où le même traitement est déclenché via
plusieurs éléments d'interface différents, ce qui est le cas dans la
quasi totalité des applications Windows? Si le traitement est déclenché
disons par un bouton, un élément de menu et un bouton d'un toolbar, que
faites vous? Sur la sélection du menu, vous déclenchez un PerformClick
du bouton? Idem pour le bouton de la toolbar? Mais si vous supprimez le
bouton et ne conservez que l'élément de menu et le bouton de la toolbar,
vous basculez sur le PerformClick du menu? En faisant un couper-coller
du code du gestionnaire d'événement du bouton supprimé? Ça ne tient pas
la route.
Regardez les MFC. Regardez Delphi (et la notion d'Action). Regardez
d'autres outils de développement. Tous isolent le plus possible le code
de traitement du design de l'interface. Il est très dommage que le
framework .Net ne propose pas d'entrée de jeu un mécanisme similaire.
Conservez une copie de ce thread. Je suis persuadé qu'un jour, vous le
relirez après avoir rencontré des difficultés majeures liées à la façon
dont vous abordez ce problème. Mon travail de formateur est de faire
prendre conscience aux développeurs qu'un peu de discipline peut éviter
de grosses catastrophes. Sans vouloir jouer les donneurs de leçons,
j'espère au moins avoir semé le doute dans votre esprit :-) .
Lio wrote:
> Ouais,... enfin si le bouton disparaît il semble logique que le
> traitement qui était lié à ce bouton va disparaître aussi donc si ce
> traitement était appelé il a toutes les chances de disparaître
> aussi...
Absolument pas d'accord. Ce n'est pas du tout logique. Si vous
considérez que l'interface utilisateur est directement et
systématiquement couplée aux traitements que l'application met en
oeuvre, vous êtes dans l'erreur, sauf votre respect.
Le fait de supprimer le bouton ne veut pas nécessairement dire que le
traitement correspondant ne sera plus déclenché dans l'application.
Peut-être qu'il sera activé par un autre élément d'interface ou
automatiquement?
> Personnellement je préfère encore le couplage qui va me
> donner une erreur de compilation et éviter de laisser du code mort
> plutôt que la solution que vous préconisez.
C'est une manière de voir les choses. Chacun voit midi à sa porte. En ce
qui me concerne, s'il y avait dans une équipe dont j'aurais la
responsabilité un développeur qui agissait sciemment de la sorte, je
crois qu'il aurait des soucis et qu'il serait candidat à une formation
sur la conception de logiciels. Votre approche conduit nécessairement à
un design problématique et va rendre le travail de maintenance plus
difficile.
Que dîtes vous de la situation où le même traitement est déclenché via
plusieurs éléments d'interface différents, ce qui est le cas dans la
quasi totalité des applications Windows? Si le traitement est déclenché
disons par un bouton, un élément de menu et un bouton d'un toolbar, que
faites vous? Sur la sélection du menu, vous déclenchez un PerformClick
du bouton? Idem pour le bouton de la toolbar? Mais si vous supprimez le
bouton et ne conservez que l'élément de menu et le bouton de la toolbar,
vous basculez sur le PerformClick du menu? En faisant un couper-coller
du code du gestionnaire d'événement du bouton supprimé? Ça ne tient pas
la route.
Regardez les MFC. Regardez Delphi (et la notion d'Action). Regardez
d'autres outils de développement. Tous isolent le plus possible le code
de traitement du design de l'interface. Il est très dommage que le
framework .Net ne propose pas d'entrée de jeu un mécanisme similaire.
Conservez une copie de ce thread. Je suis persuadé qu'un jour, vous le
relirez après avoir rencontré des difficultés majeures liées à la façon
dont vous abordez ce problème. Mon travail de formateur est de faire
prendre conscience aux développeurs qu'un peu de discipline peut éviter
de grosses catastrophes. Sans vouloir jouer les donneurs de leçons,
j'espère au moins avoir semé le doute dans votre esprit :-) .
Lio wrote:
> Ouais,... enfin si le bouton disparaît il semble logique que le
> traitement qui était lié à ce bouton va disparaître aussi donc si ce
> traitement était appelé il a toutes les chances de disparaître
> aussi...
Absolument pas d'accord. Ce n'est pas du tout logique. Si vous
considérez que l'interface utilisateur est directement et
systématiquement couplée aux traitements que l'application met en
oeuvre, vous êtes dans l'erreur, sauf votre respect.
Le fait de supprimer le bouton ne veut pas nécessairement dire que le
traitement correspondant ne sera plus déclenché dans l'application.
Peut-être qu'il sera activé par un autre élément d'interface ou
automatiquement?
> Personnellement je préfère encore le couplage qui va me
> donner une erreur de compilation et éviter de laisser du code mort
> plutôt que la solution que vous préconisez.
C'est une manière de voir les choses. Chacun voit midi à sa porte. En ce
qui me concerne, s'il y avait dans une équipe dont j'aurais la
responsabilité un développeur qui agissait sciemment de la sorte, je
crois qu'il aurait des soucis et qu'il serait candidat à une formation
sur la conception de logiciels. Votre approche conduit nécessairement à
un design problématique et va rendre le travail de maintenance plus
difficile.
Que dîtes vous de la situation où le même traitement est déclenché via
plusieurs éléments d'interface différents, ce qui est le cas dans la
quasi totalité des applications Windows? Si le traitement est déclenché
disons par un bouton, un élément de menu et un bouton d'un toolbar, que
faites vous? Sur la sélection du menu, vous déclenchez un PerformClick
du bouton? Idem pour le bouton de la toolbar? Mais si vous supprimez le
bouton et ne conservez que l'élément de menu et le bouton de la toolbar,
vous basculez sur le PerformClick du menu? En faisant un couper-coller
du code du gestionnaire d'événement du bouton supprimé? Ça ne tient pas
la route.
Regardez les MFC. Regardez Delphi (et la notion d'Action). Regardez
d'autres outils de développement. Tous isolent le plus possible le code
de traitement du design de l'interface. Il est très dommage que le
framework .Net ne propose pas d'entrée de jeu un mécanisme similaire.
Conservez une copie de ce thread. Je suis persuadé qu'un jour, vous le
relirez après avoir rencontré des difficultés majeures liées à la façon
dont vous abordez ce problème. Mon travail de formateur est de faire
prendre conscience aux développeurs qu'un peu de discipline peut éviter
de grosses catastrophes. Sans vouloir jouer les donneurs de leçons,
j'espère au moins avoir semé le doute dans votre esprit :-) .
Je crois que l'on ne se comprend pas
Ouais,... enfin si le bouton disparaît il semble logique que le
traitement qui était lié à ce bouton va disparaître aussi donc si ce
traitement était appelé il a toutes les chances de disparaître
aussi...
Je crois que l'on ne se comprend pas
Ouais,... enfin si le bouton disparaît il semble logique que le
traitement qui était lié à ce bouton va disparaître aussi donc si ce
traitement était appelé il a toutes les chances de disparaître
aussi...
Je crois que l'on ne se comprend pas
Ouais,... enfin si le bouton disparaît il semble logique que le
traitement qui était lié à ce bouton va disparaître aussi donc si ce
traitement était appelé il a toutes les chances de disparaître
aussi...
