Category: FileMaker

One of the most important features of FileMaker 17 is the “current found set portal”. It makes it easy and fast to display the list of found records on the layout (Master/Detail).

Not only does it display them, but it allows to browse records with a single click, without having to write a script or add a button.

Besides, it reflects the sort order, which means you can now design a real Master/Detail view.

In this demo file, I’ll show you a few tips, among which:

• how to use the new Get ( ActiveRecordNumber ) function to highlight the current record in the portal
• use the found set portal to browse records, and a simple button bar to act as a sortable column header

But also, on a second layout called Detail / Master, you will see what happens if we inverse the perspective and use the current found set portal as the main item of the layout body. We can suddenly use ‘list views’ on a form layout. Benefits:

• avoid the annoying “No record message” of FileMaker list view when user clicks on the body
• edit the record in a form without leaving the list view (right pane)
• add an action / navigation bar on the whole list height (left pane)
• you can now adjust the window and control its height

There is a missing feature though: no sub summary layout parts.

Enjoy!

[vc_row color=”color7″ text_color=”color4″ global_atts=”yes” style=”padding-x: 5px; padding-top: 25px; align: center; ” bg_color=””][vc_column width=”1/4″][ish_icon icon=”icon-download” align=”center”][/vc_column][vc_column width=”3/4″][vc_column_text global_atts=”yes” css_class=”btn btn-primary”]Download a sample file here. 1MT_MasterDetail.zip

Please share if you liked this post.[/vc_column_text][/vc_column][/vc_row][vc_row bg_color=””][vc_column width=”1/1″][vc_row_inner][vc_column_inner width=”1/1″][/vc_column_inner][/vc_row_inner][/vc_column][/vc_row]

Notre approche en tant que développeurs d’applications sur mesure est d’apporter des solutions évolutives à nos clients.
Leurs besoins progressent, et ils souhaitent adapter rapidement leur outil à la réalité de leur métier et de leur structure.

Mises à part quelques petites adaptations mineures qui peuvent être “reportées” en direct dans le fichier de production, la plupart du temps, pour pouvoir mettre en oeuvre de nouvelles fonctionnalités, nous devions nous lancer dans une aventure parfois fastidieuse : le versioning.

Ceci est bientôt de l’histoire ancienne

Souvenez-vous de ce à quoi pouvait ressembler un versioning :

Table par table, nous importions les données dans la nouvelle version.
En préparation de cet import, il avait fallu régler les correspondances de rubriques entre la table source de production et la table destination du nouveau fichier. L’interface que FileMaker propose pour régler l’import est sans doute le plus indigeste des interfaces de la plateforme : difficulté de positionner les rubriques qui “glissent” de haut en bas, contrôle de correspondance uniquement visuel… cette étape de configuration peut s’avérer gourmande en temps de développement (dans cet article de juin 2010 sur la mise à jour des données, nous revenons sur la méthodologie que nous adoptions dans pareille situation).

Après avoir réglé la séquence d’import, nous devions penser à mettre à jour les éventuels compteurs basés sur des numéros de série.

D’autres couches de l’application contiennent également des données qui avaient pu évoluer et être modifiées par les utilisateurs au cours de leur usage du fichier à mettre à jour :

• la sécurité, dans laquelle des comptes ont pu être créés, modifiés, supprimés;
• les listes de valeurs personnalisées dont certaines ont pu être adaptées par des utilisateurs disposants des droits pour ce faire.

Vue la complexité et la lenteur du processus de versioning, nous options souvent pour procéder à ces manoeuvres la nuit, le week-end… prévoyant selon le nombre d’enregistrements à transférer de nombreuses heures où avancerait lentement la barre de progression de la fenêtre d’import.

Parfois nous n’avions pas le choix, suite à une corruption de fichier, nous devions repartir d’une clone sain et injecter les données de production, en espérant ne pas interrompre trop longtemps le travail en cours des utilisateurs bloqués.

Un gain de temps considérable

Avec la version 17 de FileMaker, ceci va changer radicalement ! Mais c’est en dehors de l’application qu’il faut aller chercher cette excitante nouveauté. En accompagnement de FileMaker 17 (dans le package de la Developer Subscription), nous trouvons un petit outil léger en ligne de commande…léger mais d’une puissance telle qu’il va nous permettre de revoir fondamentalement le rythme de mise à jour de nos applications.
(On peut s’interroger sur la raison d’une attente si longue dans l’histoire de la plateforme pour bénéficier d’un tel outil – Fabrice se souvient que ses demandes à FileMaker pour un système du genre remontent à plus de 10 ans, et les développeurs étaient nombreux à appuyer dans ce sens.)

Le DMT, data migration tool, est donc un outil en ligne de commande qui permet d’injecter en un temps record les couches de données d’un fichier source vers un clone de la même base, et ce avec un tout petit minimum de préparation de notre part.

Comme pour le iOS SDK, cet outil vient de le “package” qui accompagne la Developer Subscription (89€HT/an). (Un package qui devient encore plus attractif avec le nouveau modèle de licence…allez jeter un oeil)

Comment utiliser le DMT

(Attention, veuillez prendre connaissance de l’article relatif à un bug important de la version actuelle de l’outil) 

Le principe est simple :

1. Réalisez un clone de la base de données de destination. Précision importante : un clone est une copie du fichier, dénuée des parties données (enregistrements et données locales). Un clone est un clone tant que le fichier n’est pas ouvert. Dès son ouverture, FileMaker y écrit des paramètres locaux (langue, format de date,…) et il perd dès lors son caractère de clone.
2. en ligne de commande, appeler l’outil FMDataMigration, identifier la source, le clone et la destination

FMDataMigration -src_path <path> -clone_path <path> [<other options>]

Et c’est réglé ! … un journal affiche la progression, les résultats et erreurs éventuelles.

Un cas vécu : le temps de versionning d’un fichier comportant environ 40 tables et des millions d’enregistrements est passé de 3h00 à 10 minutes !!  Et c’est évidement sans compter le temps gagné à ne pas devoir paramétrer la séquence d’importation des données pour chacune des tables.

Au final, nous récupérons non seulement les enregistrements, mais aussi les comptes utilisateurs et les modifications dans les listes de valeurs personnalisées, ainsi que les polices de caractères intégrées au fichier.

Ce qui est transféré

(en fonction des options cfr infra) :

• les comptes utilisateurs
• les enregistrements
• les listes de valeurs personnalisées
• le numéro de série suivant des rubriques entrée automatique numéro de série
• les index
• les ID d’enregistrements
• les paramètres régionaux (formats de date, langue par défaut…)

Paramètres de la ligne de commande

(en gras les paramètres obligatoires)

-src_path :  le chemin du fichier source
-src_account : un compte accès intégral dans le fichier source (par défaut = Admin)
-src_pwd : le mot de passe du compte (par défaut = vide)
-src_key : l'éventuelle clé d'encryption du fichier source

-clone_path :  le chemin du fichier clone
-clone_account : un compte accès intégral dans le fichier clone (par défaut = Admin)
-clone_pwd : le mot de passe du compte (par défaut = vide)
-clone_key : l'éventuelle clé d'encryption du fichier clone

-target_path : le chemin du fichier de destination (par défaut = chemin de la source avec ajout de 'migrated' )
-ignore_valuelists : par défaut le DMT va recopier les valeurs des listes de valeurs personnalisées du fichier source. Ajoutez cette option pour ne garder que les valeurs du fichier clone
-ignore_accounts : par défaut le DMT va recopier les comptes du fichier source ainsi que la clé d'encryption. Ajoutez cette option pour ne garder que les comptes du fichier clone
-ignore_fonts : par défaut le DMT va recopier les polices du fichier source. Ajoutez cette option pour ne garder que les polices du fichier clone

-v : (verbose) mode avec log de progression qui décrit étape par étape ce que le DMT est en train de faire
-q : (quiet) mode silencieux
-force : permet d'écraser un fichier de destination déjà existant

Quelques remarques et points d’attention:

Comment se fait la correspondance ?

Pour la correspondance des tables et rubriques, FM Data Migration Tool procède d’abord par nom et ID identique, puis s’il ne trouve pas par nom identique, puis enfin par ID interne correspondant. Cela signifie par exemple que si vous renommez la rubrique RUBOld en RUBNew et puis que vous créez une rubrique nommée RUBOld, les données de la source contenue dans la rubrique RUBOld seront transférées dans la nouvelle rubrique RUBOld.

Des conteneurs

L’outil est prévu pour que le fichier résultat soit ensuite placé au même endroit qu’à l’origine. Ce point doit être pris en considération dans le cas de stockage externe de conteneurs : l’outil ne gère pas de déplacement ou de conversion de ces fichiers.

Clone tu resteras

Petit rappel : un  clone reste un clone tant qu’il n’a pas été ouvert !

Réparation du code ?

Le DMT n’est pas un outil de réparation. Si on a dans la source une donnée corrompue, elle le restera après versioning.

Attention plug-in

Lors du versioning, le DMT “réévalue” les valeurs des rubriques calculs stockées. Ceci peut poser un gros problème si ces calculs font appel à des fonctions issues de plug-in. Le DMT n’ayant pas accès aux plug-in, les résultats de ces calculs sera un ? dans tous les enregistrements. Il faudra par la suite évaluer à nouveau ces calculs en entrant dans la définition de la base de données et en éditant la formule de calcul (y ajouter un espace suffit).

Sécurité : login et mot de passe

Dans les instructions en ligne de commande, il faut passer en clair un login et mot de passe du fichier clone et du fichier source. Ce login et mot de passe peut être soit celui d’un compte disposant de l’accès intégral au fichier…dans ce cas, vous exposez aux regards indiscrets et laissez dans l’historique du terminal un mot de passe critique. Soit vous pouvez mentionner un compte et mot de passe qui est associé à un jeu de privilège qui dispose d’un privilège étendu dont le nom commence par “fmmigration”. Le nom du privilège étendu doit être rigoureusement le même dans le fichier source et dans le clone (sensible à la casse).  Le jeu de privilège ne doit disposer d’aucun droit particulier dans la base de données (ni lecture des données, ni accès aux modèles, scripts,…). C’est sans aucun doute la manière la plus sûre de gérer cet aspect sécurité lors de l’usage du DMT.
Dans l’exemple ci-dessous. Nous avons créé un compte “mig” dont le mot de passe est “123456”; ce compte est associé au jeu de privilège “Mig” qui n’a aucun droit de lecture, d’accès au modèle, scripts,..dans la base. Ce jeu de privilège dispose d’un privilège étendu dont le nom commence par fmmigration : “fmmigrationTest”.

La commande devient la suivante :

 ./FMDataMigration -src_path Old.fmp12 -src_account mig -src_pwd 123456  -clone_path New.fmp12 -clone_account mig -clone_pwd 123456

Pour disposer de l’outil Data Migration Tool

Comme pour le iOS SDK, cet outil vient de le “package” qui accompagne la Developer Subscription (89€HT/an). 

 

Enjoy !

Deuxième épisode de la mini série consacrée au tri dans FileMaker.

Introduction

Configurer les différents tris possibles dans un mode liste, en cliquant sur les libellés en tête des colonnes, peut s’avérer rapidement laborieux à faire, d’autant plus si votre solution comporte de nombreux modèles en mode liste avec le même système de tri.

En effet, FileMaker ne propose malheureusement aucun mécanisme natif permettant de choisir les rubriques de tri de manière dynamique, ce qui force à concevoir des scripts de tri remplis de très nombreuses conditions afin de lancer le bon tri suivant l’en-tête de colonne cliquée, et donc la valeur passée en paramètre au script de tri.

Par bonheur, quelques techniques existent pour contourner partiellement cette limitation et ainsi bénéficier d’un choix dynamique pour les rubriques de tri.

Dans cet article nous allons explorer l’une de ces techniques, elle ne concernera que les développeurs et utilisateurs de FileMaker (FM) sous environnement macOs, car elle est basée sur la technologie AppleScript (AS).

Exécuter du code AppleScript dans et depuis FileMaker Pro est possible depuis les toutes premières versions du logiciel, cela reste encore l’un de ses points forts sous macOS (même si, pour des raisons de compatibilité avec d’autres plate-formes, il est hélas souvent délaissé dans les projets professionnels).

Nous allons donc voir comment mettre rapidement en place un script de tri dynamique et générique, utilisable tel quel dans tous vos modèles liste, avec juste un zeste de code AppleScript.

Préparation

Pour commencer, de quoi allons nous avoir besoin ?

De très peu de choses : juste de deux rubriques globales de travail, qui peuvent être crées dans n’importe quelle table, mais qui trouveraient une place naturelle dans une table “Paramètres” (ou “Settings”).

Voici quelques explications à propos de ces deux rubriques (le suffixe “_g” est pour signaler leur portée globale) :

1. Tout d’abord, une rubrique de type texte, nommée par exemple “tri_rubrique_g”, qui contiendra le nom complet (table::rubrique) de la rubrique de tri ;
2. Ensuite, une rubrique de type nombre, nommée “tri_ordre_g” par exemple, qui contiendra une valeur booléenne indiquant l’ordre de tri : 0 = ordre descendant , 1 = ordre ascendant (pour s’assurer d’avoir toujours une valeur booléenne, on peut activer une entrée auto calculée avec le code suivant : ObtenirCommeBooleen ( Contenu ) ) ;

Le principe est simple : on passe le nom complet (table::rubrique) de la rubrique à trier en paramètre au script FileMaker de tri, si ce nom est identique à celui déjà mémorisé dans la rubrique globale “tri_rubrique_g”, alors on inverse tout simplement l’ordre de tri de la rubrique “tri_ordre_g”.

Si le nom passé en paramètre est différent de celui mémorisé, alors on mémorise ce nouveau nom dans la rubrique “tri_rubrique_g” et on règle la valeur de l’ordre de tri “tri_ordre_g” à 1 (tri ascendant par défaut).

Bon, pas trop compliqué jusqu’à là… voyons maintenant quel code AppleScript nous allons utiliser et comment l’exécuter…

AppleScript

FileMaker propose deux mécanismes pour exécuter un code AppleScript au sein d’un script avec l’action “Exécuter AppleScript” (présent dans la section “Divers” de la liste des actions) :

1. “AppleScript Calculé” : il s’agit d’y inscrire le code AppleScript comme si c’était du simple texte, FileMaker fera une interprétation puis une compilation à la volée du code avant son exécution, à chaque fois que le script FileMaker sera lancé. Dans ce mode, le passage de paramètres au code AppleScript est plutôt simple, il se fait par simple concaténation à l’intérieur du code ;
2. “AppleScript Natif” : il s’agit d’y inscrire le code AppleScript brut, qui sera compilé une seule fois à la validation du dialogue, puis il sera prêt à être exécuté tel-quel à chaque lancement du script FileMaker. Ici, le passage de paramètres au code AppleScript est un peu plus compliqué à mettre en place, il faudra par exemple prévoir des rubriques dédiées (nous ne verrons pas ce cas de figure ici).

Nous allons donc utiliser du code AppleScript calculé, plus simple à implémenter avec le passage des paramètres.

Plusieurs techniques sont possibles, comme :

1. Utiliser le code AppleScript directement dans le dialogue de l’action de script (solution la plus directe, souvent suffisante) ;
2. Placer le code AppleScript dans une rubrique globale et utiliser des balises pour être remplacées par les bons paramètres ;
3. Placer le code AppleScript dans une fonction personnalisée, puis utiliser les paramètres de la fonction FileMaker pour passer les paramètres à AppleScript.

Comme ici nous travaillons en local, la solution 2 avec la rubrique globale est celle que nous allons utiliser, plus simple d’accès pour notre démo. En revanche, pour une utilisation avec des fichiers hebergés dans un serveur, la solution 3 avec une fonction personnalisée semble la plus appropriée.

Dans tous les cas, le code AppleScript demeure le même, seule la technique du passage des paramètres diffère.

Voyons donc notre code AppleScript avec quelques commentaires (précédés de deux tirets “–“) pour bien comprendre le rôle de chaque instruction :

-- Structure 'try' de contrôle au cas où une erreur se produisait pendant l'exécution
try
 
    -- On récupère les valeurs de la rubrique et de l'ordre de tri dans des variables AS
    -- Pour ce faire, on utilise deux balises, délimitées par deux caractères dièse "##",
    -- qui seront remplacées par les valeurs issues des rubriques globales de travail

    -- Le nom complet (table::rubrique) de la rubrique de tri
    set sRubrique to "##tri_rubrique##"

    -- Le numéro booléen correspondant à l'ordre de tri
    set nOrdre to ##tri_ordre##
 
    -- On active FileMaker pour lancer le tri
    tell current application
 
        -- On récupère la bonne propriété d'ordre de tri à utiliser
        set pOrdre to contents of item (nOrdre + 1) of {descending, ascending}
 
        -- On lance le tri dans le modèle actif sur la bonne rubrique et le bon ordre
        sort current layout by field sRubrique in order pOrdre
 
    end tell

on error err_mssg number err_num
 
    -- On affiche un dialogue d'infos si une erreur se produit lors de l'exécution
    display dialog ("" & err_num & " : " & err_mssg)
end try

Les deux balises “##tri_rubrique##” et “##tri_ordre##” seront remplacées avec la fonction “Substituer()”, au sein du script FileMaker, par les valeurs issues des rubriques globales de travail “tri_rubrique_g” et “tri_ordre_g” respectivement.

Voyons maintenant de quoi il sera fait le code de notre script FileMaker…

Script FileMaker

Nous allons commencer par initialiser une variable “$rubrique” avec la valeur passée en paramètre au script. En effet, chaque bouton qui fera appel à ce script de tri, passera en paramètre le nom complet (table::rubrique) de la rubrique de tri.

Si le paramètre est vide, alors on annule le tri.

Comme expliqué plus haut, on défini l’ordre de tri selon que la valeur de la variable “$rubrique” et le contenu de la rubrique globale “tri_rubrique_g”, si elles sont identiques, alors on se contente d’inverser l’ordre de tri, sinon, on règle l’ordre de tri à la valeur par défaut = 1 (tri ascendant).

Ensuite on rensigne la rubrique globale “tri_rubrique_g” avec la variable “$rubrique”, on peut désormais faire le remplacement des balises “##” dans le code AppleScript avant de lancer son exécution.

Voici le code du script FileMaker complet avec les commentaires :

# Commandes de contrôle… comme d'hab…
Gestion erreurs [ Oui ]
Autor. annulation utilisateur [ Non ]
# 
# On récupère le paramètre de script et on efface tout éventuel espace de bord inutile
Définir variable [ $rubrique ; Valeur: SupprimerEspace ( Obtenir ( ParamètreScript ) ) ] 
# 
# Si une touche morte est enfoncée ou si la rubrique de tri est vide, alors on initialise les rubriques globales, on annule le tri et on active le premier enregistrement
Si [ ( Obtenir ( TouchesSpécialesActives ) ) Or ( EstVide ( $rubrique ) ) ] 
    Définir rubrique [ Settings::tri_rubrique_g ; "" ] 
    Définir rubrique [ Settings::tri_ordre_g ; 1 ] 
    Annuler tri des enreg.
    Afficher enreg/requête/page [ Premièr(e) ]
    Fin de script [ Résultat de texte: "Annulation du tri…" ] 
Fin de si
# 
# On défini et mémorise l'ordre de tri dans sa rubrique globale selon la rubrique de tri choisie : si même rubrique, alors on inverse l'ordre de tri, sinon on utilise la valeur par défaut 1 (ordre ascendant)
Définir rubrique [ Settings::tri_ordre_g ; ObtenirCommeBooleen ( Si ( EstEgal ( $rubrique ; Settings::tri_rubrique_g ) ; Not Settings::tri_ordre_g ; 1 ) ) ] 
# 
# On mémorise la nouvelle rubrique de tri choisie dans sa rubrique globale
Définir rubrique [ Settings::tri_rubrique_g ; $rubrique ] 
# 
# On valide tout ça…
Valider enreg./requêtes [ Avec boîte de dialogue: Non ] 
# 
# On initialise une variable avec le code AppleScript à exécuter, en remplaçant au passage les balises par les vraies valeurs de travail
Définir variable [ $applescript ; Valeur: Substituer ( 	Settings::tri_applescript_g ; 	[ "##tri_rubrique##" ; Settings::tri_rubrique_g ] ; 	[ "##tri_ordre##" ; Settings::tri_ordre_g ] ) ] 
# 
# On exécute le tri avec un AppleScript calculé
Exécuter AppleScript [ $applescript ] 
# 
# À la fin du tri, on active le premier enregistrement
Afficher enreg/requête/page [ Premièr(e) ]
# 
Fin de script [ Résultat de texte: "Tri effectué…" ] 
# 
# Code récupéré grâce au plugin MBS

Petite subtitilité ergonomique, nous avons ajouté un test sur les éventuelles touches spéciales actives lors du clic sur les boutons de tri, cela permet d’annuler le tri par simple clic d’un en-tête de colonne avec une touche morte enfoncée (commande, contrôle, option ou shift), cela évite de passer par un bouton dédié (même si cela reste toujours intéressant à proposer, surtout nécessaire si votre solution est utilisée avec FileMaker Go).

Voyons maintenant comment implémenter tout ceci dans notre modèle…

Implémantation

Nous allons donc construire un modèle liste, dans notre fichier de démo (communes de France), nous avons placé 4 rubriques, à savoir :

1. Code postal de la commune ;
2. Nom de la commune ;
3. Une date calculée aléatoirement entre les années 2000 et 2020 ;
4. Un numéro d’index aléatoire de 1 à 999.

Nous disposons donc, pour nos tests de tri, de deux rubriques de type texte (1 et 2) et de deux rubriques de type nombre (3 et 4).

Chaque en-tête de colonne sera donc un bouton qui lancera notre script FileMaker de tri, en passant comme paramètre le nom complet (table::rubrique) de la rubrique à trier (nous utilisons ici la fonction native ObtenirNomRubrique ( table::rubrique ) pour s’assurer d’avoir toujours le nom correct, quelque soient les modifications ultérieures).

Nous pouvons ajouter une mise en forme conditionnelle qui, en comparant le nom de la rubrique à trier avec celui existant dans la rubrique globale “tri_rubrique_g”, pourra changer l’aspect du bouton pour bien visualiser sur quelle colonne le tri a bien été effectué.

Nous pouvons également ajouter un indicateur de l’ordre de tri, dans notre fichier de démo nous utilisons la valeur de la rubrique globale “tri_ordre_g” comme affichage booléen avec deux caractères unicode représentant des flêches, une vers le haut “▲” (tri ascendant), l’autre vers le bas “▼” (tri descendant). L’affichage de cet indicateur sera géré par un masquage conditionnel sur le même principe, mais inversé, que celui de la mise en forme conditionnelle.

Voilà, nous avons pratiquement fini, il suffit d’ajouter des sous-récapitulatifs après tri sur les rubriques dont nous désirons faire des regroupements, tel qu’illustré par Tanguy dans le premier opus de cette mini série sur le tri.

Conclusion

AppleScript offre beaucoup de possibilités avec FileMaker, comme celle présentée ici, même si d’autres solutions de tri dynamiques existent pour ce type d’utilisations en mode liste, certains natives FileMaker.

En tout cas, n’hésitez-pas à décortiquer le fichier de démo en pièce jointe ci-dessous, pour bien visualiser et comprendre toutes les techniques décrites ici, vous pourrez ensuite nous faire part de toutes vos questions et remarques dans les commentaires ci-dessous.

Téléchargez le fichier de démo ici :  1MT_Tri_S02E01.fmp12

 

[vc_row bg_color=””][vc_column][vc_column_text]Voici peut-être un sujet un peu pointu, mais il ne fait jamais de mal d’interroger parfois les fondamentaux… essayons ici de faire le tour complet de la problématique de la casse en FileMaker.

D’abord, pour ne pas se perdre tout de suite, qu’est-ce que la “casse” ?

Ici, je parierais que beaucoup de ceux qui savent déjà ce qu’est la sensibilité à la casse ne savent pas d’où vient le mot.

Ce terme nous vient de l’imprimerie, et plus précisément de la typographie : pour composer une page, il fallait attraper très rapidement des caractères en plomb. On les rangeait alors dans une sorte de caissette en bois compartimentée et que l’on appelait casse. Chaque compartiment contenait les plombs pour un caractère de la fonte (ou police). Or on ne les rangeait pas par ordre alphabétique mais par fréquence d’utilisation. Les minuscules étant bien plus employées que les majuscules, leurs compartiments devaient être proches du typographe, et donc en “bas-de-casse”, les majuscules en “haut-de-casse”.

Pour ceux que cela amuse, je vous invite à réfléchir aux termes encore employés à l’ère de l’informatique : casse, fonte, valise de police…

FileMaker comporte des fonctions de calcul qui nous permettent de manipuler la casse d’un texte :

• Minuscule ( Texte ) pour convertir un texte en minuscules
• Majuscule ( Texte ) pour convertir un texte en majuscules
• NomPropre ( Texte ) pour convertir la première lettre de chaque mot en majuscules et les autres lettres en minuscules

Ainsi que des fonctions qui permettent d’ajouter ou de retirer un style (dont la casse) :

• AjoutStyleTexte ( Texte ; Styles ) – avec les paramètres Uppercase, Lowercase, Titlecase et SmallCaps
• SupprimerStyleTexte ( Texte ; Styles ) – avec les mêmes paramètres

Mais… qu’est-ce donc que la sensibilité à la casse ? C’est très simple : selon les environnements et le contexte, on considérera qu’une majuscule a la même valeur qu’une minuscule (insensibilité à la casse) ou au contraire qu’elle a une valeur différente (sensibilité à la casse)

Par exemple dans un dictionnaire français comprenant des noms propres, comme par exemple le Larousse, on ne fera pas de différence de classement entre une majuscule et une minuscule, ainsi un nom propre avec une majuscule se retrouvera parmi des noms communs, adjectifs ou autre adverbes en minuscules.

 

Dans d’autres contextes, on fera nettement la différence.

Bien souvent dans les langages informatiques, la plupart des traitements sont effectués avec sensibilité à la casse. Cela vient notamment du fait que les premiers ordinateurs travaillaient sur des jeux réduits de caractères (ASCII), et ne pouvaient se permettre de s’encombrer de considérations telles que a = A à chaque fois qu’ils devaient analyser un a.

Mais FileMaker, qui comme vous le savez a été pensé pour des humains normaux (ou presque), fait l’effort depuis très longtemps de l’insensibilité à la casse. Ainsi, vous pouvez comparer des chaînes de caractères telles que “Milan” (la ville) et “milan” (le rapace), et constater une égalité :

"Milan" = "milan"

Ceci fonctionne aussi bien dans les calculs que dans les index (utilisés dans les liens, listes de valeurs ou recherches).

D’ailleurs, on peut noter qu’il en est de même avec les caractères accentués : “à” = “a”, si toutefois la langue d’indexation est le français (en russe par exemple, le E (yé) et le Ë (yo) sont bien deux lettre différentes, avec chacune sa place dans l’alphabet et dans le dictionnaire. Mais il s’agit de caractères différents de l’alphabet latin, bien que visuellement similaires)

On pourrait donc penser que “FileMaker n’est pas sensible à la casse”, un point c’est tout.

Or ce serait bien ennuyeux si on en restait là.

Il existe un nombre limité de cas où FileMaker est sensible à la casse (case sensitive en anglais), essayons d’en faire le tour.

Tout d’abord, certaines fonctions de calcul le sont. On en cite souvent trois en oubliant que FileMaker continue d’évoluer et que ça n’est pas parce qu’en 1914 il y en avait trois qu’il y en a forcément trois aujourd’hui.

Voici donc les trois “connues” :

• Filtre ( TexteAFiltrer ; TexteFiltre ) – Filtre ( “AaBbZ” ; “aZ” ) retournera “aZ” et non “AaZ” : le A majuscule est éliminé par le filtre
• EstEgal ( TexteOrigine ; TexteComparaison ) – EstEgal ( “monMotDePasseSuperSecret” ; “monmotdepassesupersecret” ) retournera 0 car les deux chaînes ne sont pas identiques, alors que, rappelons-le, “monMotDePasseSuperSecret” = “monmotdepassesupersecret” retournera 1 (l’opérateur de comparaison = n’est pas sensible à la casse). Soit dit en passant, si votre mot de passe est super secret, préférez une comparaison de hash MD5 plutôt que de stocker le mot de passe en clair dans la base de données !
• Substituer ( Texte ; ChaîneRecherchée ; ChaîneRemplacée ) – Substituer ( “Bébé” ; “b” ; “d” ) retournera “Bédé” et non “dédé”; car B et b sont deux caractères différents pour cette fonction sensible à la casse.

Et donc on aurait ainsi fait le tour de la question ? Que nenni…

Depuis FileMaker 12, la fonction ExecuterSQL ( RequêteSQL ; séparateurRubrique ; séparateurLigne{; arguments…} ) –  entrouvre la porte au langage de requête SQL au sein de FileMaker (d’un point de vue strict, cette porte était déjà entrouverte pour les connexions ODBC ou les plugins). Or SQL est en grande partie sensible à la casse, même si là encore, l’implémentation de FileMaker est assez tolérante.

Soit une table “maTable” contenant les colonnes “champ1” avec les valeurs A1, A2, A3, et “Champ2″ et les valeurs  B1, B2, B3 :[/vc_column_text][ish_table align=”center” header_bg_color=”color7″ header_text_color=”color4″ border_color=”color7″]

ID	champ1	Champ2
1	A1	B1
2	A2	B2
3	A3	B3

[/ish_table][vc_column_text]La formule suivante :

ExecuteSQL ( "SELECT champ1 from matable where champ2 = 'B3'" ; "" ; "" )

retournera bien “A3”. Autrement dit, le nom des tables et des colonnes n’est pas sensible à la casse, mais c’est maintenant le cas de la plupart des implémentations SQL. Les mots clef comme SELECT, FROM ou WHERE dans cette requête sont toujours insensibles à la casse. Par convention, on les écrit en majuscules, sauf ici où j’ai voulu illustrer l’insensibilité à la casse.

en revanche, la même formule dans laquelle on changera le critère ainsi :

ExecuteSQL ( "SELECT champ1 from matable where champ2 = 'b3'" ; "" ; "" )

retournera du vide, car “b3” n’est pas égal à “B3” dans une requête SQL.

Astuce : si ce comportement vous dérange, vous pouvez utiliser la fonction SQL lower :

ExecuteSQL ( "SELECT champ1 from matable where lower ( champ2 ) = 'b3'" ; "" ; "" )

Donc il y a bien quatre et non trois fonctions sensibles à la casse…

… est-ce tout ?

Non ! depuis FileMaker 16, de nouvelles fonctions sont apparues :

• SortValues ( valeurs {; typeDeDonnée ; locale } )
• UniqueValues ( valeurs{; typeDeDonnée ; locale} )

Au passage, on remarquera que FileMaker a apparemment décidé de ne plus traduire le nom des fonctions de calcul. Le traducteur a dû être sensible à la casse… sociale.

Donc essayons cette formule :

Uniquevalues ( list ( "a" ; "b" ; "B" ; "A" ; "à" ; "À" ) ; 1 ; "" )

le résultat est :

a
b

donc aucune sensibilité à la casse.

en modifiant légèrement, pour explorer :

Uniquevalues ( list ( "A" ; "a" ; "b" ; "B" ; "A" ; "à" ; "À" ) ; 1 ; "" )

le résultat est

A
b

donc on voit que le A majuscule est retourné à la place du a minuscule parce qu’il est trouvé en premier, mais comme on n’est pas ici sensible à la casse, le a minuscule n’est pas retourné en plus.

Mais… n’avais-je pas sous-entendu que ces fonctions étaient justement sensibles à la casse ?

Et bien… c’est qu’elles peuvent l’être !

Le dernier paramètre (facultatif) de ces fonction est locale, et il permet justement de préciser dans quelle “langue” on veut trier ou dédoublonner.

Or s’il est une langue que nous parlons vous et moi couramment, c’est bien… l’Unicode.

Dans l’aide, vous constatez que deux variantes peuvent être utilisées : Unicode_Raw et Unicode_Standard.

Uniquevalues ( list ( "a" ; "b" ; "B" ; "A" ; "à" ; "À" ) ; 1 ; "Unicode_Raw" )

retourne

a
b
B
A
à
À

autrement dit chaque caractère est différent (accentué, non accentué, majuscule, minuscule…). Voici donc deux nouvelles fonctions (SortValues et UniqueValues) sensibles à la casse !

Uniquevalues ( list ( "a" ; "b" ; "B" ; "A" ; "à" ; "À" ) ; 1 ; "Unicode_Standard" )

retourne

a
b
à

on voit qu’on perd la sensibilité à la casse mais pas celle aux accents.

Je crois que nous avons fait le tour de la question de la sensibilité à la casse dans FileMaker. J’espère que vous aurez appris quelque chose. N’hésitez pas à prolonger la discussion dans les commentaires ci-dessous.[/vc_column_text][/vc_column][/vc_row]