Aller au contenu

Ugo

Membres
  • Compteur de contenus

    4 350
  • Inscription

  • Dernière visite

  • Jours gagnés

    30

Ugo a gagné pour la dernière fois le 11 juillet

Ugo a eu le contenu le plus aimé !

2 abonnés

À propos de Ugo

  • Rang
    3200
  • Date de naissance 11/12/1968

Contacts

  • Website URL
    http://www.dlsystems.fr
  • AIM
    ugodiluca
  • Skype
    ugodiluca

Profil général

  • Genre
    Homme
  • Lieu
    Paris

Profil FileMaker

  • FM Conférence
    Paris 2010
  • Certification
    FileMaker 9 Certified Developer
  • FBA
    --Non membre--

Visiteurs récents du profil

21 347 visualisations du profil
  1. Bonsoir à tous, Même si le sujet est assez éloigné de FileMaker, ce n'est jamais très loin tout de même avec Agnès... Retrouvez le passage d'Agnès dans les "3 minutes de gloire" sur RadioBrunet RMC. Dans l'esprit communautaire qui nous caractérise, n'hésitez pas surtout à partager autour de vous cette video ( plus on en parle... ), et naturellement à aimer la page Facebook de TiSac ici Les 3 minutes de Gloire d'Agnès La même qu'en conférence, mais à la radio, et bien plus claire
  2. Bonjour Ugo

    Je relis un ancien message écrit par toi en 2005 et j'y trouve des pistes de développement pour mon problème évoqué ici tableau croisé dynamique.

    Aurais-tu conservé le schéma de l'époque ?

    Aurais-tu aujourd'hui avec fm 11 à 14 une solution équivalente.

    Dans mon tableau les colonnes ne sont pas basées sur une ligne de temps mais sur des données non hiérarchisées.

    Je te remercie.

  3. fin de boucle si...

    Bonsoir, La formule de sortie de boucle reprend les 3 conditions à remplir, donc ne serait-ce pas plutôt not EstVide ( rubrique A ) and not EstVide ( rubrique B ) and not ( rubrique B < rubrique A ) ou not ( EstVide ( rubrique A ) or EstVide ( rubrique B ) or ( rubrique B < rubrique A ) )
  4. FmDynamix, c'est parti !

    Bonsoir, Je me permet de compléter ou de synthétiser car un code inaccessible a tendance à tuer toute tentative de compréhension ou de réflexion. Je n'ai jamais compris pourquoi Agnès cherche à ce point à expliquer un code incompréhensible par un autre qui l'est tout autant sinon plus, mais on la pardonne toujours FmDynamix est un projet qui comprend à ce jour 2 modules mais qui sera probablement amené à s’étoffer. L’objectif est de maximiser la ré-utilisabilité en apportant une dose de modularité. Le premier module, dont il est principalement question ici, concerne les fonctions personnalisées, et permet, pour simplifier, d’appeler une fonction personnalisée sans qu'elle soit stockée dans le fichier, le nombre de fonctions pouvant être appelé étant illimité, qu’elles soient récursives ou pas. Fini donc la pénible gestion des fonctions personnalisées, cette opération n'est conduite qu'une seule fois pour un ensemble de fichiers, sans nécessité de contrôler chaque fichier individuellement. Le défi consistait donc à trouver un algorithme qui permettait d’exécuter une fonction personnalisée, dont le nombre, mais aussi le type de paramètres, sont variable, au travers une seule fonction qui comprendrait à l'inverse un nombre fixe de paramètres. Concrètement, comment donc appeler au travers une seule et unique fonction des fonctions aussi différentes que : DateRange ( dStartDate; dEndDate ) DateRangeWithLimit ( dStartDate; dEndDate; nRangeLimit ) IsDateInRange ( dTestDate ; dLowerDate; dHigherDate ) calcEndDate ( dStartDate ; nNumberDays; bWeekendsTrueFalse ) Une fonction par définition comprend une formule et un ensemble de paramètres, et lorsqu’elle est exécutée on transmet les arguments en guise de paramètres. Pour rendre ceci possible il convenait de trouver le moyen d’évaluer le code fonctionnel d’une fonction personnalisée en injectant dynamiquement le nombre et le type d’arguments pour chaque paramètre attendu par ce même code fonctionnel. C’est à cet objectif que l’exercice l'importance de l'imbrication a servi, puisqu’il a donné lieu à une fonction, #load() qui se charge donc comme l’explique Agnès En effet, la fonction cfCall qui rend cette exécution possible comprend deux paramètres : ExpressionCode - Code fonctionnel/formule à évaluer, structurée selon une convention précise Parameters - Paramètres nécessaires à l'évaluation de la formule, assemblés en exploitant la fonction #load La fonction #load injecte donc les arguments pour chaque paramètre référencé dans le code d'exécution stocké au format texte dans le paramètre Expression de cfCall Il n'y a pas grand chose d'autre à comprendre, et surtout comme pour CustomList, pas besoin de comprendre le code de ces deux fonctions personnalisées pour pouvoir les utiliser. Dans la mesure où le code de la fonction doit être structuré selon une convention spécifique, vous trouverez un utilitaire dans le fichier qui se charge de transformer le code que vous aurez copié afin qu'il soit compatible. Il existe quelques exceptions qu'Agnès pourra décrire, mais elles sont rares. Au final, chaque fonction est chargée en variable et peut donc être appelée avec par exemple pour la fonction DateRange cfCall ( $$_DateRange ; #load( /*dStartDate*/ "" ) & #load( /*dEndDate*/ "" ) ) Précisions aussi que rien n'interdit de stocker des fonctions personnalisées tout de même dans votre fichier. Enfin, dans l'esprit collaboratif du projet FmDynamix, le module fmx_FunctionCalls, au-delà de la fonctionnalité elle-même, permet de stocker vos fonctions et de les partager au travers un outil dédié. C'est aussi en cela que la démarche peut être utile.
  5. Ugo

  6. boucle sur liste déroulante

    Je me suis mal exprimé à mon tour. #calcul est évalué à la fin de chaque itération, mais sera évalué avant le #test de l'itération suivante. Aucun intérêt à priori dans une expression aussi simple que i++, mais certaines gymnastiques sont donc possibles tout de même au travers cette expression, jusqu'à réinitialiser le compteur i lui-même pour forcer par exemple la duplication d'un traitement pour une même itération i. Ex: var bStop=true;var array=['A','B','C','D']; for (var i = 0; i < array.length; i==2 && bStop?i:i++) { //traitement pour valeur i if(i==2 && bStop){ bStop=false; i-- }} On peut alors considérer qu'inclure les déclarations de variables dans ce "Fin de Boucle Si" peut être considéré tout autant comme la condition du test et l'opération d'itération, et la formule dans ce Fin de Boucle, ici dans FileMaker, pourrait être : Choisir( $i > $j ; Si ( $i=2 And $stop; Definir ( $i = $i ; Definir($stop=False;$stop)) ; Definir ( $i = $i+1 ; False ) ) ; True ) Soit au final pour plus de flexibilité et pour ce même équivalent ( duplication de traitement pour la seconde valeur par exemple ) # initialisationDefinir Variable [$stop;Valeur:True]Definir Variable [ $_void; Valeur: Definir ( [ $enum = un.Ensemble.Quelconque.Délimité ; $i = 0 ; $j = Decompte( $enum )] ;$_void)#Boucle # itération ; test Fin de boucle si [ expressionplushaut ] # traitement sur $enum # ...Fin de boucle
  7. boucle sur liste déroulante

    Bon, Mon quota d'heures sur ce Forum va expirer Dans l'absolu, il faut tout de même considérer que #calcul ( itération ) est évalué à la fin de chaque itération mais toujours évalué avant l'évaluation de #testSortie. Si je devais être tatillon, je rajouterais même que ce second argument, qui d'ailleurs est optionnel, est une condition d'exécution et non une condition de sortie. Ce sont en tout cas des échanges très intéressants, et ça mériterait des démonstrations pratiques.
  8. boucle sur liste déroulante

    Cela dépend en plus des logiques et des cycles recherchés, car une boucle for, ça peut être tout autant for (var i = 0; i < array.length; i++) { } ou for (var i = 1; i <= max; i++) { } ou des traitements inversés for (var i = max; --i > 0;) {} etc. Donc la proposition de Clément d'intégrer la logique dans l'expression calculée du "Fin de Boucle Si" me semble en effet l'approche la plus fidèle et la plus générique.
  9. boucle sur liste déroulante

    Salut, Fabricando fabri fimus
  10. Bonjour, Ce n'est en effet qu'une modélisation, bien souvent ce type d'exercice est de toutes façons peu exploitable et il ne s'agissait pas de répondre précisément au besoin mais d'expliciter la structure "n enregistrements d'une table vs n rubriques d'un enregistrement"
  11. boucle sur liste déroulante

    Bonjour, Si cette instruction est placée après la première instruction d'incrément Définir variable [ $increment ; Valeur :$increment+1 ]Fin de boucle si [ $increment ≥ DecompteValeurs ( $liste ) ] le traitement n'aura pas lieu si la liste ne comprend qu'un élément et ne sera pas accomplie pour tous les éléments de la liste dans le cas contraire. Si cette instruction est placée comme initialement proposé Définir variable [ $valeur ; Valeur :ObtenirValeur ( $liste ; $increment ) ]#ton traitement sur $valeurFin de boucle si [ $increment ≥ DecompteValeurs ( $liste ) ] le traitement aura été exécuté sur une valeur non définie dans le cas où la liste ne comporte pas d'éléments
  12. Bonsoir, J'ai du mal à voir le schéma exact mais je doute que ce soit si complexe. Voici un petit exemple properties.fmp12 properties.fmp12
  13. boucle sur liste déroulante

    Bonsoir, C'est l'énoncé qui n'était pas clair, pour le reste boucler sur une liste, que celle-ci provienne ou pas d'une liste de valeurs ou pas, me semble être assez usuel. La preuve : copiercoller-un-enregistrement
  14. Bonjour, Non Non, c'est une valeur dans un champ d'un enregistrement d'une table. Si on a donc 20 valeurs à cocher, cela constituera 20 enregistrements d'une table, potentiellement stockées dans la même colonne de cette table, ou dans des colonnes distinctes selon qu'on veut gérer différents formats de données ( nombres, dates, texte, etc ) D'une manière générale, il est toujours essentiel avant d'ajouter un champ dans une table de savoir comment on va en extraire les données. Un système de case à cocher ne comporte aucun intérêt et est même assez dangereux dans la mesure où les valeurs qui sont stockées sont issues d'une source qui est liée à l'interface de saisie ( par la liste définie dans le style de contrôle du modèle ). On peut déconnecter cette "source" ou en changer les valeurs sans que le contenu du champ ne soit impacté, et donc se retrouver avec des valeurs saisies qui n'ont plus l'intégrité requise. Même si on peut importer des données Json dans R, et donc disposer alors d'une gestion par propriétés ex : genre:M, Age:15-25, Taille:150-165cm - , le plus simple est tout de même de disposer d'une table dans laquelle chacune de ces propriétés pourra être extraite individuellement ou collectivement, quitte à reconstituer alors l'objet Json en question. La question à se poser est de savoir si au final on aura besoin de disposer des données "non cochées", c'est à dire si les données seront analysées sur la base des critères possibles ou seulement ceux existants. Concrètement, l'analyse aura-telle besoin de restituer le résultat d'une série de valeurs homogènement structurées : ex : pour un individu de 17 ans, attends-ton un résultat du type "-15ans:0, 15-25:1, 26-35:0, 31-50:0, 51-75:0, +75:0" ou "age :15-25"
  15. Calcul simple pour graphique

    Bonjour, Un "Up" après 30 minutes c'est un peu rapide... Ajouter une rubrique Statistique x_decompte, de type "Décompte de" sur n'importe quelle rubrique de la table qui ne soit jamais vide ( idéalement l'identifiant unique de la table ) Dans le graphe : Pour l'étiquette, choisir le champ "reponse" Pour les données le champ x_decompte Utiliser les données de "Jeu d'enregistrements trouvés actuel" Cocher "Afficher les points de données..." Le jeu d'enregistrements trouvés doit être trié sur le champ "reponse"
×