Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Visual Basic comment tester 3 OptionButton

comment tester 3 OptionButton

25 réponses
Avatar
dav
j'ai 3 OptionButton sur ma feuille et je voudrais savoir lequel est
coché.....

j'ai envisagé :

dim i as integer
for i = 0 to 2
select case Option1(i).Value
case true

case false
end select
next

qu'en pensez vous ? y'a mieux ?
merci,
dav
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
CoolCubix
Re,

Oui, excusez moi, en plus je connaissais sans "= true" ! J'ai "zappé", comme
on dit ;-)...

Je tiens aussi à préciser que lors d'une mise à niveau à VB.NET les
propriétés par défaut sont inconnues ! Il faut donc encore et encore
modifier du code... Vraiment plus rapide à corriger directement dans VB6 !

(Citation des binaires (10...) écrite en anglais... Just for style ! :-P)

On n'entend pas beaucoup l'expéditeur du message... dav ou te caches tu,
pour tant de gens qui passent (au moins) 5 minutes à martyriser leur
innocent clavier pour répondre à ton message d'aide, ton signal de détresse,
ta main qui dépasse de la surface de l'eau...('faudra bientôt que je prenne
ma nuit annuelle.)

Vive Vichoualle Bachique et bonne prog !
--
C
C U
O B
O !
L X
"Jean-Marc" a écrit dans le message de
news:415f09a4$0$11687$
"Patrice Henrio" a écrit dans le message de
news:%


Hello,

> Pourquoi encore et toujours IF <BOOLEEN>=TRUE THEN
> alors qu'il est si simple (et plus correct d'écrire) d'écrire
> IF <BOOLEEN> THEN

ce n'est ni "plus" ni "moins" correct. Ce n'est pas non plus
"plus" ou "moins" simple. C'est une habitude, c'est tout.

On notera au passage que le code généré est exactement le
même, qu'on mette le " = TRUE " ou pas. Le compilateur
est un grand garçon, qui sait se débrouiller tout seul.


> De plus il me semble que la valeur par défaut du optionbutton est value
donc
> on doity pouvoir tester directement if optionbutton(i) then

Ca par contre c'est un **mauvais** conseil.

1/ Programmer, ce n'est pas seulement saisir du code qui
fonctionne: c'est aussi écrire du code lisible
par un tiers. Utiliser la propriété par défaut d'un
composant nuit gravement à la lisibilité, en plus d'être
une source non négligeable d'erreurs. Ces erreurs seront
en plus difficiles à détecter.

2/ Ca ne change rien à la vitesse. J'ajouterais pour faire
bonne mesure que si on en est réduit à faire ce genre de
bidouilles malsaines et douteuses pour espérer grapiller
d'illusoires millisecondes, alors on doit revoir en
profondeur son implémentation. Le performances ne se
gagnent JAMAIS en jouant avec la syntaxe du langage.

L'utilisation d'artifices n'est jamais une bonne idée:
on sacrifie la lisibilité à la flemmardise du clavier :-(

--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."




Avatar
Zoury
Salut Dav! (et tous le autres !! ) :O)

et voici une autre façon de faire (je préfère la 2ième ...) :
http://groups.google.com/groups?threadm=uzMOLrv7CHA.1740%40TK2MSFTNGP12.phx.gbl



--
Cordialement
Yanick Lefebvre - MVP pour Visual Basic
Le français se refait une beauté, parlons en :
http://www.orthographe-recommandee.info/
"dav" a écrit dans le message de news:
415c3cb9$0$3681$
j'ai 3 OptionButton sur ma feuille et je voudrais savoir lequel est
coché.....

j'ai envisagé :

dim i as integer
for i = 0 to 2
select case Option1(i).Value
case true

case false
end select
next

qu'en pensez vous ? y'a mieux ?
merci,
dav


Avatar
Patrice Henrio
OK pour la valeur par défaut, d'autant que je n'ai même pas vérifié si c'est
bien le cas. Au moins en précisant toujours la propiété on ne risque pas de
se tromper. sans parler qu'effectivement c'est plus propre.

Par contre je ne suis toujours pas d'accord pour le =TRUE. Je sais que c'est
une habitude de certains, mais que l'on peut essayer d'améliorer. Du tyemps
où j'enseignais la programmation, je retirais toujours des points pour ceux
qui écrivaient ce genre de chose. A vrai dire peu d'élève le faisait car
d'une part ils apprenaient à programmer à partir de la seconde et avaient
dés le début la syntaxe des tests.
De plus pourquoi faire confiance au compilateur. Pour ma part je ne savais
pas que celui-ci ignorait le =TRUE.
Par contre en terme d'alogorithmie je persiste à dire que c'est une
incompréhension de ce qu'est un booleéen.

"Si vrai est vrai alors" est un manque de logique, même si cela marche car
dans ce cas on peut aussi écrire :
SI <BOOLEEN> = (1+1=2) ALORS.

Et ce n'est pas une question de gain de millisecondes mais bien une question
de compréhension de la nature du booléen.


"Jean-Marc" a écrit dans le message de news:
415f09a4$0$11687$
"Patrice Henrio" a écrit dans le message de
news:%


Hello,

Pourquoi encore et toujours IF <BOOLEEN>=TRUE THEN
alors qu'il est si simple (et plus correct d'écrire) d'écrire
IF <BOOLEEN> THEN



ce n'est ni "plus" ni "moins" correct. Ce n'est pas non plus
"plus" ou "moins" simple. C'est une habitude, c'est tout.

On notera au passage que le code généré est exactement le
même, qu'on mette le " = TRUE " ou pas. Le compilateur
est un grand garçon, qui sait se débrouiller tout seul.


De plus il me semble que la valeur par défaut du optionbutton est value


donc
on doity pouvoir tester directement if optionbutton(i) then



Ca par contre c'est un **mauvais** conseil.

1/ Programmer, ce n'est pas seulement saisir du code qui
fonctionne: c'est aussi écrire du code lisible
par un tiers. Utiliser la propriété par défaut d'un
composant nuit gravement à la lisibilité, en plus d'être
une source non négligeable d'erreurs. Ces erreurs seront
en plus difficiles à détecter.

2/ Ca ne change rien à la vitesse. J'ajouterais pour faire
bonne mesure que si on en est réduit à faire ce genre de
bidouilles malsaines et douteuses pour espérer grapiller
d'illusoires millisecondes, alors on doit revoir en
profondeur son implémentation. Le performances ne se
gagnent JAMAIS en jouant avec la syntaxe du langage.

L'utilisation d'artifices n'est jamais une bonne idée:
on sacrifie la lisibilité à la flemmardise du clavier :-(

--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."




Avatar
Jean-Marc
"Patrice Henrio" a écrit dans le message de
news:
<....>
Par contre en terme d'alogorithmie je persiste à dire que c'est une
incompréhension de ce qu'est un booleéen.

"Si vrai est vrai alors" est un manque de logique, même si cela marche car
dans ce cas on peut aussi écrire :
SI <BOOLEEN> = (1+1=2) ALORS.



Je suis d'accord et dans bien des cas, je n'écris pas le "= TRUE",
pour les expressions simples.

Cependant, il faut AMHA considérer le contexte plutôt que le dogme.
Exemple basique, mais parlant:
Si je dois écrire un classique "va-et-vient", dont l'équation
logique est S = A./B + /A.B, je préfère vraimet lire:

if ( (A = True ) and (B = False) ) OR _
( (A = False) and (B = True ) ) Then
...

Que:

If (A And Not B) Or (Not A And B) Then
...

Pour la deuxième forme, si je n'ai pas écrit le programme, je dois
prendre un papier et un crayon pour vérifier. Pour la première, je
"vois" ce que fait le code: L'ajout (inutile j'en conviens) des
"= TRUE", en plus du fait que c'est plus joli car ça rend l'expression
symétrique à l'oeil, donne un éclairage sur l'intention du programmeur.
C'est utilie quand on débuggue un truc qu'on a pas écrit soit même.

Je parle d'expérience. Je dois souvent intervenir sur du code complexe,
dns des programes qui font des dizaines de milliers de lignes. Si je dois
(et hélas c'est souvent le cas) m'interroger toutes les 10 lignes pour
essayer de piger ce que le (..censuré..) de programmeur a bien voulu
faire, ça peut vous transformer une journée paisible en cauchemar :-))

--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
Avatar
Patrice Henrio
OK j'ai bien compris ton problème.
En fait <BOOLEEN>=true te prémunis des programmeurs qui utilisent les
valeurs entières différentes de 0 pour true que l'on trouvait dans certains
basic au début, style
If A mod B then

ou A mod B donne le reste de la division entière de A par B.
J'admets que là aussi cela me faisait râler.

"Jean-Marc" a écrit dans le message de news:
415fc216$0$9019$
"Patrice Henrio" a écrit dans le message de
news:
<....>
Par contre en terme d'alogorithmie je persiste à dire que c'est une
incompréhension de ce qu'est un booleéen.

"Si vrai est vrai alors" est un manque de logique, même si cela marche
car
dans ce cas on peut aussi écrire :
SI <BOOLEEN> = (1+1=2) ALORS.



Je suis d'accord et dans bien des cas, je n'écris pas le "= TRUE",
pour les expressions simples.

Cependant, il faut AMHA considérer le contexte plutôt que le dogme.
Exemple basique, mais parlant:
Si je dois écrire un classique "va-et-vient", dont l'équation
logique est S = A./B + /A.B, je préfère vraimet lire:

if ( (A = True ) and (B = False) ) OR _
( (A = False) and (B = True ) ) Then
...

Que:

If (A And Not B) Or (Not A And B) Then
...

Pour la deuxième forme, si je n'ai pas écrit le programme, je dois
prendre un papier et un crayon pour vérifier. Pour la première, je
"vois" ce que fait le code: L'ajout (inutile j'en conviens) des
"= TRUE", en plus du fait que c'est plus joli car ça rend l'expression
symétrique à l'oeil, donne un éclairage sur l'intention du programmeur.
C'est utilie quand on débuggue un truc qu'on a pas écrit soit même.

Je parle d'expérience. Je dois souvent intervenir sur du code complexe,
dns des programes qui font des dizaines de milliers de lignes. Si je dois
(et hélas c'est souvent le cas) m'interroger toutes les 10 lignes pour
essayer de piger ce que le (..censuré..) de programmeur a bien voulu
faire, ça peut vous transformer une journée paisible en cauchemar :-))

--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."




Avatar
CoolCubix
En apprenant une langue, on commence par traduire dans sa tête en français
pour comprendre, puis avec l'expérience, les mots sont directements reliés
aux idées qu'elles évoquent. En VB c'est beaucoup plus difficile, car ce ne
sont pas des phrases mais des expressions, des fragments d'idées qui se
regroupent en plusieurs lignes. En lisant un code qu'on a pas fait, c'est
plus facile d'avoir une expression la plus proche du langage humain.

Dans l'exemple que je REcite :

<------------------ [1] ------------------>
if ( (A = True ) and (B = False) ) OR _
( (A = False) and (B = True ) ) Then

<------------------ [2] ------------------>
If (A And Not B) Or (Not A And B) Then

La solution 2 est vraiment plus lisible, plus humaine, et non pas "machine"
et très ''binaire".

Perso, c'est mon truc, mon point de vue, après chacun ses méthodes ! Tant
que ça ne ralentit pas le programme...

--
C
C U
O B
O !
L X
"Patrice Henrio" a écrit dans le message de
news:
OK j'ai bien compris ton problème.
En fait <BOOLEEN>=true te prémunis des programmeurs qui utilisent les
valeurs entières différentes de 0 pour true que l'on trouvait dans


certains
basic au début, style
If A mod B then

ou A mod B donne le reste de la division entière de A par B.
J'admets que là aussi cela me faisait râler.

"Jean-Marc" a écrit dans le message de news:
415fc216$0$9019$
> "Patrice Henrio" a écrit dans le message de
> news:
>> <....>
>> Par contre en terme d'alogorithmie je persiste à dire que c'est une
>> incompréhension de ce qu'est un booleéen.
>>
>> "Si vrai est vrai alors" est un manque de logique, même si cela marche
>> car
>> dans ce cas on peut aussi écrire :
>> SI <BOOLEEN> = (1+1=2) ALORS.
>
> Je suis d'accord et dans bien des cas, je n'écris pas le "= TRUE",
> pour les expressions simples.
>
> Cependant, il faut AMHA considérer le contexte plutôt que le dogme.
> Exemple basique, mais parlant:
> Si je dois écrire un classique "va-et-vient", dont l'équation
> logique est S = A./B + /A.B, je préfère vraimet lire:
>
> if ( (A = True ) and (B = False) ) OR _
> ( (A = False) and (B = True ) ) Then
> ...
>
> Que:
>
> If (A And Not B) Or (Not A And B) Then
> ...
>
> Pour la deuxième forme, si je n'ai pas écrit le programme, je dois
> prendre un papier et un crayon pour vérifier. Pour la première, je
> "vois" ce que fait le code: L'ajout (inutile j'en conviens) des
> "= TRUE", en plus du fait que c'est plus joli car ça rend l'expression
> symétrique à l'oeil, donne un éclairage sur l'intention du programmeur.
> C'est utilie quand on débuggue un truc qu'on a pas écrit soit même.
>
> Je parle d'expérience. Je dois souvent intervenir sur du code complexe,
> dns des programes qui font des dizaines de milliers de lignes. Si je


dois
> (et hélas c'est souvent le cas) m'interroger toutes les 10 lignes pour
> essayer de piger ce que le (..censuré..) de programmeur a bien voulu
> faire, ça peut vous transformer une journée paisible en cauchemar :-))
>
> --
> Jean-marc
> "There are only 10 kind of people
> those who understand binary and those who don't."
>
>




Avatar
LE TROLL
Je vois qu'il y a là les somités de ce groupe, ben voui, évidemment
qu'il faut que le langage soit parlant:

Le Hamlet "boolean or not boolean"... lol, on n'y comprend rien...

Ça c'est plus parlant:

If x = true Then z
------------------


"Patrice Henrio" a écrit dans le message de
news:%
Pourquoi encore et toujours IF <BOOLEEN>=TRUE THEN
alors qu'il est si simple (et plus correct d'écrire) d'écrire
IF <BOOLEEN> THEN

De plus il me semble que la valeur par défaut du optionbutton est value


donc
on doity pouvoir tester directement if optionbutton(i) then
Sinon c'est vrai que ton code est préférable car plus rapide
"CoolCubix" a écrit dans le message de news:

> Bonjour,
>
> Ta solution n'est pas mal mais elle continue de tester les autres. Voici
> un
> code plus simple d'accès car c'est une simple procédure à appeler. De


même
> l'emploi d'un Select Case est inutile pour un résultat Boolean.
>
> Code :
>
> Public Function LequelEstCoche()
> Dim i as Integer
> For i = 0 To 2 'Remplacer 2 par le nombre de OptionButton
> If OptionButton.Item(i).Value = True Then 'Remplacer


OptionButton
> par le nom des contrôles
> LequelEstCoche = i
> Exit Function
> End If
> Next
> End Function
>
> Utilisation :
>
> Placer le code dans la Form ou dans un Module.
> La fonction renvoie la propriété Index du OptionButton coché.
> Remplacer 2 par le nombre de OptionButton.
> Remplacer OptionButton par le nom des contrôles
>
>
> ;-D
> --
> C
> C U
> O B
> O !
> L X
>
> "dav" a écrit dans le message de
> news:415c3cb9$0$3681$
>> j'ai 3 OptionButton sur ma feuille et je voudrais savoir lequel est
>> coché.....
>>
>> j'ai envisagé :
>>
>> dim i as integer
>> for i = 0 to 2
>> select case Option1(i).Value
>> case true
>>
>> case false
>> end select
>> next
>>
>> qu'en pensez vous ? y'a mieux ?
>> merci,
>> dav
>
>
>
>
>




Avatar
tetofr
Salut,

Et si, tout en restant dans les expressions logiques, et en retournant
à la question initiale, nous écrivions la fonction LequelEstCoche()
comme ceci :

Public Function LequelEstCoche() as long
LequelEstCoche = - OptionButton.Item(1).Value _
- 2 * OptionButton.Item(2).Value _
- 3 * OptionButton.Item(3).Value
End Function

On peut bien sûr placer le tout dans une boucle pour un nombre différent
d'options, mais comme ça, c'est la version la plus performante...

A++
G.B.


CoolCubix a écrit :

En apprenant une langue, on commence par traduire dans sa tête en français
pour comprendre, puis avec l'expérience, les mots sont directements reliés
aux idées qu'elles évoquent. En VB c'est beaucoup plus difficile, car ce ne
sont pas des phrases mais des expressions, des fragments d'idées qui se
regroupent en plusieurs lignes. En lisant un code qu'on a pas fait, c'est
plus facile d'avoir une expression la plus proche du langage humain.

Dans l'exemple que je REcite :

<------------------ [1] ------------------>
if ( (A = True ) and (B = False) ) OR _
( (A = False) and (B = True ) ) Then

<------------------ [2] ------------------>
If (A And Not B) Or (Not A And B) Then

La solution 2 est vraiment plus lisible, plus humaine, et non pas "machine"
et très ''binaire".

Perso, c'est mon truc, mon point de vue, après chacun ses méthodes ! Tant
que ça ne ralentit pas le programme...



Avatar
Jean-Marc
"tetofr" a écrit dans le message de
news:VAX8d.4091$
Salut,

Et si, tout en restant dans les expressions logiques, et en retournant
à la question initiale, nous écrivions la fonction LequelEstCoche()
comme ceci :

Public Function LequelEstCoche() as long
LequelEstCoche = - OptionButton.Item(1).Value _
- 2 * OptionButton.Item(2).Value _
- 3 * OptionButton.Item(3).Value
End Function

On peut bien sûr placer le tout dans une boucle pour un nombre différent
d'options, mais comme ça, c'est la version la plus performante...



Hello,

NON, on ne doit PAS faire ça.

Tu fais de l'arithmétique sur des Booléens!
Ca ne veut rien dire 3 * True ou 3 * False.
Tu utilises le fait que le True du Basic vaut
-1 pour faire une IGNOBLE tambouille.

A déconseiller absolument.

D'autre part, tu parles de "performance" ? Qui a besoin
de performances pour tester un Bouton Option ??

La seule performance que je vois ici, c'est éventuellement
qu'un "programmeur" (notez bien les guillemets, hein...) qui
ose faire ça gagne le 1er prix de
"Programmation de Goret"! Tu parles d'une performance :-(

Et si on avait besoin de ce genre de perfs, alors ce ne
serait de toute façon pas la bonne méthode (qui serait alors
de renseigner une variable à chaque changement d'état).

--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
Avatar
Patrice Henrio
Entièrement d'accord !!!

"Jean-Marc" a écrit dans le message de news:
416448f0$0$22072$
"tetofr" a écrit dans le message
de
news:VAX8d.4091$
Salut,

Et si, tout en restant dans les expressions logiques, et en retournant
à la question initiale, nous écrivions la fonction LequelEstCoche()
comme ceci :

Public Function LequelEstCoche() as long
LequelEstCoche = - OptionButton.Item(1).Value _
- 2 * OptionButton.Item(2).Value _
- 3 * OptionButton.Item(3).Value
End Function

On peut bien sûr placer le tout dans une boucle pour un nombre différent
d'options, mais comme ça, c'est la version la plus performante...



Hello,

NON, on ne doit PAS faire ça.

Tu fais de l'arithmétique sur des Booléens!
Ca ne veut rien dire 3 * True ou 3 * False.
Tu utilises le fait que le True du Basic vaut
-1 pour faire une IGNOBLE tambouille.

A déconseiller absolument.

D'autre part, tu parles de "performance" ? Qui a besoin
de performances pour tester un Bouton Option ??

La seule performance que je vois ici, c'est éventuellement
qu'un "programmeur" (notez bien les guillemets, hein...) qui
ose faire ça gagne le 1er prix de
"Programmation de Goret"! Tu parles d'une performance :-(

Et si on avait besoin de ce genre de perfs, alors ce ne
serait de toute façon pas la bonne méthode (qui serait alors
de renseigner une variable à chaque changement d'état).

--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."




1 2 3