Changements récents - Rechercher:

Tutoriel Filemaker

  1. Structure
  2. Modèles
  3. Opérations diverses
  4. Calculs
  5. Scripts
  6. Privilèges d'accès

Filemaker avancé

  1. Partage des données
  2. Astuces et Exemples
  3. Développement

Règles de nommage

Versions de FileMaker Pro

Liens utiles Contact Commentaires

edit SideBar

Script de recherche avec variable

<==Sous scripts et paramètres ^ Scripts Recherche par Activer enreg. liés==>

Le but ici n'est certainement pas de faire le script de recherche le plus sophistiqué du monde, mais d'apprendre à utiliser une variable au sein d'un script. Travaillons sur un exemple concret, et décrivons d'abord ce que l'on veut :

Description
Définir une variable
Le script

Fin du script
Bouton
Remarques



Description


Dans notre fichier, partir du modèle INS_Fiche, on aimerait contrôler si il existe plusieurs fois le même nom de personne dans la table PER_Personnes. Ainsi, on peut détecter un frère, un doublon, etc… La rubrique concernée est ins_PER__Eleves::Nom. La recherche devra donc se faire dans la table des PERsonnes.

A côté du nom repris sur le modèle INS_Fiche, on peut placer un bouton d’un script qui va :

  • Copier le contenu du nom figurant sur l'enregistrement courant dans une variable (c'est une façon de le mémoriser)
  • Se positionner sur un modèle de la table PER (donc changer de contexte, d'où l'importance d'avoir préalablement mémoriser notre critère de recherche)
  • Effectuer, dans le contexte de la table PER, une recherche sur le nom contenu dans la variable
  • Contrôler si quelque chose est trouvé
  • Si oui, nous placer sur le modèle :
    • PER_Liste si plusieurs noms sont trouvés (qui nous permet de contrôler le contenu de cette différentes personnes, pour ensuite aviser sur leur inscription)
    • PER_Fiche si un seul nom est trouvé
  • Sinon, retour à la case départ…

On pourrait imaginer aussi que, dans le contexte de départ des inscriptions, si un seul nom est trouvé un message indique que cette personne est unique et que l'on reste sur notre modèle d'inscription pour, justement, procéder à cette inscription.

Au travail !

On crée un nouveau script appelé "RechercheNom" (Nomenclature comme d'hab' : pas d'espace, écriture Camel, éventuellement des "_" pour regrouper), en-tête duquel on peut placer notre intro habituelle. On peut également, pour les heureux détenteurs d'une version 9 et plus, créer un nouveau groupe appelé "Recherches".

Définir une variable


La première chose à faire, vu qu'on est sur le modèle INS_Fiche et que nous allons ensuite changer de contexte, est d'embarquer dans une variable le nom présent sur le modèle, dans la rubrique ins_PER__Eleves::Nom.

Pour ce faire, notre première action spécifique sera liée à la commande "Définir variable" :

Une variable de type $ suffit amplement, vu que nous n'en aurons besoin qu'au sein du même script.
On donne un nom à la variable (un seul mot, et le plus court possible, svp !). Prenez également l'habitude de toujours nommer vos variables de la même manière, soit tout en majuscules, soit tout en minuscules. En effet, le nom des variables est sensible à la casse et nous pouvons vous assurer qu'il est très pénible qu'un script ne fonctionne pas comme on souhaite simplement pour une variable écrite une fois $nom et une autre $Nom !!!
En dessous du nom, dans la fenêtre "Valeur", on défini le calcul dont le résultat sera monté dans la variable. On retrouve ici notre fenêtre de calcul bien connue, et on constate que la variable peut être très simplement définie comme ici (ins_PER__Eleves::Nom), mais peut être également un calcul fort complexe.

Le script


Voici le script complet :

Gestion erreur

Comme précédemment, on démarre le script en précisant ""Gestion erreurs" = Oui, cela veut dire qu'on prend la main à FileMaker Pro pour gérer nous-même les erreurs. Le seul contrôle que l'on va effectuer pour l'exemple ici est de s'assurer qu'il y ait au moins un enreg. trouvé après la recherche. Si aucun enreg. n'est trouvé, une erreur est rendue et on peut la capter via la commande Si [Obtenir ( DerniereErreur ) ≠ 0]

La Recherche

Dès qu'on a défini et complété la variable, on peut quitter le modèle INS_Fiche et aller su run modèle de PER__ contenant la rubrique sur laquelle nous allons effectuer la recherche. Ici nous allons sur le modèle PER_Tech.
En effet, ce modèle est neutre, il contient évidemment tous les enregistrements de PER ainsi que toutes ses rubriques. Nous sommes donc sûrs de pouvoir effectuer la recherche sur ce modèle. Ceci est un point important, car il montre une autre utilité de ces modèles techniques.
Comme la recherches est gérée par le script, qu'il n'y a pas de pause et que l'annulation par l'utilisateur a été interdite, ce modèle n'apparaitra pas à l'utilisateur. Il faudra par contre ne jamais oublié de rediriger l'utilisateur vers un modèle différent, quel que soit le résultat de la poursuite du script, avant de lui "rendre la main".

Dès l'arrivée sur le modèle, on se met en mode Recherche et on défini notre critère de recherche : la rubrique "PER__::Nom" doit contenir la valeur de la variable.

ATTENTION : on a bien quitté le contexte INS, et la rubrique sur laquelle est faite la recherche n'est plus ins_PER__Eleves::Nom, mais maintenant PER__::Nom, vu le contexte du modèle PER_Tech.

Dès que le critère de recherche est défini, on exécute la requête.

2 remarques :

  • Si il y a eu une éventuelle erreur sur la recherche, elle est générée lors de l'exécution de la requête. Si on veut capter l'erreur, la commande Obtenir ( DerniereErreur ) doit être placée sur la ligne qui suit la ligne de la commande dont on veut capturer l'erreur. Si tel n'est pas le cas, le code d'erreur est perdu ou plus exactement, il aura changé puisqu'il est évalué à chaque exécution d'une ligne de script.
  • Lorsqu'on effectue une requête de recherche par script, il existe la possibilité de placer ses requêtes au sein même des commandes "Mode recherche" et "Exécuter la requête". Nous ne le conseillons pas : en effet, les détails de la requête sont masqués et le script perd notablement en visibilité. L'utilisation de la commande "Définir rubrique" est à préférer. On peut multiplier à l'envi la commande "Définir rubrique" et également multiplier les requêtes par la commande "Nouvel enreg./requête"

Les 3 cas

On analyse les 3 cas par les commandes :

  • Si (1er cas)
  • Sinon si (2e cas)
  • Sinon (dernier cas)
  • Fin de si

1. Aucun enregistrement trouvé

C'est le contrôle d'erreur : si aucun enregistrement n'est trouvé, quelle qu'en soit la cause, l'erreur n'est pas nulle et on peut en capter la valeur. On se contente ici de contrôler que le code d'erreur est ≠ 0. Si tel est le cas, on retourne sur le modèle de départ, par la commande Activer modèle [Modèle d'origine] : il n'est pas nécessaire de préciser le modèle du départ du script. On arrête ensuite le script par la commande Fin de script (sinon, il continue...)

2. Un seul enregistrement trouvé

Dans ce cas on active le modèle PER_Fiche, comme prévu.

3. Plusieurs enregistrements trouvés

Dans ce cas, c'est le modèle PER_Liste qui est activé

Remarques sur l'utilisation du "SINON SI" et "SINON"

Nous commençons par un SI qui vérifie si une erreur est apparue. S'il n'y a pas d'erreur (dernière erreur = 0), le script passe à la Fin de Si ou au prochain "Sinon" situé avant la "Fin de Si". Mais il nous reste deux cas de figure à tester, donc finalement une autre condition, d'où le Sinon si. Si cette nouvelle condition n'est pas vérifiée non plus, il nous reste donc uniquement la troisième hypothèse. Mais cette hypothèse ne peut être située après le "Fin de Si", car elle serait exécutée à tous les coups. D'où l'intérêt du simple "SINON", qui nous permet en quelque sorte de dire au script "tu vérifies tout, et si rien n'est vérifié, alors tu fais ça".

Fin du script


On remarquera que notre script se termine juste après la fin de si. En fait, il n'est pas nécessaire d'indiquer à ScriptMaker que le script est terminé. S'il ne rencontre plus d'instructions, il s'arrête tout seul. Par contre, si un résultat doit être envoyé après l'exécution du script, l'instruction Fins de Script sera utilisée.

Nous sommes passés par le modèle PER_Tech, en présisant bien qu'il ne fallait pas que le script se termine sur ce modèle. En effet, il apparaitrait alors aux yeux de l'utilisateur, qui n'est jamais censé voir ce modèle.
Mais si nous relisons notre script, nous nous apercevons que le script ne peut se terminer que sur trois instructions qui suivent l'affichage :

  1. du modèle d'origine
  2. du modèle PER_Fiche
  3. du modèle PER_Liste

Ouf, tout va bien.

Bouton


On place un bouton sur le modèle INS_Fiche, à côté de la rubrique ins_PER__Eleves::Nom, et on y "accroche" le script :

Remarques


Bien entendu, le contrôle d'erreur est ici limité aux enregistrements trouvés et le but recherché est d'illustrer la gestion d'un résultat de recherche. Il est évident que le contrôle d'erreur est ici incomplet et devrait envisager l'ensemble des erreurs possibles. Citons par exemple :

  • Contrôle sur $nom non vide
  • Contrôle sur la bonne arrivée sur le modèle PER_Tech
  • Contrôle sur la requête : PER__::Nom non vide
  • Contrôle sur les arrivées sur les modèles PER_Fiche et PER_Liste…

Voilà, un script de plus dans notre fichier. C'est le moment de le tester.

Et ce sera aussi l'occasion de constater quelques points importants sur la notion de tables...

Dans notre fichier à jour, placez vous sur la table PER_Liste. On affiche tous les enregistrements (menu "Enregistrements => afficher tous les enregistrements" ou pomme/Ctrl J). La zone de contrôle à gauche nous indique bien un total de 87 enregistrements.

Plaçons-nous maintenant sur le modèle INS_Liste et de la même manière, nous affichons tous les enregistrements (63). Première remarque, nous n'avons pas le même nombre. Rien de plus normal, nous avons 87 personnes enregistrées (table PER__) mais nous n'avons procédé qu'à 63 inscriptions (table INS__).

Nos enregistrements sont classés par ordre de saisie. Pas besoin de faire un tri pour le moment, nous nous plaçons par contre sur la ligne de l'élève Al Bibaque (notre 9ème enregistrement de la table INS_Liste).

Et nous passons en mode fiche... La zone de gauche comporte toujours nos 63 enregistrements. Si nous retournons maintenant sur notre modèle PER_LIste, nous avons toujours 87 enregistrements trouvés.

Depuis notre modèle INS_Fiche, exécutons notre script de recherche des noms. Nous trouvons un deuxième élève, son frère Yul. Nous sommes sur le modèle PER_Liste et nous avons maintenant 2 enregistrements trouvés.

Si nous allons à nouveau sur notre modèle INS_Liste (rappelez-vous que la navigation se fait par les boutons du haut), nous avons toujours nos 63 enregistrements.

Nous avons modifié le jeu d'enregistrements trouvés de PER, pas de INS.

Les tables sont, en quelque sorte, indépendantes. C'est une source de confusion classique, lorsqu'on se trompe de contexte par exemple. La recherche que nous venons d'effectuer a porté sur la table PER. Nous avions quitté le contexte INS, qui donc n'a pas été modifié.

Quatre leçons à tirer de ce constat :

  • il faut toujours tenir compte et vérifier le contexte dans lequel on se trouve avant de penser qu'on a perdu des enregistrements, ou qu'une recherche ne fonctionne pas (entre autres)
  • subsidiairement, il peut être intéressant de différencier graphiquement les contextes, pour éviter les confusions. Ainsi nos modèles listes et fiches se ressemblent bigrement, à l'exception du titre. Si le fond bleu des PERsonnes devenait vert pour les INScriptions, le changement de contexte serait plus "voyant"
  • on peut tirer profit de cet état de fait en jouant sur les fenêtres. Si notre recherche sur PER se fait après l'ouverture d'une nouvelle fenêtre, les résultats affichés dans cette fenêtre seront dans le contexte PER, mais la fenêtre d'origine (INS_Fiche) n'aura pas été modifiée
  • il ne faut pas confondre l'affichage et la table elle-même, les enregistrements d'une table et ses enregistrements liés. Ce qui nous amène tout naturellement à parler de recherche par Activer enreg. liés
<==Sous scripts et paramètres ^ Scripts Recherche par Activer enreg. liés==>
Éditer - Historique - Imprimer - Changements récents - Rechercher
Page mise à jour le 28 mai 2017 à 18h34