Discussion :

[fergut]

Bonjour
Je souhaiterais savoir si c'est possible de créer des sous formulaires comme dans Accès !
Merci de bien vouloir me renseigner.

[Alex020181]

Bonjour,

Excel permet effectivement de créer des formulaires mais pas aussi "facilement" qu'Access.

Access est prévu pour des formulaires de présentation de données. Excel te laisse la possibilité de créer des formulaires objet par objet (zones de saisie, cases à cocher, ...) mais tu devras toi-même écrire le code qui les fera s'articuler.

[Patrice740]

Bonjour
Je souhaiterais savoir si c'est possible de créer des sous formulaires comme dans Accès !
Merci de bien vouloir me renseigner.

Non il n'est pas possible avec Excel de créer un sous-formulaire, c'est-à-dire un formulaire qu'on pourrait intégrer dans un formulaire "principal".

[fergut]

Bonjour,
J’ai des problèmes avec mes formulaires de saisies
Gestion des adhérents :
J’ai un formulaire de saisie « frmSaisie » qui alimente une feuille « Données » de 400 adhérents sylviculteurs : nom, qualité, adresse, tel, mail et cotisations, un champ « surface forêt » et génération d’un code adhérent « txtCode ».
Gestion des parcelles
J’ai un Formulaire saisie foret « frmsaisieforet » qui alimente une feuille « Données forêt » avec les différentes parcelles du sylviculteur concerné, code adhérent, Adresse parcelle, N°, surface, lieudit, environ 4000 parcelles (moyenne de 10 par adhérent)
Le total des surfaces des parcelles « frmsaisie_PF » devrait alimenter la surface foret de l’adhérent « txtSurf_Foret »pour le calcul de sa cotisation.
Une parcelle ne peut être qu’a un seul adhérent, 1 adhérent peut avoir plusieurs parcelles
Le lien entre les deux est le code adhérent. « txtCode »
Feuilles actives : Donnees, donnees_foret, tableau de bord et listes déroulantes et codes_champs
Les deux formulaires sont opérants sauf la fonction « le bouton Ajout de frmsaisie_DF » mais qui fonctionne sur « frmsaisie »
Également « frmsaisie_PF » je n’arrive pas à valider la ligne « ActiveCell.Offset(0.1).Value = txtSection_PF = ( 0. 10 )
Puisqu’il n’est pas possible d’avoir un sous formulaire je souhaiterais lier ces deux formulaires « frmsaisie et rfmsaisie_PF » afin de saisir les différentes parcelles de foret d’un adhérent depuis le formulaire « frmsaisie »
frnSaisie : Dans « txtCode » je souhaiterais l’equivalent : ‘=CONCATENER(GAUCHE(I150;2);GAUCHE(J150;2);S150;L150)
Concaténation des 2 premiers caractères de « txtNom », es 2 premiers caractères de « txtPrenom »,
txtINSEE et txtDoublons

Merci de bien vouloir me renseigner pour corriger le « frmsaisie_PF », me donner la procédure de liaison des deux formulaires et la fonction concaténer

Merci

ci-dessous ma BDD


https://fromsmash.com/2-bEsLhe5l-ct
Egalement feuille Excel pour transposition instructions EXCEL

[Alex020181]

Bonjour,

Tu ne peux pas faire une double affectation de valeur en une seule ligne en VBA.

Code VBA :

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

ActiveCell.Offset(0.1).Value = txtId_PF = ""

n'est syntaxiquement pas correct.

A priori de ce que je comprends de cette ligne tu veux:
- reporter "txtId_PF" dans ActiveCell.Offset(0.1)
puis
- vider la zone du formulaire txtId_PF

Il te faut faire en 2 temps (je reprends ta méthode volontairement même si on pourrait éviter d'utiliser "ActiveCell.Offset")
-

Code VBA :

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

ActiveCell.Offset(0.1).Value = txtId_PF

puis
-

Code VBA :

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

txtId_PF = ""

C'est le même principe sur l'ensemble de ces lignes

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
 
    ActiveCell.Offset(0.1).Value = txtId_PF = ""
    ActiveCell.Offset(0.2).Value = txtCode = ""
    ActiveCell.Offset(0.3).Value = txtNom = ""
    ActiveCell.Offset(0.4).Value = txtPrenom = ""
    ActiveCell.Offset(0.5).Value = txtVille = ""
    ActiveCell.Offset(0.6).Value = txtCode_postal = ""
    ActiveCell.Offset(0.7).Value = txtCommune = ""
    ActiveCell.Offset(0.8).Value = txtDepar_PF = ""
    ActiveCell.Offset(0.9).Value = txtINSEE_PF = ""
    ActiveCell.Offset(0.1).Value = txtSection_PF = ""
    ActiveCell.Offset(0.11).Value = txtNum_PF = ""
    ActiveCell.Offset(0.12).Value = txtLieu_PF = ""
    ActiveCell.Offset(0.13).Value = txtSurf_PF = ""
    ActiveCell.Offset(0.14).Value = cboPEFC_PF = ""

[fergut]

Merci pour ta réponse

Mes deux formulaires ont été créés d'après un tuto de Learnacces (1,2,3) et cela fonctionne parfaitement dans le formulaire frmSaisie mais pas avec frmSaisie_pf pour quelle raison !
______________________________________________________

Cette instruction c'est dans frmSaisie: txtCode

Code :

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

1
2
3
Private Sub txtCode_Change()
        TxtCode = Left(txtNom, 2) & Left(txtPrenom, 2) & txtINSEE & txtDoublons
End Sub

______________________________________________________
Dans ma BDD tu as une feuille Codes_champs
Peut on utiliser plusieurs fois ces variables dans 2 formulaires !
Merci

[Alex020181]

Je te confirme, en tout cas sur ma version Excel, une double affectation ne passe pas.

Dans le code du bouton "Ajouter" de ton formulaire "frmsaisie" tu n'utilises pas la double affectation. Tu utilises des affectations simples (regarde le nombre de fois ou tu as mis le signe "=" dans ta ligne).

Code vba :

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

ActiveCell.Offset(0, 5).Value = txtDenomination

Donc aucun souci.

Par contre si je modifie cette ligne de code pour faire une double affectation comme tu le fais dans le second formulaire

Code vba :

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

ActiveCell.Offset(0, 5).Value = txtDenomination = ""

Cette ligne ne fera pas planter l'exécution du code mais le résultat affiché sera erroné.

[Pierre Fauconnier]

@Patrice,

Le VBA ne passera pas non plus, je doute que les TCD, graphiques, listes de validation, etc, etc, passent bien la rampe sans problèmes. Donc pour moi, un fichier utilisé à la fois sur Excel et d'autres solutions se résumera à un collecteur de données brut de toutes fioritures, une simple feuille de saisie, et en s'assurant, si formules il y a, qu'elles aient la même syntaxe des deux côtés.

Et donc, pour l'exploitation des données, on aura un autre fichier Excel qui sera lié à ce "conteneur de données", idéalement par Power Query qui ramènera les données dans le classeur de traitement sous forme... d'un tableau structuré. Et même si on y ramène les données par VBA, ce sera bien entendu pour les injecter dans un tableau structuré.

[Alex020181]

Dans « txtCode » je souhaiterais l’equivalent : ‘=CONCATENER(GAUCHE(I150;2);GAUCHE(J150;2);S150;L150)
Concaténation des 2 premiers caractères de « txtNom », es 2 premiers caractères de « txtPrenom », txtINSEE et txtDoublons

Dans les cellules pour concaténer plusieurs cellules tu peux utiliser cette syntaxe plutôt que la fonction "concatener".

Code formule :

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

=GAUCHE(I150;2)&GAUCHE(J150;2)&S150&L150

Le résultat est le même mais c'est plus lisible (à mon avis).

Et pour concaténer les valeurs de différentes zones de ton formulaire c'est le même principe

Code VBA :

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

txtCode = Left(txtNom, 2) & Left(txtPrenom, 2) & txtINSEE & txtDoublons

Bien sûr cette ligne de code est à placer après avoir rempli les zones dont elle dépend.

[Alex020181]

Je t'ai créé en PJ un exemple basé sur ton fichier initial de 2 formulaires dépendants.

Le premier formulaire reprend la liste des adhérents (boutons "précédent" et "suivant" pour naviguer) et le second reprend exclusivement les parcelles de l'adhérent choisi dans le premier (boutons "précédent" et "suivant" pour naviguer).

Si l'adhérent affiché n'a pas de parcelles le bouton d'affichage du second formulaire est verrouillé.

Je me suis uniquement intéressé à l'interdépendance entre les 2 formulaires; ils ne permettent pas d'ajouter des données. Je ne les ai pas prévu pour. Ils servent uniquement d'exemple pour que tu puisses voir comment ça fonctionne et le faire sur ton fichier.

A toi de mettre en pratique pour ton fichier précis.

Teste et dis-nous.

[Pierre Fauconnier]

En 25 ans de métier, j'ai évidemment déjà entendu toutes tes objections. Je les balaie toutes car aucune ne tient la route.

On est pas responsable de la forme des données que l'on reçoit, mais on est responsable de ce que l'on en fait. Si je récupère des données d'une feuille protégée, mal formées, mal organisés, etc, je crée un peu de code pour copier les données sur une feuille non protégée en les remettant d'équerre puis je travaille avec les outils d'Excel qui, sur les versions actuelles, sont tous prévus pour les tableaux structurés comme "zone de stockage" de l'info. Souvent, ça permet de limiter le VBA à cette remise d'aplomb, alors que travailler sur des données mal conçues amène à créer des formules tordues bourrées d'exception et qu'il faut souvent créer du code VBA pour réaliser ce qu'Excel permet nativement sur base de données bien construites.

Tu connais un fichier lourd et qui plantait, était lourd à l'ouverture, etc? Wouah. As-tu analysé les causes de ces lenteurs et lourdeurs? As-tu pu isolé ce qui expliquait ces problèmes? Moi aussi tu sais, j'en connais et j'en ai vu passé, mais ils étaient souvent, voire toujours, mal conçus. En les remettant d'équerre, ils perdaient en poids et gagnaient en vitesse. J'ai une fois dit à un client/ami qui se plaignait de la lenteur de son fichier à l'ouverture que vu le temps qu'il passait à la machine à café, il n'avait qu'à ouvrir son fichier avant d'aller chercher son kawa. Je ne l'ai plus jamais entendu parler de lenteur sur un fichier Excel, depuis.

On accuse souvent Power Query de lenteur, avant de se rendre compte que en Power Query, on a aussi plusieurs chemins dont certains sont plus lents que d'autres, que lorsque les données en amont sont sur un serveur, la lenteur peut venir de la connexion bien plus que de Power Query, etc. Je termine un travail actuellement pour un tableau de bord qui va récupérer 7 millions de lignes dans une compta assemblées en SQL avec plein de jointures dans tous les sens. C'était très lent et attribué à Power Query. On a sauvegardé l'historique jusqu'à fin 2019 dans une table à plat en SQL, qu'on merge avec Power Query sur la compta depuis 2020 et c'est devenu instantané. Mais au départ, on a incriminé Power Query. Les problèmes de lenteur, ç'est presque toujours un problème de conception et d'étude du cas. On y revient toujours, à la conception. Qui pourrait soutenir qu'on va créer un building sur des fondations que l'on sait mauvaises au prétexte que comme elles ont déjà été faites, on ne va pas les détruire pour recommencer du plus solide? Pourquoi soutenir pour un développement ce que tu ne soutiendrais pas s'il s'agissait des fondations de ta maison? Ca n'a pas de sens.

Renommer un tableau ou une colonne fera planter le code? Oui, c'est vrai, sauf que l'on peut tester l'existence de la colonne ou du tableau avant et dérouter le code en cas de problème. Ca a toujours été le cas en informatique. Tu développes du vba pour Access. Te sais donc qu'une requête select NomDuChamp1, NomDuChamp2... from MaTable utilise les noms des champs plutôt que leur index. Pourquoi? Parce que l'on renomme rarement une table et ses colonnes, et que cela permet de ne pas se tracasser de l'ordre des colonnes. Et tu sais aussi que si tu renommes la table ou ses champs, ta requête SQL plantera. Utilises-tu la place des champs plutôt que leur nom dans tes requêtes? Non. Pourquoi le ferais-tu en Excel? Tu renommes ta table et tes champs tous les matins? Non, pourquoi le ferais-tu en Excel. C'est pareil en Excel. Si dès le départ on nomme correctement les tableaux et les colonnes, on ne va pas s'amuser chaque matin à les renommer. On en ajoutera, parfois on en insèrera, on en supprimera très rarement et on ne les renommera normalement jamais.

Pour moi, il ne s'agit pas ici "d'habitudes de programmeur", il s'agit de "bonnes techniques" à mettre en place avec les outils actuels. Personne, je suppose, ne soutiendrait qu'il est bien de "programmer" avec les macros XL4 qui pourtant étaient la norme il y a très longtemps. Soutenir qu'on peut développer avec les macros XL4 au prétexte d'une "habitude de développeur" ne tiendrait pas du tout la route. Pour moi, soutenir que "par habitude" de programmeur, on va programmer sur des plages classiques plutôt que sur des tableaux structurés, ça ne tient pas la route et c'est indéfendable. Que certains cas très spécifiques et très rares justifient de se passer des tableaux structurés au profit des plages classiques (en VBA comme en Excel) n'en fait pas une norme de programmation. Dans le cas vu ici, aucun argument technique ne peut justifier que l'on n'utilise pas les tableaux structurés qui, en Excel comme en VBA, amènent de la fiabilité, de la stabilité au classeur tout en facilitant la maintenance et l'évolution du classeur ou de la solution mise en place. Quel professionnel pourra justifier de l'utilisation de pratiques obsolètes au titre qu'il a l'habitude de programmer ainsi?

Pour ce qui concerne tes "arguments" pédagogiques et didactiques, ne connaissant pas ton expérience de formateur ni les formations que tu as en pédagogie et en didactique, je vais en rester là, ne sachant pas sur quelles "vérités" tu t'appuies pour énoncer tes propos. Mais ta position sur le sujet étant à l'opposé de la mienne, nos vues, sur ce point comme sur les autres, sont difficilement conciliables

[Patrice740]

Bonjour Pierre,

... Que certains cas très spécifiques et très rares justifient de se passer des tableaux structurés ...

Je suis entierement d'accord sur le fait qu'il faut exploiter au maximum les fonctionnalités natives du tableur.
Et aussi sur le fait que pédagogiquement, il ne faut jamais enseigner de mauvaises pratiques.

Mais il y a un cas, spécifique je le concède, mais ni très rare, ni très spécifique, où on doit (malheureusement) se passer des TS :
celui où le fichier doit fonctionner aussi bien avec Excel qu'avec Libre Office.
Même certaines administrations ont choisi Libre Office et doivent communiquer avec des utilisateurs de MSO.

[Pierre Fauconnier]

Salut.

Je ne sais pas ce que vous entendez par "double affectation", car en VBA, ça n'existe pas.

La ligne ActiveCell.Offset(0, 5).Value = txtDenomination = "" ne crée pas une "double affectation", mais affecte à Activecell.offsert(0,5).value le résultat de l'évaluation txtdenomination = "" => VRAI ou FAUX (d'où l'apparition du FAUX dans la cellule)

C'est un fonctionnement identique en Excel: le premier = sert à l'affectation à la cellule, les suivants servent à l'évaluation booléenne:

[Pierre Fauconnier]

J'ai proposé une contribution qui modélise les échanges entre tableau structuré et userform. Peut-être pourrais-tu t'en inspirer.

[Alex020181]

@Pierre

affecte à Activecell.offsert(0,5).value le résultat de l'évaluation txtdenomination = ""

Oui c'est ça. Je ne savais pas trop comment appeler ce traitement.

J'avais appelé ça une double affectation car je pensais à la lecture de
ActiveCell.Offset(0, 5).Value = txtDenomination = ""
qu'il voulait en une seule ligne:
- imputer la valeur de txtdenomination dans la cellule
ET
- imputer la valeur "" dans txtdenomination

C'est pour ça que je lui ai répondu 30/01/2021, 22h22 que cela était impossible et qu'il devait le faire en 2 étapes.

[Alex020181]

Dans ma BDD tu as une feuille Codes_champs
Peut on utiliser plusieurs fois ces variables dans 2 formulaires !

Oui bien sûr. Dans ton code ou même dans le rowsource de plusieurs objets tu peux appeler les mêmes cellules.

Rien ne t'empêche de définir 5 listes sur ton formulaire, et même sur plusieurs formulaires et de définir leur rowsource sur le même ensemble de cellules. Idem dans le code; tu peux appeler plusieurs fois cet ensemble de cellule.

As-tu regardé le fichier exemple "gestion_parcelles.xlsm" que je t'ai déposer Hier, 02h54 ?
As-tu compris comment j'ai fait ? (c'est une des méthodes. Chaque développeur a ses habitudes).

[fergut]

Bonjour et merci pour vos réponses

Principe de BDD que je souhaiterais :
En début d’année je dispose de ma base de données mise à jour au 31 décembre de l’année précédente, d’environ 400 adhérents. « Base de donnees »
En début d’année également, au fur et à mesure de la réception des cotisations je renouvèle ou crée la fiche de l’adhérent.
-Création : A l’aide du formulaire « saisie » pour les données de l’adhérent et du formulaire « frmsaisie_PF » pour toutes ces parcelles.
-Renouvèlement : À partir du code adhèrent j’appelle sa fiche la modifie ou la complété si nécessaire (deux formulaires)
Ces deux saisies d’enregistrements sont enregistrées pour créer la « BDD en cours ».
Au 31 décembre en fin d’année, je copie et remplace les enregistrements de la « BDD en cours » sur « Base de donnees » disponible pour l’année suivante.
La « Base de donnees » comprend donc les fiches renouvelées ,les créées ainsi que les non renouvelés « certains adhérents sautes quelquefois un renouvèlement ».
Un adhérent peut avoir plusieurs parcelles, mais une parcelle ne peut appartenir qu’à un seul propriétaire
Parallèlement au « rfmsaisie » avec le « frmsaisie_PF » je renseigne toutes les différentes parcelles de l’adhérent 1ère partie je rappelle des données de l’adhérent en 2ème partie je renseigne toutes ses différentes parcelles pour alimenter « Donnes foret »
Cette saisie je souhaite qu’elle soit liée à la saisie de l’adhérent, mais je ne sais comment de faire pour créer une relation un à plusieurs, une liaison éviterait de renseigner la 1ère partie.
Je joins ma BDD qui correspond un peu mieux à ce que je souhaite
L’instruction suivante ne fonctionne pas de même que le bouton Ajout de btnAjout_PF alors que btnAjout fonctionne normalement.

Code :

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

1
2
3
4
' concatène pour code_
Private Sub txtCode_Change()
    TxtCode = Left(txtNom, 2) & Left(txtPrenom, 2) & txtINSEE & txtDoublons
End Sub

Merci de bien vouloir me donner votre avis sur le schéma que je vous présente
Et de me renseigner sur les sur les modifications à apporter en tenant compte si possible de mes possibilités, j’ai construit cette BDD à l’aide des tutos de learnaccess sur youtube mais je ne maitrise pas le VBA.
Dans un 2ème temps je reviendrais sur le contenu des formulaires.
Merci à tous pour votre participation.

https://fromsmash.com/yiX1ky-X-w-ct

[Alex020181]

L’instruction suivante ne fonctionne pas de même que le bouton Ajout de btnAjout_PF alors que btnAjout fonctionne normalement.
' concatène pour code_
Private Sub txtCode_Change()
TxtCode = Left(txtNom, 2) & Left(txtPrenom, 2) & txtINSEE & txtDoublons
End Sub

Ce code fonctionne parfaitement mais est mal placé.

Tel qu'il est actuellement il faut d'abord compléter le nom, le prénom, l'INSEE et le doublon. Ensuite, comme tu as mis le code sur "Private Sub txtCode_Change()" il s'exécutera uniquement lors d'une modification du champ txtcode. Autrement dit tu dois ensuite saisir n'importe quel caractère dans txtcode pour que sa valeur se mette à jour.

Pour que le champ txtcode se mette à jour lors de la saisie du nom ou du prénom ou de l'INSEE ou du doublon tu dois le mettre non pas dans "Private Sub txtCode_Change()" mais dans "Private Sub txtNom_Change()" et "Private Sub txtPrenom_Change()" et "Private Sub txtINSEE_Change()" et "Private Sub txtDoublons_Change()".
Pour éviter de dupliquer ce code partout il serait préférable d'utiliser l'appel d'une fonction mais dans un premier temps si tu ne sais pas faire une fonction tu peux dupliquer ce code.

[Pierre Fauconnier]

A chacun sa vision des choses.

Je ne serai jamais partisan d'apprendre d'abord les techniques obsolètes à un débutant puis de lui montrer les méthodes actuelles qui simplifient et surtout sécurisent le code. Surtout qu'il n'est pas plus difficile de coder sur base des tableaux structurés que sur base des plages classiques, et qu'il est bien plus sécurisant de travailler avec les références structurées, pour les raisons déjà évoquées antérieurement dans cette discussion.

Je pense que je n'aurais jamais donné +/- 1500 journées de formation si j'avais appris les mauvaises techniques à des débutants. Ils auraient vite fui mes salles de cours. Je me pose toujours la question de savoir à quel moment dire à un débutant qu'il a appris des mauvaises techniques et que maintenant il est "assez grand" pour apprendre les bonnes. Si on ne lui donne pas les bonnes de suite, quand lui donnera-t-on? Plus tard lorsqu'il aura acquis de mauvaises habitudes et qu'il construira une usine à gaz qui fuit de toutes parts? Ca n'a pour moi aucun sens, un raisonnement pareil. Et cela n'a aucun sens, en 2021, de travailler ce genre de besoins sans tableaux structurés. Je continuerai en tous cas à insister sur les bonnes pratiques lorsque je verrai que l'on préconise les mauvaises.

Dans le code que tu donnes, tu utilises le nom de l'onglet pour pointer vers la feuille. Si cet onglet est renommé, on a aussi un problème de devoir modifier le code sur chaque ligne. Il serait intéressant, a minima, d'utiliser au moins une variable de type Worksheet.

Code :

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

1
2
3
4
5
6
7
  Dim sh As Worksheet
 
  Set sh = Sheets("BDD en cours")
  With frmsaisie
    sh.Range("A" & ligne_cours) = frmsaisie.txtID
    sh.Range("B" & ligne_cours) = frmsaisie.txtCot_UFP38
  End With

Il serait encore plus intéressant d'utiliser le codename de la feuille pour éviter les problèmes => billet de Philippe Tulliez qui n'offre aucune difficulté de mise en place. Et pour se détacher (presque) totalement de ces contraintes de parentalité, on utilise les tableaux structurés.

Les lecteurs de cette discussion, présents et à venir, se feront leur propre opinion

[Philippe Tulliez]

Bonjour,
Je partage entièrement ce que Pierre à écrit à propos de ce que l'on enseigne.
Il y a des formateurs qui lors d'une formation VBA pour débutant n'enseigne que le Select et Selection. Je trouve cela débile

Dès la première procédure faite à l'aide de l'enregistreur de macro, je montre tout ce qu'il faut enlever et pourquoi et j'explique très rapidement l'usage des variables objets.

Quelle que soit le type de formation que l'on dispense, il me semble important que l'on enseigne immédiatement les bonnes pratiques, à utiliser les bons outils et surtout les plus récents.