Puimoisson04

Bonjour, Sans problème. Pour importer la référence des enregistrements affichés, ton script d'importation sera du type : Afficher enregistrement [premier] Boucle Définir variable [$Chemin ; Chemin du jpg] Activer rubrique [La rub. multimedia] Insérer image [Référence ; $Chemin] Activer enregistrement [suivant ; sortie après dernière] Fin de boucle La seule difficulté est de définir $Chemin. Pour connaître la structure de chemin qu'attend FMP, le plus simple est dans un premier temps de sélectionner un fichier (en naviguant dans le disque dur) dans les options du pas de script "Insérer image" et de copier le chemin qui s'inscrit (puis remettre $Chemin comme chemin). Puis dans Définir variable de calculer le chemin de chaque image sous la forme : "Partie commune du chemin" & Calcul du dossier et du nom du fichier. Par exemple, chez moi, les illustrations sont rangées dans un dossier DateImage lui même dans une dossier Annee, lui même dans un dossier Pictures. Le chemin sur mon Mac est : imagemac:/Macintosh HD/Users/christophebonnet/Pictures/2017/2017_06_23/2017_06_23_2513.JPG. Le calcul de la variable est alors : "imagemac:/Macintosh HD/Users/christophebonnet/Pictures/" & RubAnnee & "/" & RubJour & "/" & RubNomFichier.

Je crois que tu mélange deux choses, le contenu de la rubrique et le masquage conditionnel. C'est ce dernier, accessible et définissable dans l'inspecteur, qui permet de masquer une rubrique (et non seulement son contenu) sous certaines conditions. Masquage.fmp12.zip

Bonjour, Si, ça marche, par ex. avec un masquage si EstVide (IdSource) comme le suggère EricMi.

Bonjour Yvan, Chaud et sec. Le dilettante est content, le botaniste un peu moins, même s'il reste les alpages… Christophe

Bonjour Yvan, Voici à quoi je pense… YvanG.fmp12

Bonsoir Yvan, Comment sont liées les tables AUT, LIV et LAU ? Le même système (rub. globale renseignée au clic dans la TE) doit fonctionner en passant par la table intermédiaire où vous devez avoir un lien vers AUT et un lien vers LIV, puis la table LIV ?

Bonjour Ivan, Une rubrique globale IdAuteur_g renseignée par script par l'IdAuteur de la ligne cliquée de la première TE ; et un lien = depuis cette globale vers IdAuteur de la table Livres. Et éventuellement un script qui efface cette globale, déclenché à la sortie du modèle (pour que cette deuxième TE soit vierge quand vous entrez dans le modèle). Christophe

Ouaouh ! Ça me fait ça aussi parfois qu'en j'abuse du pastis. Pouf, pouf, en reprenant plus posément et plus précisément, ça donne quoi ?

Il ne faut surtout pas les laisser "saisir" leur nom (fautes de frappe !), mais seulement le sélectionner dans une liste. On définit une liste de valeur "IdentifiantsRetoucheurs", mais en choisissant de n'afficher que le contenu d'une autre rubrique (nom ou concaténation nom/prénom). Ensuite on ne laisse que la possibilité de sélectionner ce nom ou nom/prénom par une liste déroulante, des boutons radios ou un menu local, mais c'est bien la rub. id qui sera renseignée. Afficher les données d'une table dans un modèle basé sur une autre table, liée, que ce soit via des rubriques liées ou des tables externes est un autre des fondamentaux. SelectRetoucheur.fmp12

Bonjour, Désolé, je n'avais visiblement pas tout compris. Donc, dans le cas le plus complexe, un projet est constitué d'interventions de durée variable de plusieurs retoucheurs pendant plusieurs jours. Le principe reste le même. Je ne suis pas sûr qu'il y ait besoin d'autre chose à ce stade et Votre structure à 3 tables semble alors suffisante. Table Projets avec Id et infos propres au projet. Table Retoucheurs avec Id et infos propres aux retoucheurs. Le nom comme identifiant est une très mauvaise idée (le jour où 2 Marie Dupont travaillent dans l'entreprise, vous êtes dans la mouise). Prévoir un identifiant unique (ce qui n'est pas le cas d'un nom ou nom/prénom) et non modifiable pour tous les enregistrements de toutes les tables est un principe quasi incontournable d'une base de données relationnelle. Table WorkReport avec Id, IdProjet, IdRetoucheur et les données propres à un job (date, temps passé…). Cette table intermédiaire est liée à une occurrence de table (OT) de Projets par l'IdProjet et à une OT de Retoucheurs par l'IdRetoucheur. Parallèlement des chaînes de liens sur l'Id (et éventuellement des globales "filtres" sur une date ou un projet, renseignées par script) depuis des OT de Projets et de Retoucheurs vers des OT de WorFlow et autres permet de récupérer données et stats d'un projet ou d'un retoucheur.

Bonsoir, On peut voir ça comme Facture/LignesDeFacture. Une table pour 1 retoucheur, 1 jour, 1 job et une table pour les morceaux de job. Les liens et scripts permettant de gérer l'ergonomie et les stats de l'ensemble.

Le fait que dans la rub. conteneur soit en gris signale simplement que tu ne peux pas faire de lien dessus. Par contre tu peux la "récupérer" dans la table source de ton lien via le lien sur le code. Sur le fond, Jean-Louis a raison, une seule table serait plus logique. Tout dépend ce que tu appelles trop lourd. Jusqu'à quelques centaines de milliers d'enregistrements, si les illustrations sont stockées en externe, la différence n'est pas vraiment nette entre un fichier et 2 fichiers. Et si l'on raisonne en tables au sein d'un même fichier, encore moins…

Tu n'as besoin que d'une rubrique concordante pour lier deux tables (classiquement une rubrique Identifiant dédiée au liens, à valeur unique et non modifiable dans la table source). Dans ton cas, tu devrais avoir un identifiant "Produit" dans ta table "Produits", et dans ta table "FichesTechniques". Un lien sur cet identifiant permet de récupérer/afficher/utiliser dans la table "Produits" toutes les données liées de "FichesTechniques". Voir le cqfd sur les principes des bases de données relationnelles.

Dans le menu "Enregistrements", "Remplacer" permet de remplacer le contenu d'une rubrique de tous les enregistrements affichés (par la valeur de l'enregistrement actif, une incrémentation ou un calcul - ici la valeur liée). Attention, cette action n'est pas réversible.

Bonjour, Il n'y a pas de raison que la deuxième solution ne marche pas. Mais elle n'est pas "rétroactive" (le calcul se fait à la création de l'enregistrement cible. Si ton fichier est déjà en place et que tu rajoutes cette rubrique, il faut passer par un "remplacer" pour la mettre à jour), ou lors d'une modification de la rubrique liée source, si on a décoché l'option "Ne pas remplacer bla bla".