Champs recherche
Bonjour à tous,
Je suis entrain de créer un petit fichier afin de pouvoir faire des factures de façon simple, mais problème je bloque au niveau de la "recherche client".
J'ai créer un userform "userform1"ou j'ai un champ recherche et à coté j'aimerais que les résultats s'affichent et que en cliquant soit sur le nom ou par le biais d'un bouton les données du client c'est à dire Nom, Prénom, adresse, etc... s'exportent dans les textboxs correspondant...
Afin que quand je clique sur le bouton valider les infos s'exportent dans les cellules correspondant sur la feuille "Facture".
Merci d'avance !
Bonjour,
Un rapide examen de ton fichier montrant un code très disparate, sans doute dû à des origines diverses, me conduit à pronostiquer que l'ensemble ne relevant d'une conception homogène et bouclée aura du mal à éviter d'être une addition de recettes divers sur lesquelles ne feront que s'agglutiner des rustines au fil des besoins, d'autant que de nombreuses règles de base pour obtenir un code propre, relativement optimisé et homogène sont ignorées...
Il y a fort à faire pour épurer cette situation. Je n'envisage pas a-priori de l'entreprendre et me contenterai de quelques remarques à partir des observations faite lors d'un survol panoramique, donc forcément très incomplètes, mais tu devrais déjà considérer qu'on ne pourra faire de travail conséquent sur un fichier totalement dépourvu de données et qu'il convient d'en avoir un minimum, ne serait-ce que pour tester au fur et à mesure le code élaboré.
Remarques et conseils éventuels :
On voit en ouvrant l'éditeur pas moins de 12 modules standard ! Une bonne partie ne contient rien, donc pour une bonne tenue régulière du projet ils auraient dû être supprimé dès l'origine, ceux qui contiennent du code se limitent à une procédure par module ! A ce régime si tu insères une centaine de procédure dans ton projet, tu vas avoir 100 modules ! Alourdissement inutile et irrationnel et qui ralentira fortement tout travail de programmation...
A ce stade et compte tenu des fonctionnalités projetées telles qu'elles apparaissent, rien ne vient justifier l'introduction d'un second module Standard.
Je conseillerais donc volontiers de rassembler les procédures existantes dans un Module et supprimer les autres, en ne perdant pas de vue que dans un module on place dans l'ordre : les déclarations de niveau module, les procédures Function (il n'y en a pas encore ou je n'en ai pas vues), les procédures Sub (et on place de préférence dans chaque catégorie de proc. celles qui seront appelées le plus fréquemment avant celles qui le seront moins...)
Autre point, on élimine immédiatement tout code devenu caduc, qui constituera un élément parasite, frein à un travail raisonné.
Exemple : Feuil1 qui contient une déclaration de procédure d'évènement Change d'un TextBox1, sans code, et sans TextBox1 dans la feuille. Cela n'a pas lieu d'être !
Dans la même veine, la lecture de ton Initialize de Userform1 fait apparaître une ListBox1 que l'on cherche vainement dans le Userform. Il est tout à fait évident qu'invoquer des contrôles encore inexistant sur le formulaire est une pratique incohérente provoquant un surcroît d'erreurs que l'on peut se dispenser de provoquer ainsi.
Tu y fais aussi référence à une plage nommée ([MaBD]), nom inexistant dans le classeur... !
Dans la foulée, je conseillerai aussi de ne jamais taper directement les procédures d'évènement des contrôles mais d'utiliser les listes déroulantes : choix de l'objet à gauche, choix de l'évènement s'il y a lieu à droite (en éliminant immédiatement la déclaration de l'évènement par défaut si ce n'est point celui qu'on utilise). Cette méthode est plus sûre et évite de chercher pourquoi une procédure d'évènement ne s'exécute pas... Je conseille aussi de laisser VBA placer les procédures lui-même, plutôt que de le faire à sa place, l'expérience montre que l'on s'y retrouve mieux ensuite et plus rapidement...
Et si l'on doit introduire d'autres procédures que celles d'évènements des contrôles ou du Userform, ne pas les intercaler au sein des procédures d'évènements, ni les repousser à la fin, mais les placer en tête du module, après les déclarations de niveau module (s'il y en a) où elles ont leur place [section (Général)] (et je conseille aussi de ne pas les affubler du Private, dont l'utilité pratique est nulle, de façon à les identifier visuellement d'un coup d'oeil...)
Tu devrais également te pencher sur l'utilité qu'il y a à renommer les contrôles que l'on utilise dans le code, de façon cohérente et tenant compte de leur utilisation (par exemple au moyen de boucles...) de façon à faciliter l'écriture du code et réduire autant que faire se peut son volume.
Mais il me paraît primordial de maîtriser l'utilisation de la fenêtre de propriétés pour définir les valeurs par défaut des propriétés des contrôles, soit celles qui seront toujours présentes à l'ouverture, et dont la définition dans une procédure Initialize n'a pas lieu d'être !
Des exemples : fixer le nombre de colonnes d'une ComboBox alors qu'il demeurera fixe et le même à chaque ouverture du Userform, surtout pour le fixer à 1 qui la valeur initiale par défaut, que l'on n'a donc nul besoin de modifier, même chose pour les largeurs de colonnes d'une ListBox, on voit mal le besoin que celles soient modifiées, donc redéfinies à chaque ouverture...
Ou encore effacer le contenu des TextBox à l'ouverture : serait-ce qu'on a poussé le vice à y placer des valeurs par défaut pour le plaisir de les effacer à l'ouverture... !
Autre élément : l'ouverture d'un Userform de saisie en non modal est une hérésie, si on procède au moyen d'un Userform, c'est en priorité pour fiabiliser la saisie et éviter que l'utilisateur puisse intervenir directement dans la feuille, c'est donc tout à fait contradictoire.
Cela se conçoit pour des utilisations marginales, par exemple afficher un message non destiné à interrompre l'action de l'utilisateur... et dans ce cas la propriété peut se fixer par défaut et n'a pas lieu d'être définie lors de l'initialisation à l'ouverture.
Une dernière observation : ton tableau sur la feuille facture, vide mais qui semble devoir constituer une base de données factures... Si c'est le cas, une feuille dédiée à cette base (comme pour la base Clients) devrait s'imposer !
Toutes ces remarques ne sont pas limitatives, il y en a certainement bien d'autres à faire, et je conseille aussi d'examiner les règles d'or relatives à l'organisation de bases de données... mais cela devrait alimenter ta réflexion sur ton projet, et pour conclure n'oublie jamais que ce qui n'est pas conçu au départ, avant toute réalisation, tu ne le trouveras pas à l'arrivée ou cela génèrera des additifs le plus souvent mal intégrés...
Cordialement.
Merci d'avoir pris la peine de me répondre.
Effectivement après lecture de votre message, je me rend compte des erreurs que j'ai fait. Je vais remettre de l'ordre dans tous ça, ce qui me permettra d'y voir plus clair.
Merci pour tous les conseilles, et je vous souhaite un bon dimanche.
Bon courage à toi, et prends le temps de faire le tour des questions, sans précipitation...