Limites de VBA: Alimenter des fiches depuis un userform
Bonjour à tous,
est -il possible de faire compléter des fiches à partir d'un userform de VBA?
Pour être précise et en espérant être le plus concise possible ( enfin j'espère):
j'ai crée grâce des userforms
à la base je voulais que ces userforms complétent des tableaux excel ( comme je l'ai déjà aperçu ) mais ... mon manager ne veut pas.
Il exige que les userform alimentent directement des fiches afin qu'elles soient d'ores et déjà prêtes à l'impression et l'exploitation.
Il accepte que ces fiches soient des pages Excel ... j'ai bataillé mais j'ai eu gain de cause
Est-ce faisable ?
VOICI UN FICHIER POUR RENDRE LISIBLE MA QUESTION ET VISUALISER MA DIFFICULTE
Merci d'avance
Bonsoir,
Je crois qu'il conviendrait d'abord de signifier à ton manager de fixer les objectifs et d'évaluer les résultats ensuite, sans se mêler de la réalisation s'il ne s'y colle pas lui-même !
Mais il est indispensable en contrepartie que tu démontres l'efficacité de ta réalisation ! Car au stade actuel, il y a pas mal à faire encore pour que cela prenne tournure...
Il convient particulièrement d'éviter d'inventer une syntaxe et essayer de coder avec la syntaxe VBA. En la respectant strictement, cela marchera toujours mieux !
Eviter également d'insérer des contrôles dans le code tant qu'il ne sont pas dans le Userform, et donc n'existent pas !
Et si l'on choisit d'utiliser des tableaux Excel, en tenir compte pour coder et ne pas coder comme s'ils n'existaient pas !
Ceci étant dit, ton idée d'utiliser le formulaire pour constituer une base, qu'elle soit en tableau Excel ou non, est tout à fait pertinente.
Cette base permettra d'alimenter aisément une fiche (ta feuille fiche, à ramener à un exemplaire, dotée d'une liste déroulante pour appeler n'importe quelle fiche de la base).
A moins d'avoir des dons particuliers, on ne consulte qu'une fiche à la fois
Et on peut également imprimer l'ensemble des fiches (procédure d'impression les appelant en boucle) avec une procédure tout à fait simple.
La feuille Fiche demeurera légère, et le classeur du même coup également, ce qui peut assurer un fonctionnement optimal de l'application.
Je t'encouragerais donc à définir ta base de données, y placer 2 ou 3 exemples de façon à établir ta fiche et le système d'affichage (des formules donneront certainement le meilleur résultat pour cela), puis à passer au codage de ton Userform pour alimenter ta base.
A noter que le code sera bien plus simple que s'il s'agit d'alimenter tes fameuses fiches, et plus rapide aussi !
(Mais il va te falloir acquérir quelques bases...
Cordialement.
Bonjour maréchal,
= EXCELLENT !MFerrand a écrit :Je crois qu'il conviendrait d'abord de signifier à ton manager de fixer les objectifs et d'évaluer les résultats ensuite, sans se mêler de la réalisation s'il ne s'y colle pas lui-même !
siga2fadial a écrit :à la base je voulais que ces userforms complétent des tableaux excel ( comme je l'ai déjà aperçu ) mais ... mon manager ne veut pas.
Il exige que les userform alimentent directement des fiches afin qu'elles soient d'ores et déjà prêtes à l'impression et l'exploitation
Bon, à nouveau, on confond présentation des résultats et gestion des données.
Les données doivent être gérées dans un tableau.
Ensuite, pour ce qui est des présentations, on peut extirper au moment d'éditer les éléments relatifs à un item.
Un sujet similaire dans son esprit est en cours ...https://forum.excel-pratique.com/post586484.html#p586484
Hello
@MFerrand merci pour cette tranche d'humour... qui serait mieux passer dans d'autres circonstances.
Je pensais trouver de l'aide et pas des moqueries
Toutefois en période d'essai pour encore un long moment et après plusieurs années sans emploi, je vais plutôt opter pour l'étude de la seconde proposition.
Merci pour votre bienceillance et votre piste M. Steelson.
Chers Maréchal et M.Steelson, bonne journée.
Siga
N'hésite pas ... on fait un peu d'humour pour se détendre, mais on est là (bénévolement) pour aider et nous faire plaisir dans la résolution des sujets.
siga2fadial a écrit :Hello
@MFerrand merci pour cette tranche d'humour... qui serait mieux passer dans d'autres circonstances.
Je pensais trouver de l'aide et pas des moqueries
Bonjour,
Tu me peines un peu en faisant état de moqueries, ce dont je me suis particulièrement gardé !
Je ne t'ai nullement conseillé de t'affronter !
Sans doute te faudra-t-il en passer par une double réalisation pour démontrer que celle répondant le mieux aux spécifications recherchées d'un point de vue fonctionnel est bien celle qui s'appuie sur le schéma que tu projetais au départ...
C'est cette idée de base, parfaitement logique pour répondre à la question posée, qui a motivé mon intervention !
Il serait effectivement dommage de mettre de côté la meilleure réponse... Je ne vois par ailleurs aucune contradiction entre mes propos et l'avis émis par Steelson (que je salue !).
Tout cela exige bien évidemment d'améliorer très rapidement ton approche d'Excel et VBA ! Je me suis limité à une critique sur 3 points au vue de ton bout de code d'essai... Je t'engage à les étudier de très près. Les deux premières te sauteront au visage par les erreurs qu'elles ne manqueront pas de provoquer, la 3e te compliquera la tâche si tu n'en tiens pas compte... J'ai pas mal d'autres critiques (ou recommandations, question de point de vue...) en réserve. Que tu ne soies pas en mesure d'atteindre immédiatement la perfection, c'est logique et n'a rien de dramatique. C'est bien pour cela que tu viens chercher un appui sur le Forum ! A toi de faire aussi l'effort te permettant d'utiliser correctement et efficacement l'appui que tu trouveras.
Les choix de base t'incombent de toute façon... !
Cordialement et bonne journée.
Rebonjour,
Visiblement j'ai froissé le maréchal mais bon je ne dois pas avoir compris le conseil ci-après
[quote="MFerrand"]Bonsoir,
Je crois qu'il conviendrait d'abord de signifier à ton manager de fixer les objectifs et d'évaluer les résultats ensuite, sans se mêler de la réalisation s'il ne s'y colle pas lui-même !
En vous relisant vous verrez aussi que vous n'êtes pas avare d'émoticônes et de points d'exclamation.
Pris ensemble tout celà ressemble à des sarcasmes même ci cela vous semble être de l'appui ...mais bon c'est mon avis et heureusement je préfère aller de l'avant
Je retiens donc uniquement les conseils relatifs aux BD et aux userform ... tout le reste étant plutôt sybillin voire anxiogène:
Ainsi la plupart des bénévoles auraient précisé les erreurs et non inviter l'auteur du sujet à les rechercher, à améliorer très rapidement leur niveau en VBA ou faire des efforts ( pas cool en fait ! je sais que je ne suis pas douée et je fais des efforts mon souci est surtout que je manque de temps ... d'où mon appel au secours ... mais oui j'oublie je ne dois surtout pas dramatiser et faire fi du contexte dans lequel j'évolue, si on me vire après tout je retrouverai peut-être un autre travail bien plus vite ...)
Souhaitons-moi plutôt de recevoir l'aide de bénévoles plus compréhensifs
Bien cordialement et bonne journée
En vous relisant vous verrez aussi que vous n'êtes pas avare d'émoticônes et de points d'exclamation.
Je ne les mets pas par inadvertance sans m'en rendre compte !
Je pourrais fort bien m'en passer... mais histoire d'induire quelques variations de tonalités d'un côté et mettre des accents sur quelques aspects de l'autre. Pas très grave si l'intention n'en est pas exactement décodée, les choses s'éclaircissent en général dans la poursuite de la discussion.
Ainsi la plupart des bénévoles auraient précisé les erreurs et non inviter l'auteur du sujet à les rechercher, à améliorer très rapidement leur niveau en VBA ou faire des efforts
Comme je l'ai dit, ma critique s'est limitée à 3 points : il suffit de lire, c'est suffisamment clair !
Aucun besoin de s'étendre sur le premier, ça te saute au visage dès l'ouverture et le compilateur te signifie qu'un bloc With ouvert avec With doit se fermer par End With. Rien à décoder, c'est clairement dit. Si on peut en imbriquer, il doit y avoir parenté entre l'objet imbriqué et celui dans lequel on l'imbrique (ça, simple question de logique : on n'imbrique pas deux objets étrangers l'un à l'autre...). Exemple :
With Worksheets("xxx")
'[...]
With .Range("A2:A100")
[...]
End With
End WithC'était l'occasion de dire qu'il y a une syntaxe à respecter. J'aurais pu ajouter que l'Aide de VBA est le premier moyen de vérifier la syntaxe utilisée dans chaque cas, et savoir utiliser l'Aide, et le faire, est l'une des premières choses à apprendre en VBA...
Et également, au cas particulier de l'instruction With... End With (que je recommande toujours d'utiliser systématiquement chaque fois que l'occasion s'en présente, car elle apporte un gain...), qu'elle joue son rôle en évitant des instructions répétitives mais n'en a pas à jouer s'il ne se présente aucune répétition.
Pour le 2e, les erreurs se seraient manifestées dès la 1re erreur de compilation réglée : appeler des objets inexistants ne peut que générer des erreurs... Il me semble avoir parfaitement spécifié la nature de l'anomalie (et là encore un peu de logique suffit à la comprendre).
Ma 3e signalisation était un peu plus indirecte. Elle visait à inciter à se pencher d'un peu plus près sur les caractéristiques des tableaux Excel dès lors qu'on en utilisait. C'est en appréhendant correctement ces caractéristiques que l'on se met en mesure d'en utiliser au mieux les avantages qu'ils peuvent présenter. Car à quoi bon mettre en place un tableau Excel pour ensuite traiter comme s'il s'agissait d'une plage ordinaire ! La suite était un travail à faire pour améliorer l'utilisation en ce domaine.
Quant à améliorer "très rapidement" le niveau en VBA, il n'y a pas de miracle, il y faut beaucoup de travail et laisser faire le temps avec la pratique. Des choses pourront avancer rapidement, et d'autres moins.
Tu sembles t'être focalisé sur la première phrase de mon post. Je n'en retire aucun mot ! Tout au plus, faut-il préciser que le terme "signifier" n'est pas à prendre dans son sens littéral direct, qu'il ne s'agit pas de créer ou entretenir une situation de conflit, mais d'aboutir au résultat équivalent à ce que cela donnerait si le rapport de forces te permettait une application littérale. N'étant pas exactement le cas, un contournement s'avère nécessaire mais l'objectif demeure si tu veux parvenir à travailler dans des conditions satisfaisantes...
J'ai également indiqué un schéma rationnel, déjà élaboré, de réalisation de ton projet. Si tu ne le perçois pas tel, c'est qu'il y a un travail préalable à accomplir qui fait actuellement défaut.
Souhaitons-moi plutôt de recevoir l'aide de bénévoles plus compréhensifs
Je l'ai fréquemment exprimé, l'assistance que je peux apporte ne repose sur aucune vocation altruiste. Mais sur un échange où chacun doit trouver son compte... Si mes motivations peuvent avoir un caractère d'ordre général ou social, sans échange promettant d'être éventuellement fructueux, je m'abstiens, mais je te souhaite volontiers de recevoir l'aide que tu souhaites puisque la mienne ne t'agrée point !
Cordialement.
ok Maréchal, bonne continuation
Bonjour à tous,
siga2fadial, je ne comprend pas très bien pourquoi tu bloques sur l'introduction de MFerrand
J'y lis qu'il te conforte dans ton premier choix d'alimenter un tableau (et tout le monde ici te dira pareil) et que ton chef te conseille des âneries (lui dire autrement bien sûr) en voulant une fiche par je-ne-sais-quoi.
Son choix est contre-productif, complique à outrance le code et toute analyse des données pour rechercher les anomalies
A toi de préparer tes arguments, qui ne manquent pas, pour le convaincre avec diplomatie.
S'il peut voir la fiche qu'il veut, que ce soit par un clic sur un onglet ou un choix dans une liste déroulante, ça ne change rien pour lui.
Tu as tout a y gagner. Sinon tu risques de partir sur une usine à gaz difficile à maintenir et à faire évoluer. Tout ce qu'il verra à ce moment là c'est une incompétence de ta part, et non pas le résultat de ses choix.
Une saine lecture pour prendre un bon départ : http://www.xlerateur.com/divers/2010/05/14/les-13-regles-d%E2%80%99or-pour-utiliser-excel-comme-gestionnaire-de-donnees-612/
eric
Merci infiniment eriiic pour ce lien,
J'ai bien compris qu'il fallait que je fasse des tableaux et que je les utlise comme base de données.
En revanche , comme l'avait déjà perçu Steelson ce qui importe à mon chef c'est la présentation.
Ce qui me trouble et m'inquiète dans vos réponses est que vous faites une distinction entre la fiche et le tableau...
Je pensais sans doute naïvement que la fiche étant sur une feuille Excel, elle pouvait être complétée comme
un tableau en indiquant dans les instructions où doivent être répertoriée les données.
Mais bon appremment je rêve et vous agace ,
Désolée
siga2fadial a écrit :Je pensais sans doute naïvement que la fiche étant sur une feuille Excel, elle pouvait être complétée comme
un tableau en indiquant dans les instructions où doivent être répertoriée les données.
On peut le faire ... si je te suis, l'idée que tu t'en fais est de renseigner les fiches (en fait une seule) qui viendrait en cas de changement modifier les tableaux-BasesDeDonnées du coup pas forcément visibles ...
C'est aussi possible par des procédures événementielles https://www.excel-pratique.com/fr/vba/evenements_feuille.php
Je vais me replonger dans ton sujet ...
Je me suis replongé dans ton fichier que j'ai un peu de mal à comprendre. Je vois une série de 3 fiches sur le même onglet avec le même identifiant.
Je veux bien faire une maquette générique qu'il te faudra ensuite customiser mais cela prendra du temps ... confirme moi que c'est bine la direction que tu souhaites.
Steelson,
Il y a effectivement 3 fiches avec un même identifiant qui correspond à un seul et même Thème.
Ce qui va changer c'est l'intitulé du risque, le contrôle à effectuer qui seront différents pour chaque fiche d'où 3 fiches.
En revanche comme il s'agit du même thème le formulaire est commun aux 3 fiches pour mettre à la personne qui le remplit de faire
les vérifications sur le même échantillon.
par exemple, elle a 20 dossiers et va étudier la gestion des participants sous l'angle de 3 risques diférents.
J'ai mis à jour mon fichier excel, et je te le joins en espérant que cela te parlera plus.
Il ya plus d'explication du projet en page accueil,
Encore merci
Bonjour,
Les modules de feuilles, du classeur, des Userforms, sont des modules dits de documents, ce sont des modules liés à des objets, ils sont par définition privés (contrairement aux modules standards qui sont publics, sauf si déclarés avec l'option Private Module). Ces modules d'objets servent notamment à gérer les évènements survenants sur les objets concernés où les objets insérés éventuellement dans ces objets parents.
Le module classeur (ThisWorkbook) permet de gérer les évènements du classeur (Ouverture, Enregistrement, Fermeture, évènements communs à toutes les feuilles, etc.)
Les modules de feuilles de calcul (chaque feuille dispose de son module) permet de gérer les évènements survenant sur la feuille (Activation, Désactivation, Déplacement de la sélection, Modifications de cellules, etc.) ainsi que les évènements concernant certains des objets insérés dans la feuille, notamment les contrôles ActiveX, le click sur un bouton (qui est un évènement survenant sur la feuille, s'il s'agit d'un ActiveX) doit ainsi être programmé en tant qu'évènement de la feuille...
Un module de Userform permet essentiellement de programmer les évènements du Userform et des contrôles créés sur le Userform.
Ces modules d'objets disposent juste au-dessous de l'intitulé du module, de deux listes déroulantes (comme dans tout module, mais qui présentent quelques particularités propres à ces modules.
La liste de gauche liste les objets dont les évènements sont programmables dans le module, et doivent y être programmés car ils ne peuvent être programmés ailleurs. Lorsque l'on veut programmer un évènement d'objet, on clique sur l'objet à programmer dans cette liste déroulante. On veut programmer un évènement de la feuille, on clique sur Worksheet, ce qui affiche la déclaration de procédure de l'évènement par défaut de la feuille (qui est SelectionChange), si c'est un autre évènement que l'on veut programmer, on laisse le curseur dans la procédure déclarée par défaut, et on se rend dans la liste déroulante de droite qui liste alors les évènements programmable de l'objet, on clique alors sur l'évènement souhaité (par exemple Change...), et on pourra effacer la déclaration de SelectionChange si l'on n'entend pas l'utiliser).
Si l'on veut programmer un bouton que l'on a inséré dans la feuille, on clique sur (par exemple) CommenButton1 dans la liste de droite, et la déclaration de l'évènement Click (par défaut pour un bouton) s'affiche. Là c'est généralement celui que l'on programme, pratiquement toujours, même si l'on est amené à programmer d'autres évènements pour le bouton... On tape le code qui doit être exécuté au clic sur le bouton à l'intérieur de la déclaration (entre le Sub et le End Sub).
Ces déclarations de procédures s'affichent toujours en Private Sub... Ce sont des procédures privées (par définition, et il n'y a jamais lieu de le modifier car elles ne peuvent être que privées (les procédures normales sont publiques par défaut, lorsqu'on écrit Sub, c'est équivalent de Public Sub, sans que l'on ait besoin de le signifier en utilisant le mot-clé Public ; à l'inverse des déclarations de variable, privées par défaut : en tapant Dim, c'est équivalent à Private, sans qu'on ait besoin là aussi de le signifier explicitement, mais pour qu'une variable de niveau module soit publique (c'est à dire que l'on puisse y accéder d'un autre module) elle doit être déclarée avec Public, et non Dim).
Passer par ces listes déroulantes pour programmer une procédure d'évènement est fortement recommandé pour se garantir de tout risque d'erreur dans la déclaration, qui aboutirait au non déclenchement de l'exécution lors de la survenance de l'évènement.
Pour traiter les diverses erreurs qui surviennent, tant à l'exécution que dès leur inscription (s'il s'agit d'erreurs de compilation), on ne répètera jamais assez qu'il est primordial d'utiliser l'Aide sans modération, pour y rechercher notamment la syntaxe à utiliser dans chaque cas, et également qu'il convient de taper un code propre, facilement lisible, en l'indentant systématiquement, ce qui permet déjà d'éviter une quantité non négligeable d'erreurs en détectant d'un simple coup d'oeil des éléments manquants, dès lors que l'indentation est correcte.
Ce qui me trouble et m'inquiète dans vos réponses est que vous faites une distinction entre la fiche et le tableau...
Une base de données se présente sous forme de tableau : une ligne du tableau représente un enregistrement, un élément constitutif de la base, les colonnes sont les champs de la base, chaque élément disposant d'une caractéristique propre relative à chacun des champs (caractéristiques qui peuvent être soit librement formulées, soit plus étroitement codifiées, à partir d'une liste limitative, qui également peuvent être obligatoires si tous les enregistrements doivent avoir une caractéristique relevant d'un champ toujours définie, ou facultatives si seuls certains enregistrements en disposent...)
C'est au moyen de ce tableau qu'on gère la base de données : ajout d'enregistrements, recherches pour consultation, modifications ou suppression. Que l'on gère en utilisant un Userform (conseillé pour une meilleure fiabilisation) ou en intervenant directement dans le tableau.
Une fiche n'est qu'un sous-produit : c'est une façon d'afficher un enregistrement sous une mise en forme particulière... et comme nous n'avons que deux mains et deux yeux, on ne lit pas 50 fiches simultanément mais une seule à la fois, un systéme fonctionnera de façon optimale en permettant de sélectionner la fiche que l'on souhaite consulter (soit l'enregistrement de la base), de l'afficher instantanément une fois sélectionner et de passer instantanément d'une fiche à une autre au fil de la consultation. Une fiche n'a besoin d'exister que si on la regarde, et aucunement tant qu'on ne la regarde pas, ce qui permet un classeur plus léger et plus réactif, et l'on peut très raisonnablement penser que la création de la fiche à consulter suivie de sa suppression lorsqu'on ne la consulte plus ou de son remplacement par une nouvelle fiche à consulter... sera toujours plus rapide que la recherche d'une fiche préexistante mais non visible immédiatement sans recherche dans une masse de fiches qui double (au moins) le volume de la base, sinon beaucoup plus si l'on doit ajouter de nombreuses feuilles et des outils spécifiques de recherche (la recherche dans un tableau reste ce qu'il y a de plus rapide...)
Cordialement.
NB- Informations gracieuses !
Bonjour (..)
@Mferrand
J'aurais presque dit la même chose
en rajoutant peut-être etc...MFerrand a écrit :Une base de données se présente sous forme de tableau : une ligne du tableau représente un enregistrement, un élément constitutif de la base, les colonnes sont les champs de la base, chaque élément disposant d'une caractéristique propre relative à chacun des champs (caractéristiques qui peuvent être soit librement formulées, soit plus étroitement codifiées, à partir d'une liste limitative, qui également peuvent être obligatoires si tous les enregistrements doivent avoir une caractéristique relevant d'un champ toujours définie, ou facultatives si seuls certains enregistrements en disposent...)C'est au moyen de ce tableau qu'on gère la base de données : ajout d'enregistrements, recherches pour consultation, modifications ou suppression. Que l'on gère en utilisant un Userform (conseillé pour une meilleure fiabilisation) ou en intervenant directement dans le tableau.Une fiche n'est qu'un sous-produit : c'est une façon d'afficher un enregistrement sous une mise en forme particulière... et comme nous n'avons que deux mains et deux yeux, on ne lit pas 50 fiches simultanément mais une seule à la fois, un systéme fonctionnera de façon optimale en permettant de sélectionner la fiche que l'on souhaite consulter (soit l'enregistrement de la base), de l'afficher instantanément une fois sélectionner et de passer instantanément d'une fiche à une autre au fil de la consultation. Une fiche n'a besoin d'exister que si on la regarde, et aucunement tant qu'on ne la regarde pas, ce qui permet un classeur plus léger et plus réactif, et l'on peut très raisonnablement penser que la création de la fiche à consulter suivie de sa suppression lorsqu'on ne la consulte plus ou de son remplacement par une nouvelle fiche à consulter... sera toujours plus rapide que la recherche d'une fiche préexistante mais non visible immédiatement sans recherche dans une masse de fiches qui double (au moins) le volume de la base, sinon beaucoup plus si l'on doit ajouter de nombreuses feuilles et des outils spécifiques de recherche (la recherche dans un tableau reste ce qu'il y a de plus rapide...)Cordialement.NB- Informations gracieuses !
Bel exemple que ce fil, de ce qu'il ne faut pas faire (ou plutôt pas laisser faire) à ceux qui pensent sans réfléchir ou aux patrons qui ...(
Bonjour le fil
@MFerrand, eriic, Steelson
Je constate (avec joie - que nombreux ici sont ceux qui pensent comme moi - mais ça je le savais déjà)
@siga2fadial
Je te confirme que tu as raison !
Ton patron t'as confirmé qu'il acceptait de te donner une chance de signer un CDI dans son entreprise
Mais si il t'as donné cette chance, c'est peut être aussi parce qu'il n'est pas capable de réaliser sans toi ce besoin...
Donc à toi de lui prouver que tu as parfaitement cerné et réalisé son besoin et qu'en plus tu emploies les bonnes méthodes pour y arriver
Je suis persuadé, qu'il sera ravi de te convoquer à l'issue de ta période d'essai pour te faire signer en bas de la page
Persiste dans ta direction première (et dans les conseils des "rouges") et tu réaliseras le besoin de ton patron sans te compliquer la vie, l'outil sera nécessairement plus rapide qu'avec sa méthode, mais le résultat sera le même !
Bonne chance...
Nous serons là, pour te soutenir, et t'aider !
Pour t'aider à
siga2fadial a écrit :Steelson,
Il y a effectivement 3 fiches avec un même identifiant qui correspond à un seul et même Thème.
Ce qui va changer c'est l'intitulé du risque, le contrôle à effectuer qui seront différents pour chaque fiche d'où 3 fiches.
En revanche comme il s'agit du même thème le formulaire est commun aux 3 fiches pour mettre à la personne qui le remplit de faire
les vérifications sur le même échantillon.
par exemple, elle a 20 dossiers et va étudier la gestion des participants sous l'angle de 3 risques diférents.
J'ai mis à jour mon fichier excel, et je te le joins en espérant que cela te parlera plus.
Il ya plus d'explication du projet en page accueil,
Encore merci
Un peu complexe, mais je vais me lancer dans quelque chose d'assez générique car la question revient souvent ... l'interface sera donc un seul onglet et les données seront stockées dans un ou plusieurs tableaux cachés. Mais cela ne vas pas sortir tout de suite ! Je vais repartir d'un projet que j'avais fait mais qu'il faut que je retrouve après une fouille archéologique dans mon micro
Si qqun veut aussi concourir, il est bienvenu.
(..)
Merci SteelsonSteelson a écrit :Si qqun veut aussi concourir, il est bienvenu.
@siga2fadial
J'ai commencé à parcourir ton dernier fichier pour tenter d'élaborer une solution...
Il y a plusieurs choses qui me chagrine...
Une 1ère questions donc !
Dans ton formulaire tu as des Clubs et des Participants (en Combobox) or telles que sont structurées tes tables dans l'onglet [Listes]nous n'avons aucun moyen de savoir si les "Participants" font partie d'un "Club"
Bonjour,
MERCI le fil pour vos conseils et encouragements... EN PARTICULIER @ MFerrand ça me fait chaud au coeur
et je reprends confiance en moi, il est vrai que je n'avais pas songé que mon chef ne savait peut-être pas programmé et qu'il tiendrai aussi compte du fait que la conception d'un outil n'est pas ma tache principale.
Je m'y remets donc calmement et riche de votre soutien, quitte à bosser demain pendant ce jour férié qui tombe à pic
à plus tard et bonne journée à tous
Siga