Cette astuce très simple fait suite à une demande revenant souvent sur les forums : comment utiliser le formatage conditionnel ou modifier le libellé des onglets par calcul.
Le fichier d’exemple (télécharger) est le même que celui de l’article sur les Bibliothèques
FileMaker propose plusieurs manières de formuler des requêtes sur la base de données. (scripts, calculs, recherches, interfaces sql, xml…). Mais c’est bien les liens qui donnent le plus de fil à retordre au développeur expert comme au débutant.
Voici quelques petites astuces de manipulation et quelques idées plus fondamentales qui vous aideront à mieux appréhender cette outil.
Attention, une maîtrise minimale des liens et de la logique relationnelle est nécessaire pour suivre cette vidéo.
Si vous développez des solutions FileMaker pour une organisation belge, vous avez peut-être parfois besoin de créer des numéros communications structurées.
Nous avons récemment publié une fonction personnalisée qui vous permet, à partir des 10 premiers chiffres (libres), de formater et compléter la communication.
Ainsi, si vous composez une chaîne telle que 1234567890 (constituée, par exemple, du numéro de client et du numéro de facture), cette fonction vous rend le résultat : 123/4567/67890/02. (les deux derniers caractères étant la clef de validation de la communication)
http://fmfunctions.com/fid/321
Cette fonction n’est pas récursive, c’est-à-dire que si vous ne disposez pas de FileMaker Pro Advanced, vous pouvez utiliser la formule comme un simple calcul en remplaçant simplement _input = _char10 par _input = [votre chaîne de 10 caractères]
Quand un utilisateur souhaite créer rapidement des enregistrements liés, une table externe basée sur un lien autorisant la création semble toute indiquée.
Néanmoins, cette technique native présente quelques inconvénients :
Voici un fichier qui présente deux techniques simples pour permettre à l’utilisateur de créer des enregistrements dans une table externe depuis un champ de saisie situé au-dessus de celle-ci.
L’une, la plus simple, est disponible depuis FileMaker 7 (moyennant une petite adaptation du calcul qui utilise la fonction Contenu, apparue avec FileMaker 9)
L’autre se base sur les filtres de tables externes filtrées, apparus en FileMaker 11.
If a user wants to easily create related records, a portal based on a relationship set to allow creation is obviously appropriate.
Nevertheless, this built-in technique has some cons:
This sample file presents two easy techniques that allow creation from a field placed above the portal.
The first one, the easiest as well, has been available since FileMaker 7 (although the auto enter calculation would require a little adaptation, because it’s making use of Self function, a FileMaker 9 feature)
The second one uses filtered portals, a FileMaker 11 feature.
L’ensemble trouvé est un concept-clef de FileMaker, à tel point qu’on oublie parfois de l’expliciter. Or sa maîtrise est indispensable, tant pour le développement que pour l’utilisation de FileMaker.
Un point méconnu et souvent source de problème dans les solutions multi-utilisateurs est la différence entre afficher tous les enregistrements et figer un ensemble trouvé de tous les enregistrements.
Au travers d’une courte vidéo, apprenez comment éviter ce piège.
Dans ce numéro, nous présentons des techniques que nous utilisons souvent pour la gestion des bibliothèques (libraries) dans FileMaker, notamment pour les images de l’interface et les chaînes de texte.
Ces techniques sont très simples à mettre en œuvre, et facilitent grandement le développement en rendant le contenu de ces libraries toujours disponible, quelque soit le contexte ou le mode.
FileMaker propose plusieurs présentations pour sélectionner des éléments dans une liste de valeurs. Or il n’est pas aisé de proposer un choix exclusif parmi plusieurs valeurs.
Les boutons radio (ou cercles d’options) devraient permettre ceci, mais malheureusement, le maintien de la touche majuscule permet à l’utilisateur de choisir plusieurs valeurs, même avec ces boutons radio.
Cette astuce permet de contourner cette difficulté, et de proposer de vrais choix exclusifs.
Si vous n’avez pas de notions de programmation, les boucles sont certainement l’aspect le plus déroutant de l’écriture de scripts.
Si vous êtes au contraire un développeur né, la simplicité des boucles dans FileMaker est également l’aspect le plus déroutant de l’écriture de script.
Dans cette vidéo, nous explorons plusieurs techniques, trucs et astuces pour faciliter la programmation de de ces fameuses boucles.
Par exemple, pour définir un calcul auto-entré en fonction de la rubrique active, on devra écrire :
Si ( Obtenir ( NomRubriqueActive ) = "leNomDeMaRubriqueEnToutesLettres" ; A ; B )
autre exemple célèbre, les listes de valeurs :
ElémentsListesValeurs ( Obtenir ( NomFichier ) ; "leNomDeMaListeEnToutesLettres" )
Ceci est dû à l’absence de fonction permettant d’interroger la structure de la base de données. On ne peut écrire, à la place de la première expression (FileMaker 10 a depuis la publication originale de cet article, introduit la fonction ObtenirNomRubrique, qui rend cette affirmation caduque) :
Si ( Obtenir ( NomRubriqueActive ) = leNomDeLaRubriqueDontJeSuisEnTrainDeDéfinirLeCalcul ; A ; B )
ni, à la place de la seconde :
ElémentsListesValeurs ( Obtenir ( NomFichier ) ; laListeDesBidulesDontJAiOubliéLeNom )
Avec la généralisation de techniques comme l’utilisation de plug-ins pour le déclenchement de scripts -FileMaker boudant décidément la programmation sur événement-, ou des scripts standardisés de navigation comme les LayoutProperties, ce problème a atteint une ampleur critique et touche le nom des scripts et des modèles, et même les occurrences de tables.
Je ne parle même pas de l’API php, qui oblige à TOUT hard-coder, car la technique que je vais vous présenter ne règle pas ce cas. On pourra éventuellement développer l’équivalent pour le côté php.
Mais au fait, quel est vraiment le problème ?
Principalement, le fait de référencer un élément en tant que constante de texte dans un calcul empêche ensuite de modifier le nom de cet élément, à moins d’explorer à fond tout le DDR (Rapport de Structure de Base de Donnée) avant chaque modification.
Imaginons que vous ayez un modèle “Clients_liste”, et un script qui active ce modèle en utilisant l’action Activer modèle (nom par calcul) Imaginons qu’au cours de votre développement, ce modèle devienne un format tableau. Vous le renommez fort opportunément “Clients_tableau”. Bien.
Sauf que paf ! votre script ne fonctionne plus (nous partons du principe dans cet article qu’un script qui ne fonctionne plus n’est pas un résultat souhaitable). Avec le temps, votre solution est truffée de choses bizarrement nommées, qui font tout autre chose que ce que leur nom indique, et vous ne vous y retrouvez plus (sans parler de vos éventuels collaborateurs ou de votre client, s’il a accès au code source)
Aussi, vous passez des heures à vous acharner sur un calcul qui ne marche pas, pour finalement vous rendre compte que vous avez fait une petite faute de frappe dans le nom du bidule. Que celui à qui ça n’est jamais arrivé se taise immédiatement, le seul réconfort dans ces situations étant de penser que les autres sont aussi bêtes que nous.
Si j’ai bien travaillé, et même si vous meniez jusqu’à maintenant une vie tranquille, vous êtes maintenant angoissé et vous demandez quels éléments de vos solutions il vous est interdit de renommer.
Non, non, il n’y a pas de quoi, c’est en toute amitié.
Alors nous y voilà, voici la technique promise. Elle tient en une fonction personnalisée, publiée depuis quelques temps sur FMFunctions.com :
FM_Name_ID ( _Name_ID ; _TLFSV ; _fileName ; _layoutName )
Commençons par décrire cette fonction, nous verrons ensuite pourquoi et comment l’utiliser.
Les paramètres sont :
Passons maintenant notre modèle “Clients_Liste” à la moulinette :
FM_Name_ID ( "Clients_Liste" ; "L" ; "" ; "" )
On obtient le résultat 121. Ça ne marche pas chez vous ? vous obtenez 63 ? Mais c’est normal ! L’identifiant du modèle “Clients_Liste” est 121 dans mon fichier, et 63 dans le votre. Mais c’est un identifiant, c’est à dire que son intérêt est qu’il ne changera jamais. Le jour où vous le renommerez “Clients_tableau”, il aura toujours l’identifiant 63 (ceux qui pensaient 121 ont besoin de faire une petite pause ;))
Tiens, mais c’est intéressant, ça, un identifiant !
Et si dans le script, au lieu d’appeler mon modèle par son nom, je l’appelais par son identifiant ? mon problème serait réglé ! Il suffit donc de sélectionner, dans l’action de script Activer Modèle, l’option (calcul par ID).
Ah ! on me dit dans l’oreillette que cette option n’existe pas… quel dommage !
Heureusement, notre fonction magique va régler le problème, car elle fonctionne dans les deux sens !
Je sais que mon identifiant est 121 (oui, chez moi, je vous rappelle que c’est 121), je vais donc appeler le modèle avec Activer Modèle (calcul par Nom) avec le calcul suivant :
FM_Name_ID ( 121 ; "L" ; "" ; "" )
Le résultat est… mais oui, vous avez deviné : “Clients_Liste” Et dans quelque semaines, il sera “Clients_Tableau” Donc mon script fonctionnera tout le temps !
Certains feront sûrement remarquer que FM_Name_ID ( 121 ; “L” ; “” ; “” ), ce n’est pas très lisible.
On ne peut pas vraiment leur donner tort.
Une fois de plus, je ne saurais mieux conseiller que de commenter ! Rien ne vous empêche d’écrire :
FM_Name_ID ( 121 ; "L" ; "" ; "" ) // Clients_liste
et le jour où le modèle devient “Clients_tableau”, ben ma fois ce n’est pas bien grave. Le commentaire sera suffisant pour comprendre de quoi il s’agit, et on pourra le changer à l’occasion, sans avoir nuit au fonctionnement de la solution.
D’autres feront remarquer (car ils sont très perspicaces, tendance sceptiques), que c’est bien joli d’aller chercher l’identifiant des scripts, modèles, rubriques… mais que cela prend du temps.
Deux choses que vous pouvez faire :
Voilà, c’est tout pour aujourd’hui. J’espère que vous avez apprécié les illustrations ainsi que la musique originale.
Cet article a été publié en Français dans Le Blog FM, et en Anglais dans FileMaker Advisor (réservé aux abonnés)
Matt Petrowsky a également publié une vidéo dans FileMaker Magazine
Kevin Frank a également écrit un article sur le sujet sur FileMaker Hacks
A la suite d’un fil de discussion sur le forum FM Source, je me suis dit qu’il fallait peut-être, trois ans après la sortie de FileMaker 8 et des variables, faire un point sur les différences entre variables et rubriques globales.
Tout d’abord, il existe trois différentes variables, qui se différencient par leur étendue (scope)
* Definir ( var = “bonjour” ; Definir ( var2 = var & ” tout le monde” ; var & var 2 )) ne fonctionnera pas car var n’est pas passée à la deuxième fonction Definir
** Definir ( var = 1 ; Evaluation ( var + 1 )) ne fonctionnera pas car var n’est pas passée à la fonction Evaluation.
Ainsi donc ces variables à deux dollars (et j’ai pas dit deux balles), ne sont en fait pas globales du tout mais “de session”. C’est à dire que leur limite est celle d’une session utilisateur pour un fichier donné.
Comme leur petites sœurs à un seul $, on les déclare avec la fonction Définir() ou avec l’action de script Définir variable().
Les rubriques globales, elles, s’apparentent beaucoup plus à des variables globales, puisqu’elles sont valables pour une session de l’application (donc multi-fichiers), et qu’elle contiennent une valeur au début de cette session.
Notons que la valeur contenue dans une rubrique globale est accessible depuis n’importe quel contexte d’une solution sans avoir à définir de lien. Elles passent même la barrière des fichiers, alors que les variables globales sont propre à une session pour un fichier.
Ce dernier aspect est particulièrement intéressant pour définir des listes de valeurs relationnelles, accessibles depuis n’importe où, plutôt que de re-créer des liens et une liste de valeurs à chaque fois qu’on en a besoin. Ces listes fonctionnent même en mode recherche !
Nous retrouvons donc en finale de ce tournoi, à ma gauche, les variables globales (c’est pas tous les jours que les $$ sont à gauche), et à ma droite, les rubriques globales (je les mets à droite parce qu’elle conservent une donnée, elles sont donc plus conservatrices – désolé, je suis aussi drôle que Goscinny depuis qu’il s’appelle Uderzo, c’est lamentable)
En finale, oui, parce que nous n’avons pour l’instant étudié que leur étendue, mais il reste encore beaucoup à voir. Et d’ailleurs, avons nous vraiment vu tout ce qui concerne l’étendue ?
Pour ce qui concerne les variables “globales”, c’est assez simple, elle sont définie au cours de la session, et sont “tuées” à la fermeture.
Il en est autrement pour les rubriques globales, qui conservent une valeur par défaut, valable pour tous les utilisateurs au début de chaque session.
Pour initialiser la valeur d’une rubrique globale, il faut être l’hôte du fichier. Autrement dit, on ne peut en principe pas modifier cette valeur par défaut si le fichier est servi (partagé par FileMaker Server ou par FileMaker Pro sur un autre poste). Concrètement, chaque utilisateur pourra modifier la valeur d”une rubrique globale au cours de sa session, mais retrouvera la valeur par défaut en fermant et ré-ouvrant le fichier.
Truc : il existe malgré tout une méthode pour modifier la valeur d’une globale sur le serveur. Elle nécessite (heureusement) l’accès intégral au fichier.
Voilà pour l’étendue, je crois que cette fois, nous en avons fait le tour.
Le stockage d’une rubrique globale ou d’une variable globale se fait au niveau du poste client, ce qui est bien pratique. Cela veut dire que la valeur est propre à l’utilisateur, et aussi qu’il n’y a pas besoin d’aller chercher une valeur sur le serveur à chaque fois qu’on en a besoin.
Une rubrique comme une variable peut être multivaluée, mais cela ne présente pas beaucoup d’intérêt pour une variable, car on ne peut pas, contrairement à une rubrique globale, récupérer la liste des valeurs avec la fonction Liste, ou la dernière valeur renseignée avec la fonction Dernière(). En revanche, on peut attribuer n’importe quel entier comme numéro de répétition, qu’il soit négatif, nul ou positif. Considérez que les répétitions d’une variable sont en fait des variables totalement différentes, et vous aurez tout compris.
Voyons maintenant quel type de données les variables peuvent contenir, par comparaison aux rubriques globales. Tout d’abord, il faut noter la différence dans la manière dont on type ces données. Dans le cas des rubriques globales, on choisit un type pour la rubrique dans le petit menu où nous retrouvons Texte/Nombre/Heure/Date/Horodatage/Multimedia. Je ne parle pas du type calcul, qui n’est pas à proprement parler un type, puisque le type de résultat d’un calcul se définit en bas à gauche de la définition de calcul. Il peut être global également. Bref, tout ceci prend du sens si on se dit que dans d’autres langages, un “calcul” s’appelle une “requête”, mais bon, le huitième jour, Il avait vraiment mal au crâne.
Dans le cas des variables, le typage se fait automatiquement, mais c’est parfois quelque chose de méconnu. Si on définit une variable telle que = “bonjour le monde”, le fait de mettre une constante de texte entre guillemets (ou de faire appel à une rubrique de type texte) typera la variable comme texte. Si on n’utilise que des données de type date, la variable sera de type date…
Je recommande souvent de forcer le type de variable à l’aide des fonctions ObtenirTexte(), ObtenirNombre(), ObtenirDate(), ObtenirHorodatage()…
Cela rend le code plus lisible et évite les mauvaises surprises.
En revanche, et c’est également méconnu, les variables peuvent contenir tous les types de données gérés par FileMaker. Tous ? oui ! Cela veut dire que l’on peut parfaitement stocker une image ou un fichier dans une variable globale.
Truc : on notera toutefois un bug pénalisant si vous essayez de stocker un long texte dans une variable globale. L’application se verra dramatiquement ralentie. Ceci ne se produit pas si vous découpez votre texte en plusieurs variables ou… que vous choisissez de le stocker dans une rubriques globale.
Cela semble assez évident, mais cela a de grandes conséquences : on ne définit pas une rubrique globale comme une variable globale.
Une variable globale peut être définie soit par script (Définir Variable()), soit par simple calcul, grâce à la fonction Définir() : Définir ( $$maVariable = “bonjour le monde !” ; “” )
C’est là un immense avantage, car on peut alors dès lors définir des variables sur chaque intervention du moteur de calcul : auto-entrée, contrôle, calcul pour ce qui concerne la définition de la base de données, mais aussi jeux de privilèges, et surtout au niveau du modèle (infobulle, web viewer, formatage conditionnel, et même [[jeux de menus personnalisés]FileMaker Pro Advanced est requis pour mettre en place ces possibilités]).
Pour définir une rubrique globale, vous devez utiliser l’action de script Définir rubrique(). Personnellement, je rêve d’une fonction de calcul qui définirait une rubrique. On peut faire ce genre de choses (et bien plus) avec un plug-in comme DoSQL de myFMbutler, mais pas avec FileMaker tout seul.
On en oublierait presque qu’à l’inverse, il existe une méthode de définition de la rubrique globale qui n’existe pas pour la variable, et pas des moindres ! Allez, allez, laquelle ? Votre langue au chat ? Ben… c’est l’utilisateur, pardi ! L’utilisateur est également un très bon moyen de définir une globale. Muni de son petit clavier et de sa petite souris, mais aussi des menus déroulant, cases à cocher, et autres boîtes de dialogue que vous aurez bien voulu mettre à sa disposition.
Du fait que la rubrique globale est propre à l’utilisateur, on l’exploitera justement pour tout ce qui est interface (filtres de table externe, images, libellés que l’on veut voir persister en mode recherche…). L’avantage de la rubrique est ici double : modifiable par l’utilisateur (par exemple pour filtrer une table externe via un menu déroulant), et surtout, affichable sur le modèle ! Second rêve du jour : pourvoir insérer un calcul directement sur le modèle, et en particulier une variable globale. On peut déjà, et depuis toujours, insérer une “rubrique de fusion”, le nom de l’utilisateur, la date courante… je parie qu’insérer une variable ne coûterait pas des mois de développement à FMI !
Une “rubrique globale” peut également servir de “rubrique clef” au départ d’un “lien” (je vous assure, FileMaker est vraiment un langage codé !), ce qui n’est pas possible avec une variable (troisième songe ?). Ainsi, tous les liens relatifs à l’interface (la vue de l’utilisateur courant) doivent être basés sur des rubriques globales.
Voilà, j’espère avoir fait à peu près le tour, et que ça aidera certains à y voir plus clair
Cet article a été publié sur Le Blog FM et a été repris par FileMaker Inc. dans sa Newsletter d’Octobre 2008.
Suite à la FM Conf, j’ai reçu plusieurs demandes d’explication sur un aspect que j’avais abordé un peu vite : la possibilité de piloter l’interface de FileMaker 11 au clavier. Voici donc un petit addendum.
Bien que FileMaker 11 ait grandement amélioré cet effet désagréable, les problèmes de clignotement sur PC sont toujours un frein à l’utilisation de l’action de script Rafraichir Fenêtre. Voici une technique toute simple qui règle ce problème.
Voici certainement l’article le plus important depuis la création de 1-more-tube : les transactions dans FileMaker.
Tout le mérite revient à Todd Geist, qui a exploré les techniques de transactions, et vous trouverez ses articles sur le sujet sur le site de Geist Interactive.
Cet article est une introduction en français, qui permettra de comprendre l’intérêt que représentent les transactions, en termes d’intégrité des données et de performances.
Si vous développez des bases de données pour FileMaker Go (la version de FileMaker pour iPhone et iPad), cette technique transactionnelle est tout simplement indispensable.
Vous pensez déjà à conserver, pour chaque enregistrement, les dates et heures de création et modification ?
Mais avez-vous pensé aux problèmes qu’engendrerait un éventuel décalage entre les réglages d’heure des différents postes clients ?
Dans cette astuce, vous découvrirez comment pallier à ce problème et utiliser l’heure du serveur comme référence unique.
“XML”, voilà un terme qui fait peur !
Et pourtant, l’utilisation du XML est un grand facteur de simplification !
Avec un temps d’apprentissage quasi-nul, vous ne pourrez plus vous passer des fonctions d’écriture et de traitement du XML au sein de FileMaker.
Dans cette vidéo, nous explorons trois fonctions personnalisées simplissimes, qui changeront votre vie de développeur si vous ne les utilisez pas déjà.
Passage de paramètres multiples et complexes, résultats de scripts structurés et utiles, mais également simplification du graphique relationnel. Voici quelques uns des principaux bénéfices de l’utilisation de ces fonctions.
Dans cette astuce, nous fournirons une technique pour proposer un bouton de suppression unique sous (ou au dessus, ou à côté…) de la table externe, plutôt que sur chaque rangée.
Gagnez de la place, et ne donnez plus à voir des interfaces aussi pleines de poubelles qu’une rue de Bruxelles un mardi soir !
Suite et fin de notre série consacrée à la création de fonctions personnalisées.
Dans cette vidéo, nous abordons la notion de tail recursion, explorons ses avantages et ses pièges.
Nous apprenons également quelques trucs pour écrire des fonctions plus faciles à utiliser.
Voici quelques techniques présentées lors de la FileMaker Conférence 2010 à Paris (Session 21 : FileMaker 11 pour développeurs)
Les graphiques comme outil de design. Réaliser un fond en dégradé grâce à un graphique et une rubrique calculée.
Nouveaux déclencheurs
Intervenir sur les données pour effectuer des traitements avant validation (par exemple faciliter la saisie d’une date
Contrôlez la condition de fermeture d’une fenêtre sans passer par les menus personnalisés.
Menus dynamiques
Fonction cachée de FileMaker Pro Advanced 11 ! Il est désormais possible de faire de vrais menus dynamiques.
Recherche rapide (QuickFilter)
Une amélioration du fichier Clairvoyance, présenté lors de la FMConf 2009. Cette version est optimisée, traite tous les types de données, et tire partie de la recherche rapide.
Here are some techniques presented during the 2010 FileMaker Conference in Paris (Session 21 : FileMaker 11 for developers)
Charts as a design tool
New script triggers
Process your data before it’s rejected by field validation options (e.g. make it easy to enter a date)
Prevent closing of a window without a specific custom menu set.
Dynamic menus
Quick Filter
Les fonctions personnalisées, apparues avec FileMaker 7, ont changé la vie des développeurs.
Pourtant, il n’est pas rare que ces fonctions fassent peur. Dans cette vidéo, nous verrons l’intérêt d’utiliser des fonctions personnalisées, et nous apprendrons à concevoir une fonction récursive.
Si vous savez ce qu’est une boucle dans un script, vous verrez que les fonctions récursives ne sont pas plus compliquées !