Bonjour à tous,
Je fais appelle à l’expertise des contributeurs de ce forum pour un projet, pour éviter « de réinventer la roue » ou de choisir une voie de développement qui soit contraire à la logique d’ACCESS. Nous utilisons ACCESS 2010.

La base ACCESS que nous développons a pour but, entre autres, de recueillir des informations sur l’état des organes d’une souris. Il y a un formulaire par organe. En fonction des informations qui sont rentrées dans les premiers contrôles du formulaire, des contrôles en aval (ou « fils »), doivent s’afficher ou au moins s’activer, et être remis à zéro en cas de modification en amont.
Par exemple, à l’ouverture du formulaire, le premier contrôle est une checkbox « l’organe est présent ». Si la case est cochée, le second contrôle qui s’active est « l’organe n’est pas morphologiquement normal ». Si cette case est elle aussi cochée, des contrôles s’activent pour renseigner toute une série d’informations supplémentaires. Dans la hiérarchie des contrôles, il y a des listes déroulantes qui selon la valeur qui est sélectionnée, conduit à l’activation de certains contrôles en aval.
Etant donné qu’il y a un grand nombre de formulaire et de champs, et qu’en plus la composition des formulaires peut être amenée à évoluer dans le temps, il est fastidieux de gérer l’activation (et leur remise à zéro) des contrôles « fils » via les évènements de mise à jour des contrôles « père ». De plus, à termes, j’aimerais même pouvoir développer ou masquer des sous parties.

Pour répondre à ce besoin de « formulaire dynamique », j’ai imaginé passer par la programmation orientée objet proposée par VBA, qui est expliquée dans le précieux tutoriel de Pierre Fauconnier (http://fauconnier.developpez.com/art...neral/classes/ ) en créant une classe personnalisée « membre_de_famille ». Un membre_de_famille contient un contrôle du formulaire et les liens qui le relie au contrôle en amont (« son père »), ainsi que les méthodes qui permettent de gérer les contrôles en aval (« les fils »)
Un objet membre_de_famille comprendrait les propriétés suivantes :
- La référence au contrôle auquel il correspond
- Une collection des liens qui le relie au contrôle « père »
- Une collection de ses contrôles « fils », qui sera une collection d’objet « membre_de_famille »…

L’objet membre_de_famille comprendra aussi les méthodes qui permettent d’activer ou désactiver les contrôles « fils », qui sera déclenchée par la mise à jour du contrôle correspondant à l’objet membre_de_famille.
Les objets membre_de_famille seront instanciés à l’ouverture du formulaires, et seront ainsi tous emboîtés les uns dans les autres, dans une hiérarchie.

J’espère avoir été assez précis et concis. Que pensez-vous de cette approche ? Merci pour votre attention et vos commentaires.