Regrouper des lignes
Bonjour à tous!
Lorsque je clique sur les lignes de domaines dans mon fichier excel Feuil1 (domaine 1, domaine 2...), je souhaiterais que toutes les lignes du dessous qui correspondent au domaine s'ouvrent et se ferment comme si on utilisait la fonction "Grouper" sauf que ça ne fonctionne pas comme je le voudrais avec cette fonction donc c'est pourquoi je souhaiterais une autre solution.
Aussi, lorsque je rajoute un message, je souhaiterais que le domaine correspondant s’ouvre automatiquement à l'enregistrement pour laisser apparaitre tous les messages du domaine.
Ci-joint mon fichier.
Merci pour votre aide et pour votre temps!
Cordialement,
Bonjour,
Tel qu'est établi ton fichier tu obtiens facilement ce fonctionnement par filtrage...
Le clic n'est pas un évènement significatif, on n'a donc pas de procédure permettant de le programmer, mais on peut programmer le double-clic et le clic droit.
On peut donc utiliser le double-clic pour ouvrir et le clic droit pour fermer par exemple.
Je serais tenté d'utiliser les filtres sur ce déclenchement d'évènement mais d'une part cela réclame une petite série de tests que je n'ai pas le temps de faire pour le moment (non pas pour filtrer, mais pour récupérer à chaque fois la situation de filtrage en cours, selon qu'il y a 0, 1, 2 ou plus de critères actifs), et d'autre part si la fusion de tes lignes titres est un très bon citères d'identification, cela place la mention de domaine dans la même colonne pour les titres et les autres lignes.
Il serait donc bon d'exclure la colonne A de la fusion des lignes titres, ou toute autre disposition aboutissant à ce que le titre domaine ne soit plus dans la colonne domaine. Que l'on procède par filtrage ou par une autre méthode, cela reste nécessaire.
Il serait souhaitable aussi que ton fichier soit déjà un peu plus fourni en lignes intermédiaires. En fait il aurait été judicieux d'avoir dès le départ au moins une ligne sous la ligne de titre. Car à l'insertion de ligne, la ligne insérée prend le format de la ligne qui prècède, ce qui réduit les manipulations à opérer. Il te faut en tout cas définir la façon dont tu voudras opérer pour ajouter des lignes par domaine. Il est utile d'en construire la procédure sans attendre...
Et si d'autres déclinaisons doivent être introduites par la suite, il est bon de le savoir dès le départ...
Cordialement.
Dans le silence...
Toutefois, si tu entends te servir du filtre sur différentes colonnes, il faut réaménager en conséquence : les lignes têtes de domaines (fusionnées) ont maintenant leur mention en B, qui coincide donc avec la colonne Catégories. Si tu entends te servir du filtre manuellement, il faudrait donc insérer une colonne (à masquer) pour dissocier les mentions de ces lignes des catégories. Sinon on escamotera les flèches de filtrage.
Il y aura peut-être 2 boutons à rajouter pour tout ouvrir ou tout fermer d'un coup (si souhaité).
J'ai cru comprendre que les lignes que l'on masque ou démasque sont ce que tu appelles messages.
Ce que j'aimerais savoir, c'est si le nombre de domaines est d'ores-et-déjà arrêté définitivement, ou si d'autres pourront être introduits. Dans ce dernier cas, il faut prévoir une procédure d'introduction qui ne détruira pas les éléments de reconnaissance mis en place (nom dynamique de la colonne A).
A travers ta 2e question c'est tout ce qui concerne ton Userform qui est en cause... Déjà je n'ai pas trouvé de mise en place d'une ligne message cohérente (insertion en fin de domaine, remise au format des éléments qui ne suivent pas l'insertion...) Et il y a d'abord pas mal de ménage à faire dans ce fatras d'origines diverses... Je passe sur le code mal indenté, tout pour en compliquer la lecture... Dans un module de feuille, on laisse VBA placer lui-même les procédures évènementielles, on les retrouve d'autant plus facilement, celles qu'on ajoute, on les place en tête à la suite des déclarations (zone désignée par '(Général)' dans la liste déroulante. On se sert d'autre part autant que possible de la fenêtre de propriétés pour mettre en place les propriétés par défaut des contrôles.
J'apprécie certes le renommage des contrôles
Bref ! Il reste à savoir si le Userform ne servira qu'à ajouter des messages. S'il est par ailleurs prévu de pouvoir les modifier, ou en supprimer, et quelles dispositions sont envisagées à cet égard.
Cordialement.
La situation a pas mal évolué...
Il ne reste plus à voir pour cette "tranche" de mise en place que :
- la suppression de messages : elle peut être autonome et simplement liée à un bouton, après positionnement sur une ligne,
- la modification : sauf particularités, le même userform doit être utilisé pour modifier, il faut préciser le moment et les modalités de choix entre modification et nouveau message (au lancement, en étant positionné ou non sur un message existant, ou sur questionnement, ou après ouverture du Userform avec dispositif de choix entre les deux fonctions), de légers aménagements seront réaliser selon la solution retenue,
- la possibilité ou non d'ajouter et éventuellement supprimer des domaines : le cas échéant, une procédure est à mettre en place pour ajouter (ou supprimer) des domaines.
Bonjour,
Excusez moi pour le délai de réponse.
Merci pour votre aide.
Oui effectivement je souhaiterais pouvoir supprimer des messages ou bien les modifier une fois enregistrés. Concernant les domaines, il est vrai qu'ils peuvent changer ou bien être supprimés ou même en rajouter.
Le niveau devient vraiment complexe pour moi ^^
Je pourrais comprendre le code mais pas le faire c'est sur
Bonsoir,
Tu n'as pas disparu ! Tout va bien.
Version provisoire donc : voir s'il n'y a pas de bogue qui surgisse, et l'ergonomie...
J'ai fait pas mal de nettoyage et de modifications finalement...
A voir en particulier :
J'ai supprimé tous les noms, sauf un qui nomme en dynamique (de façon un peu particulière) la colonne A de ton tableau. Elle n'inclut pas l'en-tête, mais inclut une ligne de plus en fin qui reste blanche, est fusionnée comme les lignes "domaines" et porte la mention 'domaine8' (éviter de la détruire).
Pour le code du Userform, tu trouveras pas mal de différences avec le code initial (certaines ne sont d'ailleurs qu'apparentes).
Si tel ou tel point t'interroge, n'hésite pas à poser la question...
L'insertion de ligne est renvoyée à 2 procédures en Module1, dont une fonction qui renvoie la position de ligne pour affectation des valeurs. Les numéros de ligne ne sont pas ceux de la feuille mais la définissent à partir du nom "domaines", donc de la ligne 5 de la feuille...
J'ai évité d'utiliser "Feuil1" comme nom (risque de n'être pas durable), donc les positionnements se calculent à partir de la plage "domaines", sauf dans le module de la feuille où la feuille reste durablement identifiable.
Pour la suite : pour ce qui est des modifications, un réaménagement sera à faire pour que le Userform pourvoie pourvoie à cette fonction concurremment avec l'ajout.
Pour les suppressions, il faudrait que tu dises de quelle façon tu souhaites désigner la ligne à supprimer : on peut le faire par bouton qui lancerait une porcédure te questionnant si tu veux supprimer le message sur lequel tu te trouves, ou autrement...
Pour les domaines, je pense qu'il faut les traiter à part. Il faut d'abord savoir si l'appellation domaine suivie d'un numéro est définitive, et si les numéros sont appelés à demeurer une suite continue (ex.: on supprime le domaine 4, le domaine5 devient domaine4, etc., ou bien on insère un domaine, après le 4, il devient domaine5, le domaine5 ancien devient domaine6, etc.)
Jusqu'à présent, tout est conçu avec cette appellation "domaine", donc si elle n'est pas destinée à demeurer, il y aura beaucoup de modifications à apporter...
Un point que j'ai omis de signaler et que je n'ai pas modifié : ta procédure de recherche de noms de fichers à transformer en liens hypertexte, la recherche admet la multisélection et peut te renvoyer un tableau de noms, cependant seul le dernier sélectionné sera finalement inscrit dans la TextBox et transformé ensuite en lien. Ce n'est pas en soi gênant car de toute façon le lien est positionné dans une cellule, et tu ne pourras en avoir qu'un dans une cellule... Donc, si l'objectif était effectivement d'avoir éventuellement plusieurs liens, il faut repenser la chose.
Cordialement.
Bonjour,
Merci pour votre aide. J'ai regardé le fichier joint et effectivement je ne reconnais pas grand chose du code
Comme je vais devoir expliquer le fichier à d'autres personnes pour qu'ils puissent l'utiliser et faire des motifs (peut être via le code), je ne vais pas pouvoir leur expliquer avec ce nouveau code trop complexe pour moi.
Pouvez vous m'expliquer où est ce que je retrouve les éléments que j'ai ajouter pour alimenter dans les listbox et combobox (joué par / activation /chargement...)? Si je veux modifier ce qu'il y a dans ces listbox et combobox, où est ce?
Au niveau des domaines effectivement, ils ne seront plus nommés "domaine" mais ils auront des noms différents les uns des autres. Dans mon code précédent, je pouvais les renommer facilement. Serait il possible de modifier cela?
Par contre, le code pour fermer et ouvrir est très pratique. Merci car ça je comprends
Pour les liens hypertexte, je n'ai besoin que d'un lien hypertexte par cellule donc c'est bon.
Au niveau de la suppression, finalement je ne vais pas avoir besoin de supprimer mais plutôt de modifier. J'aimerais que lorsque l'on clique sur les cellules en colonne A (sauf ligne turquoise), qu'un useform (le même que le useform "enregistrer un message"), rempli avec les éléments enregistrés avant, apparaisse pour que l'on puisse modifier des éléments que l'on souhaite.
Aurait il un moyen de faire en sorte de copier coller le useform et changer juste le nom pour ne pas avoir a tout le refaire?
Merci encore et bonne journée!!!
Bonjour,
La modification se déroule de façon très semblable à l'ajout d'un nouvel élément :
- le même formulaire s'ouvre, sans données si nouvel élément, avec les données existantes pour modif.
- modifier ou inscrire pour la première, c'est toujours mettre une donnée de même type dans la même zone
- que l'on mette à jour la ligne ou qu'on inscrive sur une nouvelle, à la validation, c'est toujours servir une ligne de la même façon, la seule différence est que la ligne est prédéfini à la modification par la sélection de l'élément à modifier, si nouveau elle est calculée pour insérer une ligne dans le domaine concerné.
La question des noms de domaines a des incidences beaucoup plus conséquentes... Ton système était bâti sur une hiérarchie : domaine - catégorie - sous-catégorie, avec lien de dépendance entre catégorie et sous-catégorie (à chaque catég. ses sous-catég. propres, d'où liste sous-catég. dépendante du choix de la catég.). Mais pas de dépendance entre domaine et catég. (un domaine accepte toutes catég.). Mais le nom de la forme domainex a fait qu'on s'est appuyé dessus pour toutes les identifications de domaine et positionnement : on constitue la liste à l'entrée du formulaire par une boucle "domaine"+numéro d'ordre, on se repère sur le nom domaine et sur le numéro pour les distinguer, c'était ainsi avant mon intervention et j'ai prolongé en appuyant l'ouverture par double-clic là-dessus...
Le passage à des noms différents impliquera de gérer une liste, d'une part, et de modifier tous les systèmes d'identification d'autre part... Il faut faire le tour des incidences, mais la méthode la plus appropriée semble être de commencer par bâtir cette liste avec les noms actuels domainex pour pouvoir basculer les fonctionnalités progressivement sans tout bloquer, et une fois la bascule faite d'une situation à l'autre, changer les noms (ce qui ne posera plus de problème dès lors qu'on ne gère plus sur le nom "domaine"+ numéro.
Par contre, le code pour fermer et ouvrir est très pratique. Merci car ça je comprends
Si tu comprends ça, pas de raison de ne pas comprendre aussi rapidement les modifications apportées dans le formulaire, d'autant que, comme je l'ai dit, certaines ne sont qu'apparentes. Je vais y revenir en détail pour te fournir les éléments d'explications qui peuvent te manquer, et tu verras que les difficultés de compréhension vont vite s'estomper (à voir dans les posts suivants).
Bonne journée en attendant.
Un petit lot d'explications sur ce qui a changé par rapport à ton code antérieur (pour autant que mes souvenirs soient encore assez frais...).
Le formulaire s'ouvre à partir de ton bouton de commande, rien de changé jusqu'ici. Le chargement du Userform lance la procédure Initialize. Il y a quelques petites modifications de forme...
Il y avait à la fin la définition de 2 paramètres pour TextBoxMessage. Ils ne figurent plus. Ils ne sont pas supprimés, ils sont définis à partir de la fenêtre de propriétés, une fois pour toutes, sans avoir à y revenir. La TextBox aura toujours ces paramètres là à l'ouverture sans qu'il soient besoin d'y revenir dans le code.
D'une façon générale, les paramètres par défaut des contrôles doivent être définis dans la fenêtre de propriétés, c'est autant de gagné pour la suite. Seuls ceux qui ne peuvent l'être car changeant entre deux ouvertures font l'objet d'une Initialisation à l'ouverture, et évidemment ceux qu'on est amené à modifier en cours d'exécution selon les choix de l'utilisateur.
Bien concevoir : paramètres fixes => fenêtre de propriétés, paramètres variables => initialisation, paramètres dépendant de choix => en cours d'exécution.
Il faut savoir aussi que l'initialisation peut se faire d'au moins 2 façons : chargement du Userform (sans l'afficher) et passage de paramètres par la procédure appelante, de l'extérieur donc, ou procédure Initialize qui s'exécute au chargement avant affichage (une seule fois donc lors du chargement). On dispose aussi d'une procédure Activate qui, elle, s'exécute à chaque affichage (au premier après l'initialisation, et au réaffichage après chaque masquage éventuel sans l'avoir déchargé).
Dans Initialize on initialise donc les listes des ComboBox et ListBox : rien de changé à cet égard.
A savoir, sur les méthodes d'affectations de telles listes, 3 méthodes (chacune ayant des avantages et des inconvénients...) :
- AddItem : on rentre les éléments un par un dans la liste...
- List : on rentre en bloc un tableau d'éléments (le tableau doit comporter plus d'un élément, un seul provoque une erreur)
- RowSource : on indique l'adresse d'une plage source de la liste ; cela peut être fait soit dans la fenêtre de propriété, soit par le code ; à la différence des deux autres méthodes celle-ci crée un lien avec la source, une plage d'un élément est acceptée.
Ici la liste Domaine est toujours constituée par la méthode AddItem, mais j'ai utilisé une boucle au lieu d'une énumération sur 7 lignes (il faudra y revenir lors du changement de noms).
La liste Catégorie, rien de changé sauf passage par une variable.
Les autres listes : rien de changé non plus (passage par une variable pour raccourcir l'écriture), mais dans la mesure où il s'agit de listes fixes, on pourra faire référence à une liste (RowSource) et les sortir de l'initialisation (sauf peut-être Jouépar).
Jusqu'ici pas de nouveautés créant des problèmes de compréhension, juste à voir la façon dont on peut se servir de variables de type Variant pour former des tableaux temporaires... En y affectant les données d'une plage, on affecte un tableau de valeurs, en utilisant la fonction Split on découpe une chaîne en tableau en considérant un élément séparateur dans la chaîne, et on peut également y affecter un tableau au moyen de la fonction Array (suite d'éléments séparés par des virgules). Ce sont des méthodes suffisamment banalisées et répandues pour qu'il soit utile de bien les maîtriser.
On poursuit par la liste Souscatégorie, on reste dans le même domaine...
A cet égard, j'ai omis une remarque dans le précédent post : inutile de faire un .Clear préalable lors de l'initialisation, à l'ouverture c'est tout Clear !
Par contre, pour Souscatégorie, il faut effectivement la vider à tout changement de Catégorie.
Peu de changement ici aussi, mais un notable : la substitution de Change à Click.
Pour les Combo et ListBox ces deux évènements sont souvent concomitants, mais un Click peut ne pas être accompagné d'un Change et vice-versa (ce qui peut réserver des surprises). Or, c'est le changement de valeur de Catégorie qui conditionne l'autre liste, c'est donc au changement qu'il est plus sage d'intervenir...
Après, j'ai simplement déclaré tes variables (il est toujours préférable de déclarer toutes les variables), et supprimé la variable feuille sans grande utilité : pour l'écriture, on n'a à l'écrire qu'une fois en utilisant With, et l'utilisation With... End With place la référence en mémoire ce qui permet à VBA d'être plus rapide que l'utilisation continue de F (pas sensible vu le nombre, mais le code est plus optimal...)
La méthode utilisée reste la même. Le lancement de UpdateTextBox préexistant suit la constitution de la liste. Tu ne devrais pas avoir de mal à t'y retrouver.
Autre modification qui concerne les 3 TextBox lançant également UpdateTextBox, qui ne devrait pas te déstabiliser : substitution de l'évènement AfterUpdate à Change.
Un TextBox est une zone de saisie de texte, et sa procédure Change intervient à chaque changement de valeur, soit à la frappe (ou l'effacement) de chaque caractère. On l'utilise efficacement pour intervenir en cours de saisie et assister la frappe de l'utilisateur... Mais il était inutile d'intervenir ici autant de fois, une seule à la fin suffit.
AfterUpdate se produit à la validation de la saisie, Exit se produit à la sortie du contrôle (perte du focus), les deux se confondent pratiquement lorsque la validation entraine la sortie par tabulation, sinon il n'y a de fait qu'un léger décalage et les deux se produisent finalement toujours...
La procédure UpdateTextBox, je l'ai un peu allongée en passant par une variable : on constitue un tableau avec les valeurs composantes au moyen de Array, et on transforme ce tableau en chaîne avec la fonction Join qui introduit un caractère séparateur entre les éléments en en faisant une chaîne (fonction inverse de Split). Le résultat est le même. La gestion d'erreur est nécessaire car la sélection du domaine au départ alors que le reste est vide provoquerait une erreur...
Cela s'explique parce que j'avais amorcé une transformation au bout de laquelle je ne suis pas allé, qui consistait à n'affecter la chaîne que lorsque les 4 éléments la composant était saisis... Cela aurait permis par la suite de n'avoir à tester que ce TextBox pour savoir qu'il y avait une saisie non faite quelque part. J'ai conservé finalement ta série de test sur l'ensemble pour y apporter une modification didactique (on y viendra plus tard).
Finissons les manipulations intermédiaires internes au Userform avec les TextBox cliqués pour aller sélectionner un fichier.
De la même façon qu'il était judicieux précédemment de lancer une même procédure à partir de 4 composants plutôt que de la répéter 4 fois. Il en est de même pour les TextBox cliqués : ils renvoient à une même procédure, en lui passant leur nom en argument pour que celle-ci puisse affecter le résultat au bon TextBox. Une simple simplification donc.
Jusqu'ici tu ne peux pas dire que tes procédures antérieures ont été bouleversées. Les ajustements sont minimes et tu ne devrais avoir aucun mal à t'y retrouver.
Ce que j'ai fait également c'est rétablir les procédures dans l'ordre où VBA mes place automatiquement. En effet, il les place dans l'ordre alphabétique chaque fois que l'on utilise les listes déroulantes pour l'inscription automatique des déclarations (ce qu'il est préférable de faire car cela évite bien des erreurs) et l'on n'a aucun intérêt à modifier cet ordre, plutôt que s'en servir pour s'y retrouver plus vite. Les procédures annexes ajoutées aux évènements sont toujours placées en tête dans la zone générale à laquelle VBA renvoie quand on clique sur général.
Les modifications seront un peu plus sensibles sur la procédure de validation...
La procédure de validation doit comporter 3 éléments : vérification que les conditions de validation sont réunies, recherche du positionnement du message (avec insertion de ligne et sa mise en forme), affectation des données à la ligne.
Ces 3 éléments figuraient dans ta procédure (avec quelques insuffisances).
Vérifications avant validation : tu procèdes à la vérification de saisie dans 4 TextBox, ce qui indique que la saisie est obligatoire pour ces éléments, les autres ne l'étant donc pas.
J'ai bien sûr maintenu ce schéma, mais ajouté une vérification importante : si le domaine n'est pas indiqué (et comme sa sélection est indépendante il est tout à fait possible de l'oublier), la procédure va planter car le positionnement dépend du domaine.
J'ai donc ajouté cette vérification et débuté avec.
Suit la vérification des TextBox rendue plus compacte au moyen d'une boucle : un tableau des 4 parties de noms non communes des TextBox suivis des 4 fragments de message propre à chacun lorsque sa saisie est manquante est constitué dans une variable (avec Split). On n'écrit ainsi qu'une fois la procédure pour les 4.
Je n'ai donc fait là que reprendre ta procédure pour la compacter dans une boucle.
J'ai juste ajouté la prise de focus par le contrôle sur lequel on renvoie : toujours normal de faciliter la tâche de l'utilisateur dans ce cas.
Vient ensuite la détermination de la ligne d'insertion : tu procédais par recherche du domaine en colonne A (avec Find) avec insertion à la ligne suivant la première occurence trouvée. Tu tombais donc sur la ligne d'en-tête colorée du domaine et insérait en première ligne de la zone domaine. Comme j'ai sorti la mention de la colonne A pour les lignes colorées, tu serais alors tombée sur une insertion en 2e ligne de la zone domaine. Cela n'est pas forcément gênant dans la mesure où un tri sera sans doute rendu nécessaire... mais insatisfaisant, on a l'habitude d'insérer en première ou dernière ligne.
Pour ce qui est de l'insertion, ton code est tout droit issu de l'enregistreur, il y a donc lieu de le simplifier. l'argument CopyOrigin est à sa valeur par défaut, il est d'autant plus inutile de le mentionner que je n'ai jamais vu personne utiliser l'autre valeur de cet argument. En outre il y a souvent quelques points de mise en forme à retoucher tout de même.
L'enregistreur restitue aussi la passation d'arguments par arguments nommés. C'est utile dans certains cas selon le nombre quand on ne les utilise pas tous, mais il est très généralement plus facile de les passer par position et on gagne de la place, donc il n'y a pas de raison de ne pas le faire dans la grande majorité des cas.
Avant de passer à l'explication de la procédure que j'ai utilisée sur ce point, il me faut indiquer les modifications introduites dans la feuille qui ont motivé une partie des modifications de la procédure d'insertion. Je fais donc une nouvelle pause ici.
Bonne soirée.
Interruption plus longue que prévue...
Je reviens sur le nom domaines défini ainsi :
=DECALER(Feuil1!$A$5;;;NB.SI(Feuil1!$A:$B;"domaine*")-1)Toutes les lignes message en col. A portent la mention "domaine?".
Et les lignes colorées la comportent en col. B.
Le nom recouvre donc la colonne A (à partir de la ligne 5) en incluant toutes les lignes qui comportent la mention domaine? en A ou B, soit la totalité de la col. A du tableau actif + 1 (j'ai en effet ajouté une ligne portant la mention domaine en B avec le numéro de domaine suivant dans la série, sorte de ligne de fin qui pourra s'avérer utile par la suite lors des modification à apporter et qui dans l'immédiat permettait de simplifier la procédure de tri domaine par domaine, et simplifiait aussi un dispositif de recherche dans une plage définie à partir du nom domaines).
Comme le nom de feuille "Feuil1", laissé à sa valeur par défaut, m'a paru susceptible d'être changé ultérieurement, il m'a paru plus sûr d'utiliser la plage nommée dans toutes les procédures. Certes une seule colonne est nommée... mais j'ai une certaine inclination à ne nommer qu'une colonne, voire une seule cellule, car cela suffit à définir n'importe quelle plage sur une feuille, et de façon simple surtout en VBA.
Pour en revenir à la procédure de validation du formulaire, une fois les vérifications achevées, la définition de la ligne du mesage (à insérer) est définie par la ligne :
lgn = LigneInsert(ListBoxDomaine.ListIndex + 1)On appelle la fonction LigneInsert en lui passant le numéro de domaine du message pour qu'elle renvoie le numéro de la ligne à utiliser pour insérer le message.
Cette fonction LigneInsert se trouve dans Module1 (aucun besoin qu'elle soit dans le formulaire).
Elle cherche la ligne d'en-tête du domaine suivant (pour le dernier domaine, elle tombera sur la ligne de fin). Cette est celle à partir de laquelle on peut insérer une ligne en fin du domaine. Une fois insérée, cette ligne aura le numéro à partir duquel on a fait l'insertion et elle le renverra à la procédure de validation appelante.
Avant de procéder à ce renvoi, elle appelle une procédure auxiliaire InserLigne en lui communiquant ce numéro de ligne d'insertion et le numéro du domaine dans lequel se trouvera la ligne insérée.
La ligne insérée prend normalement le format de la ligne au-dessus, mais on peut avoir un domaine encore dépourvu de messages et dans ce cas ligne aurait les attributs d'une ligne colorée. Il est donc judicieux d'assurer sa remise en forme éventuelle : la décolorer, rétablir la couleur de police par défaut et centrer les valeurs dans les cellules, ainsi que rétablir les bordures internes et externes. Ceci fait, la procédure inscrit également le nom du domaine en colonne A (on n'aura plus à le faire) et active le filtrage du domaine pour qu'il soit entièrement affiché.
La mise en place de la ligne du message est donc complètement externalisée par rapport au formulaire.
Dernier volet, la ligne étant connue, il ne reste donc plus qu'à affecter les valeurs.
Le plus économique et le plus élégant est toujours d'utiliser une boucle plutôt qu'une énumération fastidieuse cellule par cellule. Ici, les noms spécifique à chaque contrôle empêchait une boucle directe, il y avait aussi un trou dans la succession des colonnes. On a donc utilisé le même système que lors de la constitution des listes pour les contrôles : un tableau de noms que l'on peut parcourir, assorti d'un second tableau des numéros de colonne d'affectation correspondant aux contrôles listés.
Pour éviter de longues listes des noms de contrôles complets, on a subdivisé l'opération en 4 boucles, selon les parties communes des noms : ListBox, ComboBox, TextBox, la 4e également TextBox mais distinguée du fait que leur valeurs étaient à transformer en liens hypertexte.
En effet, pour cette dernière série, inutile de procéder en deux temps : soit les contrôles n'ont pas de contenu, et il n'y a ni valeur à affecter ni lien à créer, soit il y a un contenu et la création du lien se combine avec l'affectation de la valeur.
Je rappelle aussi que la ligne comme les numéros de colonnes sont définis par rapport à la plage domaines, ce qui ne change rien pour les colonnes, la plage étant en A mais décale un peu pour la ligne, la ligne 1 de la plage étant la ligne 5 de la feuille.
Si l'adressage d'une plage est le plus souvent fait par rapport à la feuille, il peut aussi bien être fait par rapport à une plage : si j'écris Range("B10").Range("C3"), je pointe en fait D12.
Le temps de régler quelques autres affaires, et je mets à l'étude l'impact de modification des noms de domaine.
Cordialement.
Bonjour,
Merci pour tes explications, je vais prendre le temps d'étudier tout ça
Bonne journée!
Bonjour,
Petit rapport d'étape :
- Modalités de suppression définies : bouton...
- Modalités de modification également : (bouton) les valeurs du message à modifier sont chargées avant ouverture par la procédure appelante.
-Gestion des domaines : en cours. Un bouton appellera un Formulaire...
Les contrôles qui apparaissent en grisé sont inactifs à l'ouverture, ils sont activés selon les choix de l'utilisateur.
L'utilisateur est invité à choisir un domaine : si ensuite il opte pour ajouter, son choix n'a aucune importance, il vaut évidemment pour modifier ou supprimer.
S'il opte pour ajouter ou modifier, la zone Nom devient active et si modif. le nom y est mis, la ListBox d'emplacement devient active aussi et les domaines y sont listés. En cas d'ajout, à validation du nom dans la zone, les boutons de positionnement deviennent actifs (ils le sont déjà en cas de modif). Le message d'info est modifié en conséquence. Le bouton Valider devient également actif.
En effet, les modifs possibles portent sur le nom et/ou sur la position du domaine dans le tableau.
J'ai supposé que mettant des noms et pouvant les changer, tu entendais aussi pouvoir changer l'ordre des domaines dans le tableau...
S'il opte pour supprimer, le message d'info l'informe que tous les messages du domaine doivent préalablement avoir été supprimés et le bouton Valider devient actif.
Ça va prendre un peu plus de temps, car il faut programmer la boîte, écrire les procédures qui exécuteront les choix faits, et rectifier toutes les procédures antérieures qui s'appuyaient sur une série numérotée des domaines...
Bon dimanche.
Bonjour,
Merci pour tes réponses et tex explications. Je trouve le useform plutôt bien.
Malheureusement, je suis désolé de ne pas être très actif sur le site, j'essaie de lire pendant mes tps de libre.
Je travaille bien sur de mon coté sur le fichier ^^ mais ton aide est utile bien évidement. Merci.
MFerrand a écrit :S'il opte pour supprimer, le message d'info l'informe que tous les messages du domaine doivent préalablement avoir été supprimés et le bouton Valider devient actif.
Tu veux dire que si je veux supprimer une ligne correspondant à un domaine précis, il faut que tous les messages du domaine soient supprimés avant?
Bonjour,
Oui cela semble être une sécurité souhaitable dans ce genre d'opération, éviter de détruire un message qu'on ne voulait pas détruire en procédant à une destruction par lot.
Mais évidemment tu peux en décider autrement si tu estimes que la suppression d'un domaine, y compris ses messages pourra se faire sans risque. A toi de voir.
Outre cet aspect décisionnel (car en ce qui me concerne, je ne suis pas utilisateur sur le fond, donc pas en mesure de savoir quelle décision doit l'emporter...), l'essentiel en ce qui te concerne est d'assimiler comment on opère pour tel ou tel aspect en VBA de façon à pouvoir prendre en main le fonctionnement de l'ensemble.
Ce dernier Userform est intéressant pour progresser dans la manipulation des composants d'un Userform et sa confection.
Car les 3 'moments' : entrée, traitements internes, sortie, y sont clairement délimités sans imbrication. En entrée, on n'a que la liste des domaines, au demeurant réduite, qui ne bouge pas avant validation finale, et sans option péalable, les options intervenant dans le Userform. A partir de cette liste, soit on choisit le domaine sur lequel on veut intervenir, soit on en ajoute un et la liste n'intervient que comme toile de fond, sur laquelle on va positionner le nouveau domaine, de même d'ailleurs une fois choisi un domaine existant c'est de celui-là dont on s'occupe et la liste retourne à ce rôle de toile de fond. Le choix d'option, nommer ou modifier le nom, positionner, sont des opération exclusivement interne au Userform (tant qu'on n'a pas validé. Du point de vue fonctionnel, cela se traduit par des modifications dynamiques de contrôles résultant de l'action sur certains d'entre eux : selon choix d'option, certains deviennent actifs et d'autres inactifs, l'inscription d'un nom (cas d'ajout ou pas de nom préexistant) rend actif les contrôles qui vont permettre de le positionner, l'action sur les boutons de positionnement va modifier la liste affichée... Ce qui est intéressant dans une telle situation est que l'on peut tester quasi-intégralement le fonctionnement du Userform sans rien modifier (puisque tout se passe avant validation), cela permet de voir l'utilité de distinguer les 3 'moments' pour mettre au point le fonctionnement d'un Userform... Et la sortie est bien distincte, il s'agit alors de réaliser la configuration définie par les choix opérés dans le Userform.
Tu verras mieux tout ça dans quelques temps...
Bonne journée.
Bonjour,
Les choses avancent... il va me rester à vérifier que je n'ai rien oublié et tester, avant de réadapter les procédures antérieurement faites... Mais pour l'instant, je pars pour la clinique, retour dans environ 38 heures...
A suivre.