Discussion :

[Pierre Fauconnier]

[...]

Ta technique crée des appels récursifs, donc des appels de pile... De plus, elle relance toute la macro, et donc également ce qui prépare éventuellement le userform. Je préfère de loin la boucle qui, placée au bon endroit, permet de juste réafficher le userform. La macro de lancement ne contient assez rarement que le .show...

De plus, ta boucle 1 to 6 ne boucle pas sur tous les contrôles, puisque tu en as 8 . Ca exclut donc le dernier optionbutton . Je passerai sur l'aberration des noms indexés, ainsi que sur le fait de continuer à boucler sans nécessité lorsqu'un optionbutton coché a été scanné.

Pas de soucis pour différencier les manières de faire, mais faudrait-il encore qu'elles soient correctes par rapport à la demande initiale (et compatibles avec les bonnes pratiques, mais là, j'en demande sûrement trop).

Bref...

[MarcelG]

Croisement avec le post de Pierre. Je tenais à préciser.

Bonjour Patrick,

J'ai testé ton code.
OK.

Néanmoins, la gestion de la variable

optionchoisie

me gêne quelque peu.
Sa valeur est soit booléenne, soit numérique (Byte) d'où une déclaration forcée en Variant.

Et moi, les déclarations en Variant....

[patricktoulon]

re
Pierre et Marcel

une variante avec la boucle sur le groupname ca plaira peut etre un peu plus a pierre

tu remplace simplement le rappel de sub par le ".show"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
Sub testx()
    With UserForm1
        .Show
        If .optionchoisie = False Then
            MsgBox Prompt:="Vous devez choisir une option"
            .Show 'on réaffiche le userform
        Else
            MsgBox "vous avez choisi l'" & .optionchoisie
        End If
    End With
    Unload UserForm1
End Sub

et pour la boucle sur les noms
on boucle sur les éléments du groupname
code userform

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Option Explicit
Public optionchoisie As Variant
Private Sub CommandButton1_Click()
    Dim ctrl As Control
    If Me.AUCUN = True Then
        optionchoisie = False: Me.Hide
    Else
        For Each ctrl In Me.Controls
            If TypeName(ctrl) = "OptionButton" Then
                If ctrl.GroupName = "TEST" And ctrl.Value = True Then
                    optionchoisie = ctrl.Name: Exit For:
                End If
            End If
        Next
    End If
 Me.Hide
End Sub

@marcel la variable perso moi ca ne me dérange pas
les boites de dialog les plus connues ont bien ce procédé non?
rien empêche effectivement soit de remplacer false par le nom "AUCUN " dans cet exemple ou même "0"
mais un do loop d'attente bloquant ca oui je trouve aberrant pour reprendre les termes de Pierre surtout qu'avec le UserForm en mode modal l'attente se fait tout seul

edit
et a bien y réfléchir en ce qui concerne le rechargement de "la pile" en rappelant la sub comme a dit pierre
perso je vois pas le soucis dans l'exemple précédent puisque je fait exactement la même chose que dans ton do loop
a savoir :un show

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Sub testx()
    With UserForm1
        .Show
       ' ........

le UserForm est effectivement déchargé et rechargé mais justement cela n'est il pas mieux en ce qui concerne une boite de dialog interactive ?

[Pierre Fauconnier]

Donc, en gros, 17 messages plus tard, tu arrives à la solution que j'ai proposée, sauf que tu commets un Exit For dans un For Next (ce truc ne devrait même pas être permis par le VBA) qui est évitable grâce à la boucle que j'ai donnée, que tu fais du récursif là où ce n'est ni utile, ni probablement souhaité ^(*) et qu'il n'est nul besoin de masquer le userform pour l'afficher à nouveau ensuite^(**)...

Pour ce qui est du récursif, l'espace pile n'est pas infini, même si normalement, on n'arrive normalement pas à un stack overflow...

^(*) Quant à dire qu'il vaut mieux réinitialiser le userform, ça dépend du contexte. Si la proc initialise le userform et que tu viens de remplir x contrôles avec des données, tu ne seras pas forcément très content de voir que tout a été supprimé simplement parce que tu as oublié de cocher une option. Cette approche n'est donc pas à généraliser. Il me semble toujours utile de bien envisager les tenants et aboutissants d'une solution proposée avant de déclarer qu'une solution en vaut une autre. Le résultat d'un appel récursif de fonction n'est, dans ce cas-ci, pas égal à celui d'une boucle et il est judicieux, d'après moi, de ne pas tirer de conclusions hâtives en n'ayant regardé le problème que de son petit bout de lorgnette.

^(**) Normalement, on ne devrait masquer le userform que si l'utilisateur abandonne la saisie, ou si tout est ok niveau saisie , sur le plan informatique (si on attend une date, on a bien une date) et sur le plan métier (la date est-elle valide par rapport aux règles de gestion). Le code de validation informatique doit se trouver dans le userform, le code de validation métier doit se trouver HORS du userform et être indépendant de celui-ci. Au click sur le bouton, on réalise la validation informatique, si elle est bonne, on réalise la validation métier et seulement si c'est ok, on masque le userform et on passe au traitement des informations saisies, puis on décharge le userform. Il ne sert à rien d'essayer de réinventer la roue en imaginant des "patterns", qui en plus ne tiennent pas la route, alors que des patterns existants, testés et validés depuis de nombreuses années, ont fait leurs preuves et constituent en quelque sorte les standards de la programmation procédurale. Et ces patterns, ce n'est pas moi qui les ai inventés, évidemment, je ne fais qu'utiliser des solutions parce qu'elles ont été étudiées, expérimentées et validées par des générations de programmeurs, et donc qu'elles ont fait leurs preuves.

Pour revenir au problème de la discussion (gel de la boite de correction orthographique), le respect des standards et des bonnes pratiques évite la collision, le récursif, l'Exit For et tout ce qui tourne avec.

[patricktoulon]

re
@Pierre

Si la proc initialise le userform et que tu viens de remplir x contrôles avec des données, tu ne seras pas forcément très content de voir que tout a été supprimé simplement parce que tu as oublié de cocher une option. Cette approche n'est donc pas à généraliser.

il y a un moyen simple pour palier a ce cas
a la place du unload tout court

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if optionchoisie<>false then unload userform1

ou le controler dans le UserForm

si il y a des textbox et autres controls modifiés l'ors de l'affichage le UserForm ne sera pas déchargé du moins il me semble même en rappelant la sub

soit le UserForm est une boite de dialog qui doit renvoyer une réponse soit c'est une fenêtre d'interface utilisateur c'est pas la même chose

a noter aussi que optionchoisie sur mon modele ou celui de Marcel peut taper une erreur "serveur distant....." ou tourner indéfiniment pour Marcel si le UserForm est fermé avec la croix

il faut donc prévoir dans le queryclose un if closemode=0 then cancel=true

[Pierre Fauconnier]

Un Unload sur un problème de validation me semble pour le moins radical, puisque toute la saisie va être remise à zéro. C'est vraiment du grand n'importe quoi!

Pour ne pas polluer la discussion, j'ai écrit un billet de blog qui explique la manière dont j'envisage la gestion d'un userform.

J'espère que ce billet vous permettra de mieux architecturer vos codes.