• Vue
• Éditer
• Historique
• Imprimer

Script de recherche par activation d'enregistrements liés

Souvent on pense qu'une recherche dans FileMaker Pro passe obligatoirement par le mode Recherche.
Il existe néanmoins une autre technique, qui, souvent, s'avère bien plus rapide : l'activation d'enregistrements liés. En effet, si un lien possède les critères de sélection (ou de filtrage, c'est la même chose), la simple commande Activer enreg.liés suffit à sélectionner dans la table liée les enregistrements désirés.
Du reste, n'est-ce pas ce que l'on a fait, par exemple sur notre modèle classe, en affichant dans une TE (Table Externe) tous les élèves ou profs de chaque classe ? Sauf que la TE ne fait qu'un affichage. si on passe du modèle CLA_Fiche au modèle PER_Liste, le jeu d'enregistrements ne correspond pas forcément (voir remarques sur l'exemple précédent).

Il y a probablement des raisons historiques à ne pas utiliser suffisamment cette technique. L'une d'entre elles est liée au fait que seules les nouvelles versions de FileMaker Pro permettent de créer un lien à partir de globales ou de calculs non indexés, ce qui n'était pas possible précédemment.

Par exemple, en utilisant cette méthode, nous pourrions simplement imaginer un lien à partir de 3 globales (qui, rappelons-le, possèdent la même valeur pour tous les enregistrements) vers 3 rubriques. Il suffit de remplir les globales avec ses critères de recherche et d'activer les enregistrements liés pour "trouver" le jeu d'enregistrements correspondant aux critères des globales... Simple, non ?

Illustrons un cas concret : une mise à jour en utilisant la commande "Activer enregistrements liés" :

Description

Dans notre fichier, depuis le modèle INS_Liste, on aimerait qu’en cliquant sur le nom, on active la fiche de la personne dans la table PER_Personnes (via le lien ins_PER__), sur le modèle PER_Fiche pour complèter une rubrique ControleInscription de la table PER avec le texte « Inscription OK », puis retour à notre liste du modèle INS.

La première chose à faire est bien sûr de créer dans la table PER_Personnes (en se plaçant sur le modèle PER_Tech) une rubrique texte ControleInscription. Plaçons-la sur le modèle PER_Fiche,

et, pour pouvoir visionner immédiatement le résultat de notre script, sur le modèle INS_LIste (à partir de l'OT ins_PER__). Du reste, pour ne pas allonger notre modèle, on peut même remplacer notre actuelle ::Commune par notre nouvelle rubrique. Comme elle provient de la même OT, il suffit de double cliquer dedans et de changer la rubrique (en modifiant le titre également).

Activer Enregistrement lié

Ceci étant fait, depuis le menu FileMaker Pro, "Script", "ScriptMaker", on crée un nouveau script ActiverNom dont la première ligne de commande (après notre en-tête) est Activer enregistrement lié. On clique ensuite sur l'option "Définir" :

Dans cette fenêtre, plusieurs options :

• Obtenir l'enregistrement lié de : on défini ici l'OT bouée que l'on veut utiliser pour atteindre la table PER_Personnes. Dans notre cas, c'est simple : ins_PER__ pour atterrir sur la table PER_Personnes.
  • on appréciera ici l'avantage d'une bonne nomenclature. En effet, un script pouvant être posé sur n'importe quel modèle, il n'y a pas de contexte pré-établi (contrairement aux calculs). La liste des OT est donc complète, sans préciser lesquelles sont liées ou non entre elles.
  • comme nous savons que nous partons de INS pour arriver sur PER, notre nomenclature nous dit clairement quelle(s) OT bouée(s) utiliser.
• Afficher l'enreg. avec le modèle : ça tombe sous le sens : FileMaker demande quel modèle on veut utiliser pour l'atterrissage. Sympa, en plus : seuls les modèles liés à la table concernée sont proposés, toutes OT confondues ! On choisi dans notre cas PER_Fiche. Ce qui veut dire, en passant, que l'on va changer de contexte lors de l'atterrissage ! En effet, nous serons alors dans le contexte PER__ et non plus INS__.
• Afficher dans une autre fenêtre : inutile pour le moment puisque nous reviendrons sur le modèle de départ.
• Afficher uniquement enreg. liés : plus subtil à comprendre...
  • Si cette option n'est pas cochée, on atterrit bien sur l'enregistrement de la personne correspondant à l'inscription, mais tous les enregistrements de la table PER seront affichés, qu'ils soient liés à INS ou pas ! L'utilisateur peut alors visualiser l'enregistrement suivant ou précédent, c'est-à-dire un enregistrement qui n'est pas forcément lié à celui de départ. Si ceci est pratique dans certains cas, c'est également dangereux...
  • Si cette option est cochée, seuls les enregistrements liés à INS via le lien ins_PER__ seront sélectionnés. On doit dans ce cas choisir une des deux options :
    • Faire correspondre uniquement les enregistrements actuels : seul(s) le ou les enregistrements liés à seulement l'enregistrement de départ de INS sera ou seront activés.
    • Faire correspondre tous les enregistrements du jeu trouvé : tous les enregistrements liés aux enregistrements actifs de INS seront activés via le lien ins_PER. Si on a opéré une sélection préalable sur p.ex. 10 enregistrements dans INS, seuls les enreg. liés à ces 10 enreg. seront activés.

Comme on le voit, les possibilités sont nombreuses et il est important de bien les maîtriser. Dans notre cas, on ne veut que l'enregistrement lié, donc on coche Afficher uniquement enreg. liés et Faire correspondre uniquement les enregistrements actuels, car on ne veut que la fiche de la personne correspondant à une inscription.

Remarque importante

Au sein d'un script, en dehors du cas ou il n'y a aucune action après l'activation des enregistrements liés, il est impératif de contrôler si, effectivement, des enregistrements liés ont bien été trouvés ! En effet, si aucun enregistrement lié n'est trouvé, FileMaker Pro ne bouge pas de modèle et reste donc dans son contexte d'origine. Conséquence : la suite des actions se passe dans un mauvais contexte. Le cauchemar absolu : si le but du script était d'activer des enregistrements pour les supprimer... aucun enregistrement n'est trouvé, et TOUS les enregistrements du jeu trouvé dans la table d'origine sont purement et simplement supprimés... Des seaux de larmes ont déjà été remplis, alors autant prévenir ! Mais nous connaissons maintenant la commande miracle pour pallier cela : Si [Obtenir(DernièreErreur) ≠ 0]

Le script

Voici le script complet :

On voit donc que, juste après la commande Activer enregistrement lié, on place la capture d'erreur avec 3 lignes de commande :

Si tout est en ordre, c'est à dire si effectivement un enregistrement lié est trouvé, alors le Si n'est pas vérifié. On saut donc directement à la ligne Fin de si et, seulement à cette condition, on peut effectuer la suite des opérations comme prévu : "Définir rubrique [PER__::ControleInscription; "Inscription OK"].

Ensuite, on n'oublie surtout pas de revenir sur notre modèle de départ.
Comme les actions du scripts ont eu lieu sur une autre table que celle d'origine, notre situation de départ reste inchangée. Ce n'est par contre pas le cas dans notre OT PER. En effet, si vous vous rendez à l'aide des boutons de navigation sur le modèle PER_Liste, vous constatez que seul l'enregistrement lié est actif et dans le jeu d'enregistrements trouvés.

Bouton

Pour déclencher le script, nous allons placer un bouton à côté des rubriques du modèle INS_Liste, avec le script comme commande :

Un simple clic sur le bouton à côté d'un nom de personne inscrite actualisera la rubrique PER__::ControleInscription en y plaçant la mention "Inscription OK" et ce, de manière presque invisible pour l'utilisateur.
Une navigation vers la table PER après l'action de ce script ne laisse apparaitre que l'enregistrement lié.

Et voici le fichier à jour.