Discussion :

[MULTON]

Bonjour,
j'utilise un Userform sous VBA 6.3 pour entrer des données sur une feuille.
Un premier userform est activé à l'ouverture du classeur avec 3 options.
L'une d'elles me renvoit sur le Userform qui me permet d'entrer les données.
Un Commandbutton valide les données puis lance une macro qui permet de mettre à jour les données sur la feuille.
Si un enregistrement a déjà été effectué à cette date, une boite de dialogue (écraser, annuler, retour) apparait et me renvoie éventuellement sur la macro si je choisi l'option écraser.
Je peux me rendre compte que les variables sont bien prises en compte dans ma "fenêtre espion".
J'ai déclarer "Option Explicite" et mes variables en "Public" à la racine du module.
Par contre elles ne sont pas conservées lors de l’exécution de la macro.
J'en suis arrivé à inscrire les variables sur une feuille pour les utiliser tout au long de la procédure puis les supprimer en fin.
Je sais, c'est du bricolage mais je n'ai trouvé que cela comme solution fiable.
C'est pourquoi j'en appelle à votre aide.
Merci de votre attention.

[eriiic]

Bonjour,

J'ai déclarer "Option Explicite" et mes variables en "Public" à la racine du module.

De quel module ?
Il faut que ce soit un module standard, pas un d'un UF ou d'une feuille.
eric

[MULTON]

Merci pour cette réponse rapide Éric.
Je n'ai qu'un module dans lequel figure la macro.
J'ai inscris "Option explicit" et les déclarations "Public" des variables à la racine de ce module.
Cordialement

[eriiic]

Ca ne répond pas à la question...
Fais Insertion / Module et déclare-les dedans.
eric

[MULTON]

Bonjour Eric,
j'ai inséré un module, y ai fais les déclaration mais cela ne change rien.
Voici la structure du fichier avec la "fenêtre espion". Dans cette dernière la date disparait et bien que la variable LISIER soit à 10, rien ne sera écrit sur ma feuille.

[eriiic]

Bonjour,

en supposant que tu l'aies bien initialisée à moment donné, une cause pourrait être que DATE1 est restée déclarée ailleurs.
eric

PS ; je viens de voir que tu parles de LISIER.
La variable qu'on voit est celle du Textbox, regarde le type de l'objet.
A utiliser les même noms tu ne peux que t'y perdre, vba aussi dans certains cas.
Met un préfixe comme Tbx_nom à tous tes objets Textbox. En plus, en lisant on sait à quoi on a affaire.

Par ailleurs, pour rechercher une date je te conseille plutôt de récupérer la ligne avec l'équivalent VBA de Equiv().
.Find sur une date est plutôt scabreux si tu ne maitrises pas tout.
eric

[Patrice740]

Bonjour,

Il faut utiliser les variables publiques avec parcimonie : uniquement quand c'est indispensable, c'est à dire quasiment jamais !
Il est très largement préférable de transférer des variables locales via les arguments des procédures, c'est d'ailleurs à ça que servent les arguments !

A lire : https://docs.microsoft.com/fr-fr/off...c-naming-rules

PS : il faut aussi éviter les .Select inutiles (le seul qu'on voit est dans ce cas) et il est fortement conseillé de préciser le parent des Range !

[MULTON]

Merci à vous pour votre aide.
je me mets au travail en appliquant vos recommandations.
Une chose quand même qui m'interpelle. Comment peut'on pérenniser la valeur d'une variable venant d'un USF-textbox en ne déclarant pas "public" ces variables ?
En tous cas merci encore pour votre aide.
Je vous tiens au courant dès que possible.

[Patrice740]

Re,

Comment peut'on pérenniser la valeur d'une variable venant d'un USF-textbox en ne déclarant pas "public" ces variables ?

Je ne comprends pas ce que tu veux dire, par définition une variable est ... variable, et donc pas pérenne.
Comme je t'ai dis, il vaut mieux déclarer les variables dans la procédure qui les utilise, c'est à dire des variables locales qui disparaissent lorsque la procédure est terminée.
Si des variables doivent être utilisées dans d'autres procédures appelées par la procédure principale, il faut les transmettre en argument.

Par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
Sub Bonjour()
Dim str_a_envoyer As String
  str_a_envoyer = "Bonjour"
  Call AfficheMessage(str_a_envoyer)
End Sub
 
Sub AfficheMessage(str_a_afficher As String)
  MsgBox str_a_afficher
End Sub

[MULTON]

Ce que je veux dire par pérenne c'est que le fait de les déclarer en "Public" elles garde leur valeur dans toutes les procédures de mon classeur, USF et Modules tant qu'une action volontaire n'est pas déclenché pour en changer.

J'ai une date et 19 variable à entrer sur un USF.
Je contrôle la date du textbox et j'initialise ma variable "DATE1" comme suit :

Code :

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

1
2
3
4
5
6
Private Sub Tbx_DATE1_BeforeUpdate(ByVal Cancel As MSForms.ReturnBoolean)
     If Not IsDate(Tbx_DATE1) Then
        MsgBox "La saisie n'est pas une date !"
        Cancel = True
    End If
End Sub

Je contrôle mes autres textbox et je les initialise comme suit :

Code :

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

1
2
3
4
5
6
7
8
Private Sub Tbx_LISIER_BeforeUpdate(ByVal Cancel As MSForms.ReturnBoolean)
Tbx_LISIER = (Replace(Tbx_LISIER, " ", "_"))
Tbx_LISIER = (Replace(Tbx_LISIER, ".", ","))
If Not IsNumeric(Tbx_LISIER) Then
        MsgBox "La saisie n'est pas un nombre !"
        Cancel = True
End If
End Sub

Puis je valide mes entrées :

Code :

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

1
2
3
4
5
6
7
8
Private Sub traitement_données_Click()
Unload Me
DATE1 = CDate(Tbx_DATE1)
 
If Tbx_LISIER = "" Then
Tbx_LISIER = 0
End If
LISIER = CSng(Tbx_LISIER)

Idem pour les autres entrées

Et j'appelle une macro pour mettre à jour ma feuille. Mais déjà là mes variables sont hors contexte alors que je les ai déclarées en "Public" à la racine du module de ma macro.

Je voudrais d'abord comprendre pourquoi mes variables ne garde pas leur valeur avant d'essayer de me passer des déclarations "Public".
Je n'arrive d'ailleurs pas à assimiler le passage d'argument alors que ce dernier change de nom d'une macro à l'autre. Comment faire avec 20 arguments ?
Je dois vous paraitre "lourd" mais je suis un amateur autodidacte. J'utilise VBA depuis des années et j'ai toujours été embêté par ces variables. D’où mon recours jusqu'à maintenant de l'écriture sur une feuille de ces variables puis leur effacement en fin de projet.
Merci pour votre attention
Cordialement
Denis

[eriiic]

Bonjour,

regarde si cet exemple fonctionne chez toi.
Et ce que tu fais de différent éventuellement.
eric

[Transitoire]

Bonjour a tous!
Cher Multon, le post N° #9 de Patrice740 ()() me semble très explicatif de la démarche à suivre. je vous conseille donc de le lire attentivement.
On peut par ailleurs passer plusieurs arguments à condition de les séparer par une virgule exemple ( Call Test(maVar, Mvar) )
Il n'est donc plus utile de passer par des Variables publiques pour passer des arguments.
Cordialement

[Patrice740]

Bonjour,

Je n'arrive d'ailleurs pas à assimiler le passage d'argument alors que ce dernier change de nom d'une macro à l'autre.

Comme je t'ai dit, une variable locale n'existe que dans la procédure où elle est déclarée, c'est pour ça que j'ai volontairement mis cet exemple :
- str_a_envoyer est déclarée dans la procédure appelante, elle n'existe que dans la procédure appelante : Sub Bonjour
- str_a_afficher est déclarée dans la procédure appelée, elle n'existe que dans la procédure appelée : Sub AfficheMessage
Lors de l'appel de la procédure par Call AfficheMessage(str_a_envoyer), l'argument de la procédure appelée prend la valeur de la variable indiquée dans la procédure appelante, c'est à-dire que str_a_afficher prend la valeur de str_a_envoyer.
Précision complémentaire :
- Lorsqu'on transfère une variable ByRef (ce qui est le cas par défaut), les modifications apportées à la variable de la procédure appelée sont renvoyée à la variable de la procédure appelante.
- Lorsqu'on transfère une variable ByVal, les deux variables sont indépendantes, la variable de la procédure appelante conserve sa valeur initiale après la fin de la procédure appelée.

C'est là tout l'intérêt de cette méthode, les procédures appelées sont autonomes et polyvalentes, elles peuvent être appelées par différentes procédures, être réutilisées à volonté dans différentes applications.

[unparia]

Bonjour

Commentaires parlants ajoutés au code incriminé --->>

Code :

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

1
2
3
4
5
6
7
8
9
Private Sub traitement_données_Click()
          Unload Me ' ---->> ce qui décharge donc le userform
          DATE1 = CDate(Tbx_DATE1) '      |
          '                                  | le userform ayant été déchargé,
          If Tbx_LISIER = "" Then '    | aucune des instructions suivantes
            Tbx_LISIER = 0 '              | ne sera donc   exécutée 
          End If '                       | (DATE1 et LISIER ne seront donc pas (re)initialisées). 
          LISIER = CSng(Tbx_LISIER) '   |
....

[Pierre Fauconnier]

Salut.

Pour moi, voici le schéma minimal correct d'utilisation d'un userform qui récupère des valeurs de cellules et les y repoussent après saisie. On voit bien qu'il n'y a aucune variable publique ( Patrice740), celles-ci n'ayant rien à faire dans du code que je qualifie de professionnel, à de très rares exceptions près.

Voici le code du userform, qui illustre que ce userform ne dialogue pas directement avec les cellules. Ce n'est pas son rôle.

Code vba :

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
Option Explicit
 
Public Result As String
 
Private Sub btnValidate_Click()
  If DatasAreOk Then
    Result = "Validated"
    Me.Hide
  Else
    MsgBox "Données non valides"
  End If
End Sub
 
Function DatasAreOk() As Boolean
  DatasAreOk = (UCase(tboValue.Value <> "BONJOUR"))
End Function

Le code qui gère le transfert Cellules->Usf et Usf->Cellules. On remarque que le userform n'est pas chargé de manière explicite (absence de Load Userform1). Par contre, il est bien déchargé en fin de process, après en avoir exploité les informations

Code vba :

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

1
2
3
4
5
6
7
8
9
10
Sub Test()
  With UserForm1
    .tboValue.Value = Range("a1").Value
    .Show
    If .Result = "Validated" Then
      Range("a1").Value = .tboValue.Value
    End If
  End With
  Unload UserForm1
End Sub

Il faut noter que Unload Userform1 décharge le userform de la mémoire, et que suite au chargement implicite du formulaire lors de son utilisation dans le code, ce qui suit affichera la valeur par défaut du textbox du formulaire (chargement implicite du formulaire sur la ligne msgbox... et récupération de la valeur par défaut du textbox)

Code VBA :

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

1
2
3
4
Sub Test2()
  Unload UserForm2
  MsgBox UserForm2.TextBox1.Value
End Sub

Il faut bien comprendre le cycle de vie du userform:

1. chargement (explicite ou implicite);
2. événement Initialize (normalement rarement utilisé selon mes bonnes pratiques);
3. "vraie" initialisation par code (hors du formulaire);
4. affichage;
5. masquage;
6. exploitation des données du userform;
7. déchargement.

En complément, mon billet de blog à ce sujet

[MULTON]

Merci à vous tous, Patrice, Eric, Transitoire, unparia, Pierre !
Mon problème venait effectivement d'un "Unload Me" mal placé.
Je vais tenir compte de toutes vos suggestions.

Nommer mes "Textbox" en TBS_xxx différemment de mes variables.
Utiliser "Equiv" plutôt que "Find" pour les recherches de date.
Ne pas décharger l'"USF" avant d'avoir valider mes variables.
Ne pas utiliser les déclarations "Public" (enfin je vais essayer)

Enfin deux dernières questions avant de considérer comme résolue cette discussion :

Si je dois transférer mes vingt variables par arguments séparés par des virgules, la procédure appelée les reprend comment ? dans le même ordre ?
Les arguments de la procédure appelée peuvent-ils garder la même syntaxe que la procédure appelante ?

Merci beaucoup de mettre à disposition vos connaissances et de consacrer du temps à des personnes comme moi.
Super site, vraiment !
Denis

[Patrice740]

Re,

Si je dois transférer mes vingt variables par arguments séparés par des virgules, la procédure appelée les reprend comment ? dans le même ordre ?

Oui mais il est aussi possible de les transférer dans un ordre différent en utilisant des arguments nommés

Les arguments de la procédure appelée peuvent-ils garder la même syntaxe que la procédure appelante ?

La même syntaxe ???? je suppose que tu demandes si on peut nommer la variable de la procédure appelée avec le même nom que celui de la procédure appelante :
Oui mais ça peut être source de confusion.

Si je dois transférer mes vingt variables ...

Selon le cas, il peut être plus simple de transférer une seule variable contenant tes variables, pour ça au moins 2 méthodes :
- transférer un type de variable personnalisée (je préfère cette option, c'est plus facile à lire)
- transférer un tableau de 20 données de type Variant

Voir ce tuto, en particulier le § IX : http://silkyroad.developpez.com/VBA/LesVariables/

Notes que le Type de variable personnalisé est déclaré en Public ou en Privé, mais que chaque variable de ce type peut être déclarée en local dans la procédure.

[eriiic]

Je ne comprend pas bien ce rejet des variables publiques et cette volonté de vouloir s'en passer à tout crins.
Il y a une raison à leur existence et elles ont leur rôle. Ca existe dans tous les langages, avec une portée et une durée vie différente.
Quel est le problème de s'en servir dans ce cadre ?
eric

[MULTON]

Merci encore pour toutes ces explications.
J'ai lu vos blog et tutos et j'avoue que j'ai du pain sur la planche. Quel niveau ! Mais je sais que j'ai les réponses à mes questions. A moi de travailler maintenant.

[Pierre Fauconnier]

Bonjour

Commentaires parlants ajoutés au code incriminé --->>

Code :

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

1
2
3
4
5
6
7
8
9
Private Sub traitement_données_Click()
          Unload Me ' ---->> ce qui décharge donc le userform
          DATE1 = CDate(Tbx_DATE1) '      |
          '                                  | le userform ayant été déchargé,
          If Tbx_LISIER = "" Then '    | aucune des instructions suivantes
            Tbx_LISIER = 0 '              | ne sera donc   exécutée 
          End If '                       | (DATE1 et LISIER ne seront donc pas (re)initialisées). 
          LISIER = CSng(Tbx_LISIER) '   |
....

Unparia, ce que tu écris là est inexact.


Contrairement à ce que tu affirmes, le code est bien exécuté, avec les valeurs par défaut des textbox. En effet, la ligne Unload Me décharge bien le userform, mais il est rechargé avec les valeurs par défaut à la ligne suivante. Les instructions sont donc bien exécutées^* (du reste, leur exécution ne dépend évidemment pas de l'état du formulaire, chargé ou non donc), contrairement à ce que laissent entendre tes commentaires (=> "le userform ayant été déchargé, aucune des instructions suivantes ne sera donc exécutée (DATE1 et LISIER ne seront donc pas (re) initialisées").

^* DATE1 et LISIER seront donc bien réinitialisées avec les valeurs par défaut des textbox correspondants du userform. Si une date par défaut est présente dans Tbx_Date ou qu'une valeur par défaut est présente dans Tbx_LISIER, les variables recevront ces valeurs. Idem si l'événement Initialize valorise ces contrôles, ce qui aura pour effet de transférer ces valeurs aux variables.

Les lignes sont bien exécutées et les variables (ré)initialisées!.