Discussion :

[olra72]

Bonjour,

J'ai un formulaire avec un contrôle onglet qui renvoie vers plusieurs sous-formulaires. Certaines informations affichées sont redondantes (ie. elles apparaissent dans plusieurs onglets, voir aussi sur le fond du formulaire père).

Le problème est que je me perds entre les Me.Requery et autres Me.RefreshRecord, sans parler des activation/désactivation de contrôle Boutons à réaliser dans les Sub Form_Open ou Form_GetFocus ou Form_Activate en fonction des états de ce qui est affiché (certaines actions dans un sous-formulaire change l'état d'un de mes objets, ce qui entraîne des activations/désactivations de boutons dans d'autres onglets, voire dans l'en-tête du formulaire père).

Grâce à cet excellent forum, j'ai entre autre découvert que les Form_Open (et Close) ne s'appliquent pas aux sous-formulaires ... ce qui ne m'arrange pas (je m'attendais à ce qu'ils s'activent lorsque je changeais d'onglets).

Est-ce que quelqu'un aurait une liste de "bonnes pratiques" de rafraîchissements des données (Requery, RefreshRecord et autres) et d'utilisation des événements (Open, Activate, GetFocus et autres) pour maintenir une cohérence de tous les affichages dans un formulaire à onglets contenant des sous-formulaires ?

J'imagine que la première des bonnes pratiques aurait été d'éviter l'affichage de données redondantes ... mais mes utilisateurs en ont décidé autrement. Ils aiment bien se voir "répéter" certaines informations de base dans les onglets où ils passent et pas seulement dans l'en-tête du formulaire père (ou, d'ailleurs, je commençais à manquer sérieusement de place).

Cordialement,
Olivier

NB: pas de repentir sur les modifications - toute donnée modifiée - et valide - peut être immédiatement enregistrée dans la DB !

[olra72]

Pas de réponse ? ... et après avoir galéré moi-même sur ce sujet pendant plusieurs mois, je suis arrivé à une sorte de stabilité combinant efficacité apparente et mises à jour minimales ... mais je serai bien en peine d'en tirer ces fameuses "bonnes pratiques" que j'appelais de mes vœux.

En gros, je ne mets aucun rafraichissement qui ne soit pas évident (ex. changement de valeur d'un filtre sur les données) et j'ai éliminé la plupart de mes Me.Refresh, même sans trop comprendre comment ACCESS fait pour mettre à jour des données visibles simultanément sur plusieurs formulaires.

D'ailleurs, à ce sujet, je n'ai encore rien de bien convaincant pour la restauration des ascenseurs à leur niveau précédent un Me.Requery (quand cela a un sens, et cela arrive souvent).

Allez, encore un an ou deux, je serai au point et je pourrai conseiller les petits jeunes

Amicalement,
Olivier

[olra72]

Comme promis (qu'il l'eut cru ?), me revoila trois ans après avec de nouvelles infos.

J'ai enfin découvert comment tracer l'appel de la requête de données d'un formulaire (en l'occurrence continu) : Il faut définir une fonction de trace qui effectue un Debug.Print d'un message, qui retourne ce même message en valeur de retour et il faut AUSSI que cette valeur de retour soit affiché dans le formulaire (ie. que l'appel à la fonction de trace soit dans la requête de la source de données du formulaire.

Détail qui a son importance : Je travaille toujours avec la base active en mode "Document à onglets" (cf. Options).

A partir de là, j'ai pu m'apercevoir des choses suivantes :

DANS UN FORMULAIRE CONTINU (N enregistrements successifs visible sur le même formulaire) :
* Lors de la première ouverture d'un formulaire, la séquence d'évènements Open-Load-Activate-Current est invoquée .. et l'appel à la source de données se fait après le Current (ie. en fin de séquence)
* Si on quitte et qu'on revient au formulaire, c'est seulement la séquence Desactivate-Activate qui sera invoquée .. et l'appel à la source de données se fait après le Activate (ie. également en fin de séquence)
* Si, dans le code du formulaire on fait un Me.Requery, cela appelle d'abord la source de données ... puis la fonction Current mais seulement si le recordset n'est pas intégralement vide
* En cas de changement de ligne sélectionnée dans le formulaire continu, la fonction Current est appelée mais sans provoquer de rafraichissement de la source de donnée

Voici mon problème : J'écris classiquement un minimum de code dans les fonctions Open, Load, Activate, Current, Desactivate (plus Error pour gérer le cas des recordset intégralement vides) et je m'en sers pour activer/désactiver des boutons d'actions globales situés en bas de l'écran, pour actualiser le ruban de l'application, enregistrer une activité pour repousser mes time-out de déconnexion, etc. Bref, j'ai des chose à faire, mais alors : Dans chacune des fonctions ci-dessus, quand est-ce que je peux considérer que le recordset est à jour ?

Dans la séquence Open-Load-Activate-Current, c'est après le Current.

Dans la séquence Desactivate-Activate, c'est après le Activate.

Dans le cas d'un Me.Requery volontaire, c'est AVANT le Current.

Dans le cas de la sélection d'une autre ligne, Current est appelé et le recordset reste ce qu'il est.

Si on touche à l'ascenseur, la source de données est appelée pour récupérer les nouvelles lignes (celles qui étaient invisibles) mais le Current n'est pas appelé pour autant.

DANS UN FORMULAIRE UNIQUE (1 seul enregistrement visible) :
..C'est la même chose, sauf que la source de données ne requiert qu'un seul enregistrement (et qu'il n'y a pas d'ascenseur) mais la logique d'appel des évènements suivis ou précédés d'un rafraichissement de la source de données sont identiques.
Mais, là, y'a un os ! Dans un formulaire unique, l'état des boutons du bas de l'écran vont généralement dépendre de l'enregistrement en question !! Par exemple, si j'examine un objet "Devis" et que ce dernier a été envoyé au client (il sera donc dans un état "Diffusé"), le bouton "Supprimer" doit être grisé ou invisible. Bref, je dois mettre quelque part du code qui étudie l'objet et modifie le formulaire, donc je dois IMPERATIVEMENT savoir QUAND le recordset est à jour ou pas. Hors, parfois, je désactive le formulaire, càd que je passe dans un autre formulaire et, de là, je fais quelque chose qui va me renvoyer dans le formulaire initial mais sur un autre objet, et ..

... et je vais y réfléchir encore un coup. Maintenant, j'ai identifié le comportement d'Access (voir ci-dessus) mais - finalement - je ne suis pas sûr de ne pas me poser de faux problèmes ... ça serait bien mon genre ;-) !

[olra72]

Ah oui ! Je vous ai pas tout dit : Dans mes formulaires uniques, j'ai aussi des sous-formulaires (généralement avec leurs propres sources de données, filtrée par réplicat-maître) et je me pose aussi des questions sur qui met à jour quoi, en cas de Désactivate-Activate du formulaire principal, en cas de sélection d'un champ dans le sous-formulaire puis de re-sélection d'un champ dans le formulaire principal, etc, etc.

On peut dire que je cause tout seul, mais je me comprends ;-)

[loufab]

Bonjour,

Toutes les questions que tu te poses sur qui passe avant qui dans les événements font justement l'objet d'un tuto.

https://loufab.developpez.com/tutori...ss/evenements/

Cordialement,

[olra72]

Merci à Loufab pour sa réponse !

J'ai lu et apprécié cet excellent tuto il y a pas mal de temps ... mais il y a un point qu'il n'aborde pas (si, si, j'ai vérifié) : Quand, précisément et - éventuellement combien de fois - est appelée la requête-source qui est associée au formulaire ?

Ça fait l'objet en ce moment même d'une discussion fort intéressante sur https://www.developpez.net/forums/d2...ce-d-ouverture

Bon, d'accord, je suis principalement le seul à causer, mais je ne désespère pas - soit qu'on ne me dise que je sodomise les mouches (si, si, ça m'arrive), soit qu'on me donne une marche à suivre qui fonctionne, soit qu'on m'annonce que je me ballade dans une zone grise d'Access et que la réponse est juste "Abandonnez tout espoir, vous qui entrez ici !"

Cordialement,
Olivier

[loufab]

Bonjour,

En effet ce tuto ne dit pas tout. Tu as en complément le Chasseur d'évènements (sur ma page) une application en open source qui peut t'aider à tracer le déclenchement des évènements lors d'actions.

Pour en revenir à tes questions. Tu te poses à mon avis les mauvaises questions.

Quand ? A chaque action qui le nécessite. On est dans de l'évènementiel, ce sont les évènements qui sont à l'origine du comportement de l'ihm et non le contraire.

Le current_form ne déclenche pas le requery (interrogation de la source) mais cet événement se produit lorsque l'interrogation de la source se fait (le requery). C'est très différent.
Tu peux invoquer un Current_form mais tu n'auras pas de Requery. Par contre un requery déclenchera un current_form.

L'interrogation de la source ce fais de manière automatique 1 fois à l'ouverture du formulaire, lors de la lecture de la propriété Source. On peut situer cette lecture en amont du current_form (juste après l'open_form).

Et par extension :
A chaque me.requery : qui déclenche évidemment le current_form.
A chaque redéfinition de la source : par l'action sur la propriété Source et (à vérifier) lorsqu'il y a une action sur me.filter.

Combien de fois ?
Au minimum 1 fois à l'ouverture. Au maximum autant de fois qu'on en donne l'ordre explicitement ou non.

Pour conclure je dirais que nous sommes effectivement dans une zone grise mais que nous avons tous les moyens pour investiguer.

Cordialement,

NB : Les mouches vont surement se sentir mieux.

[olra72]

J'ai découvert que l'usage des formats conditionnels (au moins dans les formulaires continus) déclenchait bien une double exécution de la requête source. Bizarre ! Une fois que le recordset est OK, il peut être utilisé autant pour l'affichage que pour les formats conditionnels. A quoi ça sert ce double-appel ?

En l'état, pour moi, ça règle le problème : Je voulais éviter TOUS les doubles appels mais je ne suis pas prêt à renoncer aux formats conditionnels, trop pratiques pour ajouter de l'info quasi-subliminale (du genre, les items en rouge demandent de l'attention à cause d'un défaut de planification, d'un défaut de notification du client final, etc.).

... mais je vais aller voir ton "Chasseur d'Evènements". Je ne trouverais peut-être pas ce que j'espère (après tout, Acces fait ce qu'il veut quand il veut), mais je mourrai moins bête (comme dirait l'excellent Marion Montaigne).

Cordialement,
Olivier