Jérémie Gimenez

Bonjour MMB, (Prénom ?) Dans la solution de Philippe, il n'est pas nécessaire d'avoir 2 rubriques pour chaque valeur booléenne. L'idée est d'avoir une table à part contenant 2 enregistrements : "oui", dont la rubrique valeur est 1, et "non", dont la valeur est 0. Regarde le schéma de Philippe, il est très clair. Du coup, après, tu utilises à n'importe quel endroit, sur n'importe quelle rubrique, la liste de valeur qui appelle cette table OuiNon. Au passage, j'aime bien cette solution, @Philippe ROTTIER, je n'y aurais pas pensé ! 😄 Bon début de semaine ! Jérémie

😂 Autant pour moi… Alors désolé, aucune idée de la solution et pas de moyen pour tester. Dans l'explorateur, dans les bibliothèques (ou AppData ou Programmes…), si tu ajoutes une "Mes apps" et que tu quittes FMP. Il y a peut-être un fichier qui va être modifié et dont la date de modification bougera. Modifier ce fichier manuellement avant de relancer FMP permettra peut-être d'agir sur ça. Mais ça fait beaucoup de "peut-être"… J'ai eu fait ce genre de manips en FMP12, avant que les styles ne soient gérés dans FMP, pour modifier des CSS. Ca marchait, avec un peu d'acharnement.

Bonjour Apophis, Je serais curieux de voir cette solution, mais je n'ai pas de compte DropBox (et pas trop envie d'en ouvrir un qui traînerait inutilement). Aurais-tu la possibilité de partager ce document (s'il n'est pas trop lourd) ?… Merci et bonne journée ! Jérémie

Bonjour, Le menus "apps" ?

Vraiment désolé, José, mais je ne comprends pas du tout comment est censé fonctionner le modèle que tu as ajouté. Dans le fichier que je t'ai envoyé, est-ce que le comportement de la liste, dans laquelle la valeur A disparaît dès qu'elle est utilisée dans un enregistrement, correspond à ton besoin ?

Voici la version 1 Dis-moi si cela fait ce que tu attendais. ParJupiter - Liste modifiable individuellement.fmp12

Avec plaisir José ! 😊

Et bien, si on est plusieurs utilisateurs possibles au même moment (cas le plus complexe, mais qui peut le plus peut le moins), je proposerais ceci : - avoir une table Utilisateur, avec une rubrique Utilisateur::liste_temporaire (non globale !) (et une rubrique id, bien sûr), - dans la table de travail (celle contenant les enregistrements devant recevoir distinctivement différentes valeurs d'une même liste, mais sans répétition), avoir une rubrique globale Ma_table::glob_id_utilisateur dans laquelle on met, à l'ouverture, l'identifiant de l'utilisateur, - avoir une occurrence de table de Utilisateur reliée à Ma_table par le lien suivant : Ma_table::glob_id_utilisateur = Utilisateur::id, - utiliser une liste de valeur avec l'option "Voir uniquement les valeurs liées depuis" Ma_table, qui pointerait vers Utilisateur::liste_temporaire, - avoir un script déclenché à chaque fois qu'on choisit une valeur, qui viendrait ré-écrire Utilisateur::liste_temporaire en enlevant la valeur qui vient d'être saisie. Ensuite, quand on change de jeu d'enregistrements, ou quand cela est rendu nécessaire par la navigation, un autre script vient remettre la liste par défaut dans Utilisateur::liste_temporaire. (Liste par défaut qui peut, elle-même, varier selon différents critères) Une autre solution étant d'avoir une table avec les valeurs de la liste et de jouer à afficher/masquer les enregistrements en fonction de leur présence ou absence dans le jeu d'enregistrement trouvé. La solution par liste de valeur individuelle est modifiée par script est tout de même plus souple, je pense. Bon courage ! Jérémie

Bonjour Dias, C'est à dire "ne plus pouvoir utiliser la valeur A dans un autre enregistrement" ? Ou bien dans une autre rubrique du même enregistrement ? Y a-t-il plusieurs utilisateurs susceptibles d'utiliser cela en même temps ? La solution dépendra de ces paramètres. Bonne journée, Jérémie

Bonjour Pascal, Ces déclencheurs de scripts sont une solution. Avoir un bouton "Modifier la fiche", qui n'apparaîtrait que pour l'utilisateur créateur et qui mènerait dans un autre modèle ou les rubriques sont ouvertes, serait une autre solution. En tout cas, dans ton script déclenché, tu pourrais avoir une validation d'enregistrement, ce qui ferait que, dans la table externe, si on reclique, on revoit le message. Par contre, ça empêcherait que l'utilisateur lise la rubrique, si on contenu dépasse la hauteur de l'objet rubrique. Autre piste, à utiliser pour les rubriques sensibles : si on a un texte long dans une rubrique et qu'on souhaite que l'utilisateur puisse consulter ce texte, scroller dedans, copier certaines parties MAIS qu'il ne puisse pas le modifier, on peut créer une rubrique calculée, de résultat texte, qui renvoie la rubrique sensible. Ainsi, quand on utilise cette rubrique dans le modèle, elle est entièrement consultable et copiable, mais ps modifiable. Bonne journée, Jérémie

C'est cool. Est-ce que tout est résolu ?

Merci pour tes encouragements, @Bernard M ☺️ J'accours, je vole… (Plus sérieusement, cette semaine à Poitiers a été très riche, très intense. Je prépare la suite cette semaine !)

Effectivement Philippe, le principe de paresse entre largement en compte ! 😄 Cela-dit, même si c'est le mot principal du teaser, ma présentation ne portera pas, ou presque pas, sur le "fichier interne du développeur", mais sur un ensemble de principe permettant de se faciliter la vie quand on développe et (surtout) quand on livre le fruit de notre développement au monde extérieur… 🗿

Hello, Je dors dans le centre, donc pas de taxi à partager… Par contre, partager un verre serait de l'ordre du possible ! 😄

Ca fait donc plus que des yétis et des requins-jaguars…