Si valeur ComboBox existante ne remplir certaines valeurs

Question

Dans un UserForm nommé commande j’ai une ComboBox_nom , une ComboBox_reference , une TextBox_designation et une TextBox_date. Avec la valeur de la ComboBox_nom j’active la feuille qui à ce nom , je met la valeur de la ComboBox_reference dans la cellule A3 , la valeur de la TextBox_designation dans la cellule B3 et la valeur de la TextBox_date dans la cellule C3 et passe à la ligne suivante à chaque entrée de nouvelle référence. Je souhaiterai lors de la saisie d’une valeur existante dans la colonne reference (A) dans la feuille active ne rentrer que la date dans la première cellule vide de la ligne de cette référence. Merci pour votre aide...

U. Milité · Answer

On ne peut répondre que de manière assez imprécise à ta question, si on ne dispose pas d'un fichier (sans données confidentielles) pour illustrer ta demande. Regarde du côté de la méthode Range.Find ou de la WorksheetFunction.Match qui permettront, si la donnée existe déjà, de trouver sa position en colonne A ... pour le reste, tout dépend de la structure de tes données, du code présent dans ton UserForm, etc...

MFerrand · Answer

Pourquoi faire ? Tu trouves que VBA va trop vite ! Pour le reste même avis qu'U.Milité &#91;Salut !&#93...

MFerrand · Answer

Deux remarques rapides : Il faut mettre la propriété Locked de ta TextBox designation à True, pour qu'on ne puisse saisir. Lors de l'affectation d'une date à partir d'une TextBox, il faut toujours convertir en date (utiliser CDate). Pour ta question il faut opérer une recherche sur la feuille pour détecter si le produit y existe déjà... Il y a pas mal de choses à revoir et je n'ai pas le temps dans l'immédiat. On verra donc dans la soirée (si personne ne s'y est attelé !) Cordialement...

MFerrand · Answer

Je voudrais savoir pourquoi la colonne C sur clients est vide, et pourquoi une cellule fusionnée dans l'en-tête (B et C) ?

C'est à proscrire.

Cette colonne par ailleurs représente un champ, qui doit soit exister (et donc être pris en charge dans les Userforms), soit disparaître.

Nb- Si j'interviens, je commence par un nettoyage, car on ne peut faire un travail rationnel sans...

MFerrand · Answer

J'ai commencé par le premier Userform pour suivre la logique d'insertion de données. Tu avais un fort risque d'erreur si, lors d'un ajout, tu ne procédais pas dans l'ordre : mise en place feuille client, puis ajout dans la base de données, car lors de l'ajout dans la base tu réinitialisais les contrôles et n'aurais donc plus disposé de leur valeur pour la feuille. J'ai donc couplé ces deux volets... Un bouton devient donc inutile, ou disponible ! car tu n'as pas prévu de procédure de modification. On peut intégrer une procédure de modification dans le même Userform (changements d'infos client, rectifications d'erreurs...). Fais-moi savoir si tu le juges utile... Même chose le cas échéant pour le suppression, si le cas doit se produire. Cordialement...

MFerrand · Answer

On s'est occupé du Userform non concerné par ta question ! Avant de passer à la question initiale, je te repasse le fichier, que tu puisses opérer la reprise en main des modifications... Je pense qu'il reste des choses à voir encore, elles devraient pouvoir s'intégrer sans trop de mal. Pour bien cerner la démarche, quelques explications préalables... Utilisation de nom : J'ai nommé la première colonne de ta base de données Clients, avec un nom dynamique qui s'adaptera aux variations. Un nom dynamique s'obtient avec une formule utilisant la fonction DECALER appliquée à une cellule fixe (la première cellule de la plage nommée) et en dimensionnant le nombre de lignes à partir du nombre de valeurs contenues dans une colonne dont on sait qu'elle sera toujours remplie (éventuellement on dimensionne de façon analogue le nombre de colonnes, mais ce n'est pas le cas ici). A voir dans le Gestionnaire de noms. La plage commence à A2. Le nombre de lignes est défini sur la colonne B (car la colonne A &#91;Civilité&#93; sera peut-être amenée à accueillir d'autres valeurs que M et Mme et si tu as des clients autres que des personnes physiques, il ne peut être exclu que ce champ puisse éventuellement être laissé vide, alors que le Nom &#91;en B&#93; est indispensable pour définir un client... On n'a pas ajusté le nombre de lignes en réduisant de 1 pour tenir compte de l'en-tête non incluse dans la plage. Le nom inclus donc une cellule vide en fin de plage. Cela a l'avantage que la plage demeure définie si aucune donnée ne figure encore (on peut donc démarrer avec une base vide ne contenant que les en-têtes), que cette ligne vide sera naturellement celle à utiliser pour l'insertion d'un nouveau client, et elle est en permanence définie par le nombre de lignes de la plage (.Rows.Count) qui nous fournira l'index de ligne par rapport à la plage. De même, une seule colonne est nommée, mais c'est largement suffisant pour atteindre n'importe quelle partie de ta base, de façon souple, par décalage et redimensionnement (en utilisant .Offset et .Resize). Tu pourras le constater à l'usage. Un nom se suffisant à lui-même pour atteindre la plage visée, on peut se dispenser définitivement de passer par la feuille pour l'atteindre. Noms des contrôles : &#91;Procédant à des renommages, j'essaie toujours de faire plus court que les noms génériques d'origine... car on est amené à les écrire en général plusieurs fois... &#93; Il est certain qu'un nom long explicite t'indiquera directement ce que tu y places, mais tu le sais avec les étiquettes indiquant déjà la nature des données à saisir, et dans la mesure où l'opération implique une correspondance entre TextBox de saisie et champs de la base, établir une correspondance entre numéros d'ordre des contrôles et colonnes de la base facilitera l'utilisation de boucles, propre à réduire le volume de code à écrire. Sauf cas particulier, j'utilise un identifiant du type de contrôle (VBA classera leurs procédures de façon groupée...), suivi d'un nom générique et d'un numéro d'ordre. Au cas particulier : tbCli1 à tbCli9, en correspondance avec les colonnes 2 à 10 de la base. La colonne 1 déroge, elle concernée par les OptionButton, baptisés opbCiv1 et 2 (1 pour M et 2 pour Mme, en corresp. avec les codes Sécurité Sociale ! ). Mais il est fort possible que tu soies amené à en ajouter... On les parcourt ainsi aussi en boucle jusqu'à trouver celui qui à la valeur True (un seul peut l'avoir). NB- Pour l'affectation lors de l'ajout d'un nouveau client, on servira un tableau d'indice 0 à 9 (0 pour la civilité, 1 à 9 pour les valeurs des tbCli1 à 9), et on affectera ce tableau à la ligne d'insertion (la dernière de la plage) redimensionnée à 10 colonnes, en une seule fois, donc plus rapide que l'affectation cellule par cellule... Les boutons sont nommés cbFerme, cbAjout, cbModif et cbSuppr... Une ComboBox est également ajoutée : cbxRech pour la recherche, préalable à modification ou suppression. J'oubliais, les étiquettes, impliquées par un changement de couleur de police lors de vérification de la saisie sont rebaptisées dans les mêmes conditions que les TextBox : lbCli1 à lbCli9. Fonctionnement du Userform : Le Userform s'ouvre en mode Ajout : les boutons Modifier et Supprimer sont inactifs. On sert donc dans ce cas les divers champs... Si on utilise la Combo pour afficher un client existant, lors de la sélection dans la Combo, les TextBox sont servis automatiquement, le bouton Ajouter devient inactif et les boutons Modifier et Supprimer deviennent actifs, la couleur de fond de la Combo passe en jaune (pour attirer l'attention...) On peut donc soit modifier, soit supprimer. Si on efface la valeur de la Combo : le fond de celle-ci redevient blanc, les TextBox sont vidés et on repasse en mode Ajout... Lors de l'ouverture du Userform, la liste de la Combo est alimentée avec les noms de clients. La procédure choisie est Activate (car Initialize n'est exécutée qu'une seule fois au chargement du Userform, alors que Activate sera exécutée à chaque affichage). Ainsi lors de suppression ou ajout, ou modification (qui peut éventuellement affecter le nom client), en masquant l'Userform puis le réaffichant on provoque la mise à jour de la liste de la Combo. Ajout d'un client : Le clic sur Ajouter déclenche une fonction VérifSaisie qui renverra True ou False selon que la saisie est complète ou non. Cette fonction opère la vérification et sert simultanément un tableau (déjà évoqué) déclaré en variable au niveau module (donc accessible aux autres proc. du module). La coloration en rouge des étiquettes des champs non servis est assurée (retour au noir si à la vérification suivante ils sont servis). Particularité pour la date (toujours !) : on convertit en date pour éviter les fameuses inversions jour/mois, mais de plus, affectant d'abord à un tableau on convertit la date à sa valeur numérique (valeur sûre !), ce qui impliquera la définition du format de cellule lors de l'affectation définitive à la feuille. Il y aura probablement des formats de données sur lesquels se pencher et éventuellement revenir : code postal, numéros de téléphone, adresse mail (rendre le lien actif ?)... La feuille client est générée à la suite : proc. ChangeNom modifiée... Modification : Le clic opère la mise à jour des infos client dans les mêmes conditions qu'un ajout, sauf que la ligne est celle correspondant au client sélectionné dans la Combo, la feuille n'est pas générée, mais mise à jour s'il y a lieu et son nom changé le cas échéant. Supression : Une confirmation est demandée. La ligne de la base est supprimée. Pour la feuille, je n'ai provisoirement pas opté pour sa suppression au cas où tu veuilles concerner les données en archives... On ajoute la mention supprimé avec la date et on la masque... Ce n'est que provisoire, et il faudra modifier cela. A toi de voir l'économie globale de gestion clients... Il conviendrait certainement de l'archiver ailleurs si tu la conserves... Par ailleurs, l'accroissement du nombre de clients (souhaitable je pense ! ) peut conduire à un alourdissement du classeur justifiant qu'on envisage de gérer le tout autrement... Il faudra sans doute s'y pencher ultérieurement. Pour l'instant, vois l'aspect fonctionnel et signale-moi les erreurs éventuelles (je n'ai fait que quelques tests sommaires)... A suivre... Cordialement...

MFerrand · Answer

La suite ! En partie seulement, j'ai laissé pour le moment de côté la question ajoutée des rectifications des dates de commandes produits déjà enregistrées...

Comme précédemment, plage nommée sur la feuille Produit. Ajustée aux données cette fois, le nom est placé en RowSource de la Combo concernée.

La Combo Client est alimentée par proc. Initialize.

Les contrôles sont renommés. Ajout d'une ListBox où sont insérées les dates antérieures pour le produit-client sélectionné.

J'ai dû compléter les formats de tes feuilles clients (et fait aussi sur la feuille modèle) sur la zone préformatée, soit jusqu'à BL48.

Les dates n'étaient pas des dates (converties par revalidation, le format mis s'applique donc désormais). Format date choisi sur toute la zone, format texte de la première colonne généralisé (même format sur feuille Produit, s'il n'est pas mis de façon homogène les valeurs ne sont pas reconnues !)

Restera à voir la question des rectifications de dates antérieures. Un bouton est prêt pour ça mais ne fait rien pour l'instant ! Je pencherais pour basculer ces rectifications éventuelles sur un Userform annexe : à partir de la sélection Client-Produit on a les dates déjà enregistrées qui s'affichent dans une ListBox, en cliquant sur Rectifier on ouvrirait un Userform reprenant le contenu de la ListBox et on pourrait valider, modifier ou supprimer chacune des dates listées, puis valider le résultat qui serait reporté sur la feuille indépendamment des nouvelles dates... J'y réfléchis encore (et j'ai aussi quelques urgences à m'occuper...)

Cordialement.

79tguy-essai.xlsm (82.36 Ko)

MFerrand · Answer

Pas vu de difficulté à cet égard ...

MFerrand · Answer

En effet, le cas où on tombe à un client dans la base n'a pas été prévu... mais facile à rectifier : Private Sub UserForm_Activate() Dim Lst With &#91;CliCiv&#93; If .Rows.Count &lt; 2 Then Exit Sub Lst = .Offset(, 1).Resize(.Rows.Count - 1).Value End With If IsArray(Lst) Then cbxRech.List = Lst Else cbxRech.AddItem Lst End If End Sub Le premier ajout concerne le cas où la base est vide (0 clients) : pas de liste du tout. Pour le 2e, la condition permet de savoir si Lst est un tableau ou non : ne lui affectant que les valeurs d'une colonne, si la colonne se réduit à une cellule, l'affectation d'une seule valeur conduira Lst à n'être qu'une variable scalaire ordinaire... Donc si la condition est vérifiée on a un tableau (plusieurs clients) et on l'affecte au moyen de List, sinon on n'a qu'un seul client (qui ne peut alors être affecté par List) et on affecte par AddItem. Cordialement...