Discussion :

[Superpat9999]

Bonjour, j'ai créé un formulaire "sf_CodePostal" avec aucune procédure à l'intérieur.
Lorsque je liste mes formulaires pour rechercher une ligne de code à l'intérieur, il ne peut trouver cette ligne et surtout ne peut l'ouvrir, puisqu'il n'y a rien.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
        For Each doc In oDb.Containers("Forms").Documents
                        Debug.Print doc.Name
 
                With oRst
                        bolExiste = RechercheIntitule("form_" & doc.Name, strSearch)
                        If bolExiste = True Then
                                Debug.Print "Existe : " & doc.Name
                        Else
                                .AddNew
                                ![Liste_Formulaires] = doc.Name
                                .Update
                        End If
                End With
        Next doc

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
Function RechercheIntitule(strModuleName, strSearch) As Boolean
'Procédure qui vérifie si le titre existe.
    Dim mdl As Module
10  On Error GoTo errSub
    Set mdl = Modules(strModuleName)
12  strNomProcedure = "RechercheIntitule"
    ' Return reference to Module object.
14  If mdl.Find(strSearch, 1, 1, -1, -1, False, False, False) Then
        ' On trouve l'intitulé
16      RechercheIntitule = True
18  Else
20      RechercheIntitule = False
22  End If
Exitsub:
24  On Error GoTo 0
26  Exit Function

Comment je gère cette erreur ?

[Superpat9999]

Je me réponds à moi même, pas sûr que ce soit la meilleure solution :

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
18
19
20
21
Function RechercheIntitule(strModuleName, strSearch) As Boolean
        'Procédure qui vérifie si le titre existe.
        Dim mdl     As Module
10      On Error GoTo errSub
        Set mdl = Modules(strModuleName)
12      strNomProcedure = "RechercheIntitule"
        ' Return reference to Module object.
14      If mdl.Find(strSearch, 1, 1, -1, -1, False, False, False) Then
                ' On trouve l'intitulé
16              RechercheIntitule = True
18      Else
20              RechercheIntitule = False
22      End If
Exitsub:
24      On Error GoTo 0
26      Exit Function
errSub:
        If err = 9 Then
13              RechercheIntitule = True
15              On Error GoTo 0
17              Exit Function

[deedolith]

Sinon,
tu peux t'appuyer sur la collections Forms.
N'y sont présent que les formulaires contenant du code VBA.

[Superpat9999]

Merci deedolith pour ta réponse, mais je ne sais pas faire avec collection forms !

[deedolith]

Tu ne sais pas faire quoi ?
Le éléments des collections Forms et Documents ont un truc en commun: La propriété Name (ca se voit dans l'explorateur d'objets).
Ne me dit pas que c'est difficile de récupérer le nom à d'un item dans la collection Forms pour récupérer l'item de même nom à dans la collection Documents.
Ou alors c'est que tu ne veux pas chercher.

[Superpat9999]

deedolith, je trouve que ta réponse est un peu "sévère", pour n'employer qu'un terme léger. Je programme sous Access pour mon plaisir et essayer de m'entretenir les neurones. Si je pose la question c'est que je n'arrive pas à trouver la solution, j'ai assez de temps libre pour chercher. Je viens sur ce Forum depuis longtemps et dans l'ensemble les personnes qui répondent sont sympathiques et pas agressives.
Je suis désolé, mais les collections ne me sont pas familières. J'ai fini par trouver une solution sur un forum annexe, solution pas évidente et pas à ma portée.
Bonne journée tout de même.

[deedolith]

Basiquement, une collection est un conteneur qui associe une clef à une valeur.

Je t'invite à te renseigner dessus.
car parmis les objets Office à disposition (que ce soit Access, Excel, Word, Power point ect ...), des collections il y en a des pelles,
et savoir les manipuler un minimum ne te sera que bénéfique.

Je t'invite également à te renseigner sur les différents outils de l'éditeur VBA (explorateur d'objets, fenêtre d'exécution, fenêtre espions).

[hyperion13]

Salut
Il fallait sans hésiter sortir l'artillerie lourde.
@deedolith est coutumier dans l'art de la prose. Pour info il n'apprécie pas ma notation à la hongroise en VBA Excel. Ça pollue sa vision.

deedolith, je trouve que ta réponse est un peu "sévère", pour n'employer qu'un terme léger. Je programme sous Access pour mon plaisir et essayer de m'entretenir les neurones.

@deedolith n'arrive toujours pas à faire la distinction entre ceux qui écrivent "Je veux" et ceux qui écrivent "Je voudrais" comme toi @Superpat9999

Si je pose la question c'est que je n'arrive pas à trouver la solution, j'ai assez de temps libre pour chercher. Je viens sur ce Forum depuis longtemps et dans l'ensemble les personnes qui répondent sont sympathiques et pas agressives.

@Superpat9999 tu es familiarisé aux collections. Une 1ère collection ici, une 2nde ici et autre là.

Je suis désolé, mais les collections ne me sont pas familières. J'ai fini par trouver une solution sur un forum annexe, solution pas évidente et pas à ma portée.

Je reviens au postulat de ton Post#1
Si j'ai bien compris, à l'aide de ta sub() tu cherches à savoir si dans la collection Forms l'un d'eux contient ou non un module et que ce module contient au moins des lignes de code.
Tu évoques le problème de ton sform sf_CodePostal qui contient un module mais sans aucune sub() et/ou function() et génère l'erreur 9.
Par contre il doit contenir 2 lignes vides. A vérifier
Pas certain que je réponde à ta problématique

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
18
19
20
21
22
23
24
25
26
27
28
Private Sub btnListeForms_Click()
' Procedure : Obj_HasModule
' Website   : https://www.devhut.net/ms-access-vba-hasmodule/
Dim dbs As DAO.Database
Dim rst As DAO.Recordset
Dim doc As DAO.Document
Dim iCount As Long
 
Set dbs = CurrentDb
Set rst = dbs.OpenRecordset("tbl_forms", dbOpenDynaset)
 
For Each doc In dbs.Containers("Forms").Documents ' on parcoure les forms
    If Obj_HasModule(doc.Name, "Form") Then ' on vérifie s'ils contiennent un module
        iCount = VBE.ActiveVBProject.VBComponents("Form_" & doc.Name).CodeModule.CountOfLines ' on compte le nombre de lignes dans le module
        Debug.Print "Nom du frm: " & doc.Name & " - " & "nb lignes dans Module: " & iCount
        If iCount > 2 Then
            With rst
                .AddNew
                ![nom_form] = doc.Name
                ![nbligne_mod] = iCount
                .Update
            End With
        End If
    End If
Next
 
Set dbs = Nothing
End Sub

[deedolith]

Je me doit de répondre aux attaques personnelles:

@deedolith est coutumier dans l'art de la prose. Pour info il n'apprécie pas ma notation à la hongroise en VBA Excel. Ça pollue sa vision.

Ce n'est pas "Ta" notation hongroise, c'est "La" notation hongroise.
C'est juste inutile.
Les temps ou l'on programmait avec un simple éditeur de texte (genre: Edit sous MS-DOS) sont révolu, on a à disposition de puissants IDE nous fournissant multitude d'informations qu'un document texte ne peut révéler.
Pourquoi intégrer les types de donnée aux noms de variable quand l'IDE nous donne cette information ?
Les types de données ne sont utiles que pour le compilateur, pour entre autre vérifier la concordance des types, ce n'est pas le travail du programmeur (ce qu'introduit implicitement la notation hongroise).
Un bon nom de variable doit refléter son rôle, un type de données n'est pas un rôle.
Pour rester cohérent avec la notation hongroise, un changement de type de données impose de renommer les variables, avec tous les risques d'erreur que ca comporte. Pour la maintenance, c'est zéro (plus de travail que nécessaire).
Ca nuit à la lisibilité (des noms plus long et plus complexe que nécessaire).

Pour rappel, avant d'être fonctionnel, un code source doit être lisible et intelligible.

@deedolith n'arrive toujours pas à faire la distinction entre ceux qui écrivent "Je veux" et ceux qui écrivent "Je voudrais" comme toi @Superpat9999

Contrairement à ce que de nombreux articles et personnes veulent faire penser, programmer, c'est difficile, et programmer correctement, encore plus.
Ce demande entre autre, un minimum de connaissance (les bases du langage et de l'IDE), de la discipline et de la recherche, histoire de savoir ce qu'on manipule.

[loufab]

Bonjour,

J'aime bien les discussions de fond sur les méthodes de chacun.

Utiliser la notation hongroise n'est pas forcément inutile. ça permet de savoir d'un coup d'oeil à quel type on fait face. Surtout qu'avec VBE il n'y a que 2 moyens de savoir :
Soit pendant l'exécution. (on y est pas toujours et poser un Espion c'est pas pratique)
Soit en utilisant le menu contextuel. (ne pas oublier de poser un drapeau pour revenir au code en cours. Bref ! pas très pratique non plus)

Alors oui, quand on programme de petites applications dans son coin la notation hongroise on passe souvent outre. Par contre quand on est sur de gros projets qui sont destinés à vivre et évoluer, seul ou à plusieurs c'est quand même plus pratique de l'utiliser. A noter qu'on a souvent le sentiment avec l'IDE VBE d'être plus proche d'Edlin que d'Eclipse.

Partir du principe que les fonctionnalités de l'IDE fait le job à notre place c'est comme dire que les commentaires ne servent à rien parce qu'une programmation claire nous en dispense (claire dans la tête de l'auteur comme souvent le nom d'une variable).

Si on suit ce résonnement alors pourquoi perdre son temps à déclarer des variables ?! Supprimons l'Option Explicit et ne déclarons aucun type puisque le langage nous le permet ! Après tout le Variant fait le job (à priori dans 80% des cas ça se passe bien) et on a de la ram à revendre. Si cela nuit aux performances c'est pas grave on a de la puissance.

J'ai volontairement utilisé la citation pour signaler que ce que j'écris sont une suite d'ANTIPHRASES !

Chacun a ses méthodes adaptées à ses expériences et au cycle de vie de l'application (il n'est jamais trop tard pour commencer à l'utiliser sur une appli déjà commencée). J'avoue que personnellement ce n'est pas systématique, tout ce qui est stockage d'id tout comme les compteurs de boucle je me passe de cette notation parce que généralement elles restent internes à mes procédures.

Sinon c'est bien aussi d'expliquer les choses par des exemples concrets ou des liens vers des tutos compréhensibles par le lecteur.

Cordialement,

Ps : Je crois que quand Hyperion dit "ma" ce n'est pas qu'il s'en attribut la paternité mais probablement qu'il y a un passif sur la question.

[deedolith]

Je te redirige sur l'article wikipedia:
https://en.wikipedia.org/wiki/Hungarian_notation

Pour faire bref:
La notation hongroise est utile sur les langage faiblement typés ou non typés.
Dans le cas contraire, les désavantages surclassent les avantages.

A ma connaissance, VBA est un langage fortement typé.

[loufab]

Merci pour ce lien je pense que son contenu peu éclairer ceux qui ne connaissent pas le sujet.

On peut regretter seulement qu'il fait surtout référence aux langages compilés avec des IDE performant, ce que VBA est loin de représenter.

En quelques points :

1) VBA est fortement typé, si on le lui demande. On peut faire du quick & dirty sans Option Explicit ou en utilisant du Dim non typé, on le voit souvent dans des instruction du type,

Code :

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

Dim tota, tata, titi as string

Où l'auteur pense être sur JAVA ou autre.
2) VBA n'est pas un langage compilé, donc rien en aval pour signaler les incohérences.
3) Et toutes les raisons pratiques appliquées à VBA et non à d'autres langages qui bénéficient d'un compilateur et d'un IDE performant. Ce que j'ai indiquées précédemment. Je ne t'engage pas à les lire.
4) Si un point négatif est à retenir c'est en effet le problème lors de l'autocomplétion. ça peut être ennuyeux lorsqu'on a de nombreuses variables publique, mais là encore on peut se dire que trop de variables publiques peut cacher un problème de conception.

Cordialement,