Salut.
L'important n'est pas qu'ils soient
affichés, mais qu'ils soient
chargés.
D'abord, je vois trop souvent du code qui fait ceci:
- afficher le userform;
- récupérer des données (d'une feuille Excel ou autre);
- laisser l'utilisateur manipuler les données, en saisir...;
- traiter les données (inscription dans des cellules, sauvegarde, manipulations diverses);
- masquer le userform et/ou le décharger.
Le problème de cette technique est qu'elle crée un
couplage fort entre le usf et l'environnement dans lequel on l'utilise. Autrement dit, le usf est
très dépendant de l'univers dans lequel on le manipule (nom de feuille, adresse de cellule, ...). Cela induit qu'il n'est souvent exploitable que dans
un contexte très déterminé et
qu'on ne peut que rarement le réutiliser ailleurs sans le modifier, parfois considérablement.
Le rôle d'un userform est d'
afficher des données, de
permettre à l'utilisateur de les modifier, et
c'est tout. Eventuellement, et même assez souvent, on crée
une fonction de validation au sein du userform pour accepter le clic sur OK uniquement si les données sont correctes,
sans que cette fonction doive aller chercher des données à l'extérieur du userform. C'est au code qui a appelé le userform de lui passer les valeurs à afficher ainsi que celles qui permettraient un contrôle de validité éventuelle, et de traiter les valeurs modifiées ou non par l'utilisateur lorsque ce dernier a terminé son traitement.
Pour utiliser un usf comme il se doit, il faut savoir qu'il y a trois états à un userfom:
- non chargé;
- chargé mais non affiché;
- chargé et affiché.
Normalement:
- On charge le userform;
- On lui passe éventuellement des données;
- On l'affiche;
- L'utilisateur modifie des données;
- Un bouton du userform (ou plusieurs) masque(nt) le userform;
- On traite les données du userform;
- On le décharge.
Si on n'a rien à lui passer avant de l'afficher, on peut:
- L'afficher directement (.Show) ce qui a pour effet de le charger avant de l'afficher;
- Laisser l'utilisateur manipuler les données;
- Utiliser un bouton du userform (ou plusieurs) pour masquer le userform;
- Traiter les données du userform;
- Décharger le userform.
Dans l'exemple suivant, je charge trois userform à la suite, je leur passe une info qui affiche une valeur dans un textbox, un bouton les masque, je récupère les valeurs des userforms puis je décharge les userform. Chaque userform contient un textbox1 et un commandbutton1.
Chaque commandbutton1 utilise le code évènementiel suivant, qui ne fait que le masquer:
1 2 3
| Private Sub CommandButton1_Click()
Me.Hide
End Sub |
La procédure suivante d'un module standard te permettra de comprendre comment le tout s'enchaine. Il va de soi que c'est plus intéressant si la valeur du textbox est modifiée par l'utilisateur lorsque le userform est affiché.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
| Sub Test()
Load UserForm1
UserForm1.TextBox1.Value = "Pierre"
UserForm1.Show
Load UserForm2
UserForm2.TextBox1.Value = "Pierre"
UserForm2.Show
Load UserForm3
UserForm3.TextBox1.Value = "Pierre"
UserForm3.Show
Debug.Print UserForm1.TextBox1.Value & ";" & UserForm2.TextBox1.Value & ";" & UserForm3.TextBox1.Value
Unload UserForm1
Unload UserForm2
Unload UserForm3
End Sub |
Normalement, ce n'est pas de la responsabilité du userform d'enregistrer les données. USF3 devrait simplement être masqué, puis la procédure qui a ouvert les différents userform devrait enregistrer les données. Un userform ne sert qu'à afficher des données et à en collecter de l'utilisateur,
jamais à les traiter. En respectant ce principe de base de la programmation, tu écriras un code bien plus facile à tester, à maintenir et à faire évoluer
Eventuellement, voir
ma réponse dans une discussion qui illustre autrement le mécanisme d'utilisation pertinente d'un userform.