Jump to content

Jérémie Gimenez

Membres
  • Content Count

    343
  • Joined

  • Last visited

  • Days Won

    6

Everything posted by Jérémie Gimenez

  1. Bonjour Jean, Tu recevras certainement un mail t'informant qu'une réponse a été postée. Dans ta configuration, ça n'est pas un calcul qu'il te faut, mais un "report d'information à un instant t", donc il faudra un déclencheur de script sur la rubrique Montant qui enverra Obtenir ( NuméroRépétitionActive ) et qui fera inscrire dans la répétition correspondante de la rubrique Date, la date du jour. Autant te le dire : cette technologie (les multivaluées) est très limitée est ne te permettra probablement pas longtemps de continuer ton développement. Mieux vaut utiliser une table à part pour les "lignes". Dans cette table, tu auras une rubrique Date avec une formule en auto-entrée : Si ( Montant ; Obtenir ( DateActuelle ) ) Ensuite, cette table sera matérialisée par une "table externe" sur ton modèle, et tu pourras : - ajouter des lignes une à une (soit par un bouton, soit en utilisant la propriété de création dans la relation entre les 2 table) - ou ajouter directement 45 lignes vides (par un script), que l'utilisateur renseignera ensuite, à sa convenance. En espérant t'avoir aidé… Bonne journée, Jérémie
  2. Bienvenue au club, @jilc ! 😉 Mais en fait, j'ai l'impression que le compteur de membres en ligne est défectueux, voire défaillant, car il me dit tout le temps "1 membre en ligne"…
  3. D'autant plus qu'il s'agit d'un fichier presque vide, créé il y a quelques jours, par le bouton "nouveau fichier vide" de la fenêtre d'ouverture. Je n'ai encore AUCUNE fonction personnalisée dedans. A peine 3 tables sans la moindre particularité, et les rubriques de base… (Même pas des rubriques automatiques de Filemaker puisque j'ai vider le XML DefaultFields, à cause de l'absence de rubriques calculées). Je n'ai pas importé de thème, pas copié-collé de rubriques ni script ni rien… Pas de Source de données externes non plus… Bref ! On saura si ça se présente un jour chez d'autres personnes !
  4. Bravo ! Moi, j'étais dans la Bibliothèque du HD, et non dans celle de l'utilisateur (qui était d'ailleurs cachée, jusqu'à cette heure)… Du coup, effectivement, ça remarche après avoir supprimé ces 2 extensions ! Reste à savoir pourquoi il a tant voulu m'ajouter ces extensions ce matin. NB : pour répondre à Esaïe, non, je n'ai pas de script contrôlant ces extensions à l'ouverture du fichier, du moins pas dans ce fichier. J'ai eu ça ailleurs, et dans des solutions sur lesquelles je développe encore en FMP16. Un grand merci ! Jérémie
  5. Bonjour Cey, Merci ! Je pensais plutôt à ~/Applications/FileMaker Pro 18 Advanced/Extensions/ Mais après vérification, dans ~/Library/Application Support/, je n'ai pas de dossier FileMaker…
  6. Bonjour, FMP 18 refuse de s'ouvrir : « L'installation de l'ancien moteur d'exécution Java SE 6 est nécessaire pour ouvrir Filemaker Pro Advanced ». Ca me le fait seulement depuis ce matin. J'avais déjà rencontré ce souci avec FMP 17 ; j'avais supprimé l'extension Script Master, et ça s'était arrangé. Souci : à cette heure, je n'ai aucune extension dans mon dossier FMP 18. Donc rien à supprimer… Pourtant, c'est sûrement encore un problème de plugin : ce matin, à la première ouverture, Filemaker m'a demandé de valider l'installation de BaseElements puis de ScriptMaster (alors que le fichier en question n'utilise aucune de ces extensions, soit dit en passant)… J'ai accepté sans me méfier, et depuis j'ai ce plantage à l'ouverture ! Sauf que je ne peux virer ces extensions puisqu'elles ne sont pas apparues dans le dossier de Filemaker 18… (Inutile de préciser que je n'ai pas une envie débordante d'aller installation des bidules Java, encore moins "anciens".) Quelqu'un sait-il ce qu'il en est ?? Bonne journée, bonne fête ! Jérémie
  7. Voilà comment on se fait rappeler à l'implacable solitude de notre condition terrestre ! 😭 Et sous la pluie, en plus !! 😅😅
  8. Bonjour Envergure, (NB : tu as sûrement un prénom, ça sera sympa de nous le dire…) Bravo pour ton fichier et pour l'ensemble du projet, qui est justement d'envergure ! Avant de te lancer dans de grandes modifications, je pense qu'une simple correction t'aidera déjà un peu : dans la capture ci-dessous, tu verras une erreur sur un lien. Dans PRIX, "clé sous article" devrait être relié à "sous article ID", et non pas à "clé prix". Il y a peut-être d'autres coquilles de ce genre, je n'ai pas tout regardé, mais en corrigeant cela, tu auras sûrement déjà du mieux. Bon début de semaine ! Jérémie
  9. Ca, c'est la cible. La rubrique qui oscille entre 1 et 0 dans chaque entreprise est effectivement non globale et fixe. Appelons cette rubrique "actif". Il faut une autre rubrique (outil) globale, qui contient 1 et qui est globale. Si le fichier est en ligne, il faudra ajouter un définir rubrique à l'ouverture, pour remettre 1 dans cette globale. Appelons-la "g_1". Le lien sera : entreprises::g_1 = entreprises_liste::actif Si c'est pas ça, je veux bien une capture du modèle et du schéma des relations…
  10. Je pense que si le 1 (à gauche du lien) est global, tu verras les entreprises "à 1". Mais j'avoue ne pas être sûr de comprendre exactement. Si tu veux partager quelques captures…
  11. Salut Olivier ! En forme ?? 🙂 La date de ce post est manquante, du coup, je ne sais pas si c'est un nouveau sujet ou un sujet ancien ressurgi de façon inopinée. Si le sujet est d'actualité, a priori, il s'agit d'une question de rubrique non globale alors qu'elle devrait l'être. A gauche du lien : une rubrique g_1 qui est globale A droite du lien : la rubrique non globale liste, qui contient 1 ou 0 selon la sélection Si j'ai bien compris la question, elle rejoint la notion de sélection que j'ai abordée à la conférence de La Rochelle : En tout cas, au plaisir de discuter ! Jérémie
  12. Je t'en prie ! Bonne journée
  13. Dans la rubrique statistique, tu as choisi l'option "progressif". Si tu la décoches, tu auras le montant total même sans aller sur le dernier enregistrement. NB : je te recommande vivement de te doter d'un modèle de type liste, pour visualiser ce genre de données.
  14. Tout à fait, @tcolles. D'autant qu'un tel script, plus précis dans son œuvre que mon idée, peut être inclus dans un petit bouton "Refresh" juste en haut de liste, par exemple… Je viens de tester ça… Excellent !! Par contre, pour ce qui est de "mettre à jour toutes les rubriques archivées d'une table", ça ne le fait pas (forcément…). Dommage, j'ai cru un instant qu'un hack allait me permettre de simplifier mes mises à jour nocturnes… Bonne journée !
  15. Bonjour Arusha, J'aime bien ton modèle TRAJETS ! ? Dans cette situation, une table doit suffire, avec un bon modèle de rapport (type liste avec filtrage et tri bien pensés). (Je vois une table Recherche dans ta structure, qui n'est pas indispensable, je pense.) Dans ton cas précis, la difficulté apparaît pour croiser les critères. Comme tu le fais déjà, on peut croiser le critère jour / nuit avec les critères climat et type de route. Mais, et tu l'as peut-être déjà constaté, dans l'absolu, il faudrait pouvoir enregistrer dans la même journée X kilomètres Jour+Campagne+2voies+Pluie et Y kilomètres Jour+Campagne+cheminDeTerre+Brouillard et Z kilomètres […], etc. Le nombre de combinaison est important et peut être multiplié si tu décides d'ajouter des items (vents violents, entre-chien-et-loup, embouteillage, incident survenu, trois-passagers-bruyants-à-l'arrière, etc.). On peut donc difficilement recourir à des rubriques pour chaque cas de figure. Concrètement, si tu veux gérer tous les possibles, il te faut subdiviser en sous-trajets : - soit en créant une fiche trajet nouvelle à chaque fois qu'un des critères est modifié, - soit en utilisant une table "sous-trajet" reliée à la table trajet. Dans les 2 cas, tu utiliseras une rubrique jour-nuit unique, une rubrique type-de-route unique, une rubrique climat unique et une rubrique kilométrage. Tu pourras sortir des rapports précis assez simplement. Bonne journée ! Jérémie
  16. Un exemple, si cela se comporte différemment sur ton poste, ne serait pas significatif. As-tu essayé les 2 possibilités : Liste déroulante et Menu déroulant ?
  17. Bonjour Tom, L'idée se défend. Hélas, Je ne peux pas dire qu'il y ait une majorité d'adresses pros, en tout cas pas une "immense majorité". Du coup, effectivement, je me contente des boîtes citées dans le lien que j'ai trouvé (voir plus haut). C'est bien assez complet pour mon objectif ! Merci ! ? Jérémie
  18. Bonjour Kachourando, (Peut-être n'est-ce pas ton prénom) Ce que tu souhaites est exactement ce que Philippe a décrit. Ca le fait naturellement sur Mac, mais pas sur Windows… Est-ce ton cas ? Bonne journée, Jérémie
  19. I see what you mean !! Mais l'objectif n'est pas si élevé, heureusement. En fait, on passe d'un système dans lequel les Contacts étaient directement reliés à des Structures, à un système dans lequel la jonction sera faite par une table Fonctions. Au cours de la migration, je vais grossièrement laisser les adresses de type Gmail/Yahoo dans la rubrique Contact::email, alors que les autres adresses passeront dans Fonction::email. C'est une distinction approximative entre adresses pros et persos.
  20. Salut Fabrice, Dans ce cas précis, il n'y aura pas d'interaction avec l'utilisateur, car la séparation va se faire au moment de la migration. Après migration, si l'utilisateur veut mettre bidule@gmail.com comme adresse pro, et machin@impots.gouv.fr comme adresse perso, il en sera libre. Parmi les "millions", j'en ai trouvé une seule, mais elle me paraît pas mal : https://www.arobase.org/gratuit/annuaire-messageries.htm Bonne journée !
  21. Bonjour, Pour un client, j'ai besoin de séparer les adresses mails de milliers de contacts entre 2 catégories : - adresses pros : @leur-entreprise.com, @bidule.gouv.fr - adresses "gratuites" : @gmail.com, @yahoo.fr, @laposte.net, wanadoo, free, etc. Je me suis créé une petite fonction personnalisée, qui renvoie 1 pour ce genre de boîtes mails : Occurrences ( _mail ; "@gmail." )OrOccurrences ( _mail ; "@laposte." )OrOccurrences ( _mail ; "@numericable." )OrOccurrences ( _mail ; "@yahoo." )OrOccurrences ( _mail ; "@hotmail." )OrOccurrences ( _mail ; "@free." )OrOccurrences ( _mail ; "@icloud." )OrOccurrences ( _mail ; "@orange." )OrOccurrences ( _mail ; "@sfr." )OrOccurrences ( _mail ; "@outlook." ) Mais cette liste est sûrement incomplète… Quelqu'un veut-il participer en complétant ? Ou bien peut-être y a-t-il une liste officielle ? Si c'est le cas, je n'ai pas trouvé… NB : plus tard, je m'occuperai de faire une fonction plus jolie, en utilisant Extrait ( _mail ; Position du @ ; Distance entre @ et . ) ; pour l'instant, mon objectif est déjà d'avoir une liste plutôt complète… Au plaisir de vous lire ! Jérémie
  22. Bonjour Cooky, Si j'ai bien compris : Si ( DATE du jour > cotisation::DATE DE FIN ANNEE AND cotisation::payé ≠ 1 (1 ou "x" ou "payé", selon la valeur que tu as associée à cette case) ; "RAPPEL A ENVOYER" ) Ca devrait le faire. Par contre, je me permets d'anticiper un souci qui se rencontre souvent : si la rubrique DATE du jour est un calcul indexé, elle ne se mettra pas à jour d'elle-même. Dans la capture jointe, tu constateras que la rubrique DATE du jour n'a pas suivi le changement de date, et ce même après un rafraîchissement de la fenêtre FMP. Danger : tu ouvres le jour J est ça te montre les "rappels à envoyer" d'une date antérieure à J, donc le suivi est impossible. Pour contrer cela, on peut : - empêcher l'indexation de la rubrique (mais ceci la rend non mémorisable, ainsi que toutes les rubriques calculées qui en dépendent, ce qui n'est en général pas souhaité), - remplacer le champ DATE du jour calculé par une simple date, dans laquelle on vient chaque jour rafraîchir la valeur par script… Bonne journée ! Jérémie
  23. Prenons un exemple : regne::id_dynastie <-> dynastie::id Dans cette relation, le champ regne::id_dynastie recevra par exemple 23 pour que le règne soit relié à la dynastie 23. Autres champs dans ces tables : regne::nom_de_la_dynastie qui irait chercher, par référence externe, la valeur de dynastie::nom Si on en vient à corriger le nom de la dynastie, on peut ensuite rafraîchir cette donnée dans regne::nom_de_la_dynastie pour que la nouvelle orthographe y soit reportée. En revanche, une rubrique identifiant n'est pas censée être modifiée. Même, elle ne DOIT jamais être modifiée, donc aucune raison qu'elle soit en référence externe. Dans l'exemple : - dans dynastie::id : le 23 ne doit jamais être modifié - dans regne::id_dynastie : si le 23 est remplacé par un 25, ça signifie que le règne est raccroché à une autre dynastie que précédemment, mais cette modification est faite par un utilisateur, elle n'est pas une conséquence ni de l'enregistrement 23 ni du 25. En enlevant toutes les références externes non nécessaires de tes fichiers, je ne pense pas que tu rencontres de souci. Je l'ai fait sur l'ensemble de tes liens règne <-> dynastie <-> période <-> ère sans voir aucune différence.
×
×
  • Create New...