Récupérer et utiliser le texte d'une combox

Merci pour votre aide.

Le "code" ne servira plus à rien et pourra donc être supprimé. Mais j'espère qu'il sera tout de même possible de repérer la première ligne vide de chaque feuille des machine afin d'y mettre la saisie.

Cordialement.

Aucun problème pour la ligne d'insertion... je retrouve le fichier et je vois ça...

Re,

Voilà ! Il ne reste plus grand chose : l'Initialize dont la seule fonction était de calculer le Code, disparaît donc, la proc. de validation se simplifie... Ce qui te permet de voir le schéma de validation "pur" sans autre élément...

La validation consiste à transférer les valeurs saisies dans la feuille, ce qui implique de définir la ligne d'insertion :

• on la définit ici (de la façon dont tu le faisais antérieurement dans l'un des cas) par ...End(xlUp).Row + 1 qui est une manière très classique d'opérer...
• il y en a d'autres : boucle pour aller chercher la ligne vide (qu'il me semble que tu avais aussi utiliser), Find (que je ne préconiserais pas...
• il y a également l'utilisation de noms de plage dynamique : en nommant ton tableau avec un nom dynamique (ou la 1re colonne du tableau qui suffit en général) ta première ligne vide se définit par : [NomPlage].Rows.Count + 1, ligne définie dans le tableau et non plus dans la feuille, tu adresses alors dans le tableau : [NomPlage].Cells(Lig, 1).Resize(, 7).Value =... sans plus avoir besoin de référence à la feuille, car le nom se suffit comme adressage unique sans ambiguïté (et l'utilisation de With te dispense de répéter le nom plusieurs fois)
• tu seras dans le même cas avec l'utilisation d'un tableau Excel, en utilisant le nom mis automatiquement par Excel (qqui couvre la plage donnée du tableau : la ligne définie avec +1 sera la 1re ligne sous le tableau et lors de l'affectation Excel incluera automatiquement cette ligne dans le tableau...

Autre aspect : tu pouvais affecter cellule par cellule comme tu le faisais, ce qui produit une énumération devenant vite fastidieuse et un code plus long que nécessaire, avec une boucle, il y a moyen d'améliorer un peu la chose, et l'affectation préalable à un tableau (tel que c'est fait ici) améliore encore, tu sers ton tableau et tu affectes le tableau en une fois à la ligne d'insertion, les interactions avec Excel sont réduites au minimum et l'exécution n'en sera que plus rapide.

A ce stade, ton programme reste tout de même squelettique ! L'intérêt d'un formulaire est notamment de fiabiliser la saisie, soit de vérifier au moment de la saisie qu'elle conforme : que la date peut être effectivement interprétée comme date, que n° de tél. et code postal correspondent aux normes... ce qui se fait le plus souvent sur la proc. AfterUpdate ou BeforeUpdate du contrôle (lorsque l'utilisateur valide sa saisie en passant au contrôle suivant). Egalement pour des mises en forme automatiques (nom et commune en majuscules par exemple), ce qui s'opère normalement sur la proc. Change du contrôle.

Et avant validation, il convient de t'assurer que tous les champs obligatoires ont été saisis.

Un autre volet est l'extension de l'usage Ajout du formulaire à un usage Modification (impliquant recherche en vue de modifier) ou Suppression. Ce qui demeure assez facile : pas de problème pour la suppression (on supprime la ligne), et pour la modification, la validation sera identique à un ajout, sauf la ligne d'insertion (on aura récupéré la ligne lors de la recherche... et l'on peut opérer automatiquement : si on a la ligne c'est une modification et on insère sur cette ligne, si on ne l'a pas c'est un ajout et on insère à la fin).

Ces indications pour te donner quelques pistes visant à toujours aller au plus simple, qui sera le plus sûr et le plus efficace...

Après tu as les développements liés à l'utilisation de tes données, c'est déjà un autre sujet...

Cordialement.

Merci de m'avoir accordé de votre temps. Il est vrai que ce projet reste très basique. Maintenant que cette commande fonctionne je vais essayer de l'agrémenter. Vous parliez de pouvoir supprimer une ligne dans le tableau, il en était question quand j'ai réfléchi au projet. Pourrais-je le faire avec une fonction "si" dans le "private sub" de mon bouton valider?

Bonsoir,

La suppression est relativement annexe. Il est préférable de la coupler avec la modification dans la mesure où pour l'un comme pour l'autre il y a une phase recherche préalable. Et grouper Ajout, Modification, Suppression offre un ensemble de procédures homogènes.

On peut se dispenser de dissocier Ajout et Modification au niveau validation. Il est par contre toujours préférable (c'est une opération plus définitive !) d'avoir un bouton dédié à la Suppression.

Voir dans le fichier, un peu étoffé pour intégrer Modif et Suppression, avec donc un dispositif de recherche.

Modifications apportées au Userform :

• Une ComboBox de recherche par Nom [cbxRechNom], désactivée au démarrage.
• Un bouton Suppression [bt3], également désactivé au démarrage.
• Une variable module : Lig [Long] destinée à recueillir le numéro de ligne de l'élément sélectionné par recherche.

- Le formulaire s'ouvre donc de fait en mode Ajout (il ne peut y avoir recherche qu'après sélection d'une machine) : lorsqu'une machine est sélectionnée, une proc. ComboBox1_Change intervient, elle réinitialise les contrôles dans tous les cas (proc. RéinitCtrl, j'y reviendrai) et si une sélection est faite, lance une proc. InitRech qui va initialiser le dispositif de recherche (elle récupère les valeurs de la colonne Nom sur la feuille-machine et les affecte comme liste de la Combo de recherche qu'elle active alors).

Le dispositif est diversifié pour prendre en compte les différents cas : s'il n'y a pas d'enregistrement dans la feuille, elle ne mettra rien et n'activera pas la Combo (rien à chercher), si plusieurs noms, on aura recueilli un tableau des noms et on l'affecte au moyen de la propriété List, si un seul nom (on aura recueilli le nom mais pas un tableau) on l'affecte avec AddItem (List ne peut être utilisé pour un seul élément).

- Si on utilise la Combo recherche pour une recherche par nom, une sélection dans la liste de la Combo déclenchera une proc. cbxRechNom_Change, laquelle affectera le numéro de ligne à la variable Lig (qui le conserve) et va chercher les valeurs sur la ligne de la feuille pour les affecter aux TextBox, le bouton Supprimer est activé, et le fond de la Combo se colore en rose soutenu, ce qui indiquera que l'élément affiché est un élément existant, que l'on peut donc modifier ou supprimer...

Si on efface la Combo (plus de sélection), les contrôles sont réinitialisés, la variable Lig est ramenée à 0, le fond est repassé en blanc et le bouton Supprimer est désactivé.

- La proc. RéinitCtrl dispose d'un argument optionnel booléen : lancée sans argument (c'est le cas ci-dessus) elle se contente d'effacer les TextBox, avec l'argument à la valeur True (c'est le cas lors du lancement par ComboBox1_Change, elle désactive aussi la Combo de recherche et élimine sa liste, et ramène Lig à 0 et désactive le bouton Supprimer.

Si l'on n'a pas sélectionné de machine (effacement de la Combo1) on se retrouvera donc dans le même état qu'à l'ouverture, si une machine a été sélectionnée, la Combo recherche pourra être réactivée avec une nouvelle liste (s'il y a lieu)...

- La proc. de validation a été aménagée pour opérer l'Ajout ou la Modification.

Elle a aussi été un peu étoffée : elle a été asservie à ce que tous lex TextBox soient servis, sinon on demande à l'utilisateur de compléter. C'était un peu nécessaire car sans cela, tu pouvais fort bien valider des lignes vides (seul le champ Machine aurait été servi), ce qui aurait entraîné des anomalies, même pour des tests sommaires...

La validation étant acquise, la proc. teste la variable Lig : si celle-ci est >0 (Modif.), elle demande à l'utilisateur de confirmer la modification, si elle est =0 (Ajout), elle calcule la ligne et l'affecte à la variable. Suit l'affectation, qui se déroule dans les mêmes conditions, et un message de confirmation.

- L'action sur Supprimer suit un déroulement analogue, message de demande de confirmation à l'utilisateur, suppression de la ligne (connue), message de confirmation de l'opération.

Il y a bien sûr quantités d'autres méthodes utilisables... Je conseille toutefois de commencer par des éléments simples et veiller à bien les comprendre et les maîtriser avant de passer à des éléments plus complexes, si tu veux effectivement avancer et ne pas passer l'essentiel de ton temps à chercher une assistance sur le Forum, dont l'utilité sera très relative si tu n'as pas la maîtrise des éléments que tu utilises déjà, cela ne fera qu'ajouter quantité d'éléments nouveaux pour toi, que tu auras au bout du compte plus de mal à intégrer si tu ne consolides pas une base couche par couche...

N'hésite pas par contre, à venir demander des explications relatives aux éléments sur lesquels tu travailles pour te permettre de mieux appréhender ce que tu fais...

Cordialement.

Bonjour,

Oui ce n'est pas une bonne méthode que de demander de l'aide sur le forum sans arrêt mais il fallait absolument que je termine ce projet. Je pense que je peux largement mettre un "résolu", je vais maintenant me plonger dans vos lignes de code afin de bien les comprendre.

Merci de m'avoir accordé de votre temps.

Cordialement.

Rémy.

Bonjour,

Bonne continuation...

Un dernier conseil que j'avais laissé de côté : indenter systématiquement ton code, il en sera plus facilement lisible, et dans des proportions considérables. Egalement dans ce type de modules laisser VBA placer les procédures d'évènements, à l'usage on s'y retrouve beaucoup plus vite et ce n'est pas négligeable, et placer les procédure non évènementielles, que l'on est amené à rajouter, en tête de module (zone répertoriée comme (Général) dans la liste déroulante de gauche), après les déclarations de niveau module.

Tu as pu par ailleurs remarquer que toute instruction de retour à l'Accueil a disparue du code... Tu ne quittes jamais cette feuille, ce qui n'empêche pas VBA d'opérer, au contraire...

Cordialement.