Discussion :

[lipaika]

Bonjour,

Je me débrouille un petit peu maintenant en VBA, mais je n'écris pas du code pro et je voudrais des conseils pour organiser mon code de manière plus rigoureuse.

Mon problème se pause notamment sur les userform:
J'ai un userform dans lequel je récupère un nom d'utilisateur et six nombres fétiches. un bouton permet de valider l'entrer et de lancer la macro principale.

code userform:

Code :

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

1
2
3
4
5
6
Private Sub CommandButton1_Click()
    NomUser=recup_nom()
    Tableau=recup_tab()
    call traiter_donnees()
    userform1.hide
end Sub

code Module 1:

Code :

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

1
2
3
4
5
Public NomUser as string
Public tableau() as string
Public sub traiter_donnees()
...
end sub

Pour que traiter_donnees se lance quand je clique sur valider, il faut le declarer en public, ce qui me semble risquer (tous les utilisateurs peuvent avoir acces a cette proc depuis le classeur!!)
Je voudrais savoir quelle est la métode pour faire communiquer les entités userform et module??

Si vous avez de la doc à me conseiller merci d'avance

[Bigalo]

Bonsoir,

Il existe une astuce simple : seules les macros ne nécessitant aucun argument apparaissent dans la liste des macros exécutables depuis l’environnement Excel.

Il suffit donc de remplacer

Code :

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

Public sub traiter_donnees()

par

Code :

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

1
2
Sub traiter_donnees(Optional i as Integer)
' NB - L’argument optionnel i a pour sel fonction de rendre la macro invisible depuis l’environnement Excel

La ligne de commentaire évite que quelqu’un (soi-même quelques mois + tard, ou un autre développeur), ne supprime l’argument optionnel, sous le fallacieux prétexte qu’il paraît inutile

J’ignore pourquoi, mais il faut typer la variable, sinon la macro reste accessible. Quant au mot Public, il n’est pas nécessaire : une Sub d’un module standard, non précédée de Private, est accessible directement à partir de tout module (y compris ceux des UserForms, donc) du projet

Cordialement,

[SilkyRoad]

bonjour

Si vous avez de la doc à me conseiller merci d'avance

j'espère que ce lien pourra t'aider:
http://excel.developpez.com/cours/


bonne journée
michel

[lipaika]

Merci pour l'astuce.

Pour ce qui est des modules et classes, y a t'il une méthode simple pour les définir? Je veux dire, quand est-ce que l'on crée une classe ou un nouveau module. Comment instancie t'on un élément d'une classe?

Avez vous un exemple simple de marche à suivre ou un exemple de code implémenté de façon pro?

Merci

[patbou]

bonjour,

un lien pour les modules de classe

http://sinarf.developpez.com/access/vbaclass/#L0

[Bigalo]

Bonjour lipaika,

De rien

On ne définit pas de module, on en crée, en fonction des besoins, éventuellement par programmation.

Un module est l’endroit où placer le code.

Il en existe de 2 sortes, les modules standards et les modules de classe. Les modules "ThisWorkbook", et les modules associés à une feuille ou un UserForm étant un cas particulier de modules de classe.

Pour ces 3 cas particuliers, le module est utilisé pour gérer les événements liés à l’objet associé (les événements de niveau classeur, pour ThisWorkbook, ceux de niveau feuille pour un module associé à une feuille, et ceux relatifs au UserForm ou à l’un quelconque de ses contrôles pour un module associé à un UserForm).

Quant une fonction ou une procédure ne concerne directement pas un événement, son emplacement normal est dans un module standard. Toutefois, pour simplifier la lecture du code, ou pouvoir accéder directement aux contrôles d’un UserForm, ou à des variables de niveau module (définies avec Private, en haut d’un module), rien n’empêche d’écrire des procédures non événementielles, ou des fonctions, dans le module associé à un UserForm, par exemple :

Voici un cas typique : BOK est le nom d’un bouton OK sur un UserForm. Quant l’utilisateur clique sur ce bouton, il faut en général effectuer un contrôle de saisie, et selon le résultat afficher un message indiquant les données (non facultatives) non renseignées ou poursuivre le traitement. Voici un exemple de code (placé dans le module du UserForm), gérant cela :

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
Private Sub BOK_Click()
    ControleSaisie
        If Resultat Then
            ReportDonnees
            Unload Me
        End If
End Sub
 
Private Sub ControleSaisie()
    Resultat = Controle(TNom = "", "le nom.", TNom)
    If Resultat Then Resultat = Controle(TPrenom = "", "le prénom.", TPrenom)
End Sub
 
Private Sub ReportDonnees()
     ' Ici le traitement des données saisies grâce au UserForm
End Sub

BOK_Click() est une procédure événementielle liée au bouton "OK". Il est donc nécessaire (à des cas particuliers près, comme l’emploi d’un module de classe distinct pour gérer avec une procédure unique, le même événement pour plusieurs contrôles similaires) que cette procédure soit dans le module du UserForm.

ControleSaisie et ReportDonnees sont 2 procédures appelées par OK_Click(). Elles ne servent nulle part ailleurs (il y des procédures équivalentes, portant le même nom, pour chaque UserForm, mais leur contenu est spécifique au UserForm concerné). On pourrait les mettre dans un module standard, mais ce serait se compliquer la vie : il faudrait donner un nom distinct à la version associée à chacun des UserForms, et qualifier tous les contrôles :

Ici, TNom est un TextBox sestiné à entrer un nom de famille. Dans le module associé au UserForm, on s’y réfère directement, par exemple

Code :

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

ActiveCell = TNom.Value

ou plus simplement

Code :

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

ActiveCell = TNom

car .Value étant la propriété par défaut d’un objet TextBox, elle est implicite, et il n’est nécessaire de l’indiquer explicitement que dans un petit nombre de cas.

Dans un autre module, pour faire référence à TNom, il faut le qualifier en le précédant du nom du UserForm (DNaturaliste, en l’occurrence, "D" pour Dialogue, et "Naturaliste" car le UserForm est destiné à saisir les infos relatives à un naturaliste). Il faut alors écrire :

Code :

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

ActiveCell = DNaturaliste.TNom

Il est clair que si une procédure a besoin d’accéder aux contrôle d’un UserForm chargé en mémoire, le code sera plus court si on met la procédure dans le module du UserForm, puisque cela dispense de devoir qualifier les contrôles.

Quant à Resultat, et Controle, utilisés dans la procédure ControleSaisie, il s’agit d’une variable publique et d’une procédure, situées toutes les 2 dans un module standard, ce qui permet de les appeler depuis le module de n’importe quel UserForm.

Controle est une fonction à laquelle on passe différents arguments permettant

• De tester une expression, permettant de détecter une anomalie (info non renseignée sur le UserForm, ou incorrecte),
• D’afficher, le cas échéant, un message indiquant ce qui ne va pas,
• De sélectionner, le cas échéant également le contrôle où corriger l’anomalie détectée.

Resultat est un booleen qui prend la valeur True, si la fonction Controle n’a pas détecté d’anomalie, False sinon.

Selon les UserForms, la fonction Controle est appelée un nombre variable de fois. La procédure ReportDonnees n’est éxécutée que si Resultat = True après l’ensemble des contrôles.

Quant à l’instanciation de classes, quelqu’un d’autre te répondra. J’utilise en effet relativement peu les modules de classes (autres que ThisWorkbook, et ceux qui sont associés à une feuille ou un UserForm).

Cordialement,