DominoArea.org [Archive]

j'ai suivi tes conseils :

bouton "créer modifier"

tLkp := @DbLookup( ""; ""; "(essai)"; "suivresurlelongterme"; [ReturnDocumentUniqueID]);
@If( @IsError(tLkp);@Command([Compose]; "suivresurlelongterme");@Command([OpenDocument]; ""; tLkp))

ma vue cachée est "(essai)"
ma vue visible est "suivi"
mon masque est "suivresurlelongterme"

mes 2 vues font appels SELECT Form="suivi"

le bouton je l'ai implanté dans ma vue suivi.

Si j'ai bien compris la formule : si tlKp est en erreur, cela veut dire que c'est la premiere creation, sinon via l'ID on recupere toujours le meme doc.

j'ai fait plusieurs essais cela ne fonctionne pas

"cela ne fonctionne pas" c'est un peu léger pour un diagnostic
si le doc n'existe pas, est-ce que le compose se fait bien ?
si le doc existe, est-ce que le doc s'ouvre ou est-ce qu'l y a un message d'erreur ?

sinon remplace le OpenDoc poar un Prompt pour voir un peu mieux ce qui se passe ...

sinon, perso, je l'aurai faut en LS, mais comme t'as commencé en Formule et que je ne sais pas si t'as fini par te mettre au LS ...

roubech a écrit:"cela ne fonctionne pas" c'est un peu léger pour un diagnostic
si le doc n'existe pas, est-ce que le compose se fait bien ?
si le doc existe, est-ce que le doc s'ouvre ou est-ce qu'l y a un message d'erreur ?

sinon remplace le OpenDoc poar un Prompt pour voir un peu mieux ce qui se passe ...

sinon, perso, je l'aurai faut en LS, mais comme t'as commencé en Formule et que je ne sais pas si t'as fini par te mettre au LS ...

pardon dsl

si le doc n'existe pas, il se compose bien
si le doc existe, il en compose un autre a nouveau

ajouter nocache dans les params du lkp

roubech a écrit:ajouter nocache dans les params du lkp

jai fait rien de plus. je ne comprend pas pk!!

si tu as une vue visible, pourquoi une deuxièeme vue cachée ?
tu as bien une première colonne triée qui correspond à la clé du DbLookup, dans mon exemple le champ Form

Bien moi le bouton je les implanter dans ma vue active et non dans la cachée, cela ne répond pas a mon besoin qu'il y soit.

Je pensais que lookup me permettait de récupérer l'ID de mon doc situe en vue cache afin douvrir tjs le même. La composition d'un doc n'est possible qu une seule fois.

Comme toujours, ce que j'indique, c'est une proposition par rapport des choses que j'ai expérimenté ou seulement imaginé. Je ne connais pas ton contexte. J'ai toujours du mal à comprendre tes problématiques. Et le fait de ne pas avoir une discussion en live en continue, de passer par des messages entrecoupés d'autres activités ne facilite pas les choses. Il ne faut donc pas prendre chaque proposition au pied de la lettre, mais les analyser pour comprendre l'esprit et l'adapter à ton cas. S'il y a des choses que tu ne comprend pas, il faut d'abord trouver ce que c'est avant de te jeter tête baisser dans la copie du code.

si j'ai parlé d'un vue privée, c'est que j'avais en tête un doc qui permet de stocker des paramètres de l'appli et donc qui n'a pas besoin d'être consulté par les utilisateurs. (Au contraire, je préfère pas qu'ils se doute de son existance. J'ai d'ailleurs tendance à ajouter un test sur un rôle en plus au début du code pour éviter qu'un petit malin vienne trifouiller mes paramet/ou un champ auteur dans le doc ...)
"Bien moi le bouton je les implanter dans ma vue active et non dans la cachée"
Si dans ton cas tu as une vue visible, c'est comme tu veux.
Mais alors, je m'interroge sur l'utilité de créer une vue cachée. Tu n'a pas répondu à cette question.

"Je pensais que lookup me permettait de récupérer l'ID de mon doc situe en vue cache afin douvrir tjs le même."
Le DbLookup sert bien à récupéré le UNID du doc, s'il existe. Mais tu n'es pas obligé d'avoir 2 vues, une pour l'utilisateur et une pour le DbLookup. SAUF si ta vue utilisateur ne te permet pas de faire le DbLookup. D'où ma seconde question au sujet de la colonne triée.
Dans mon exemple, la vue ne contenait qu'une colonne basé sur le masque et triée de manière à pouvoir faire le DbLookup en utilisant le nom du masque comme clé de recherche. Tu n'a pas répondu non plus à ma 2ème question sur le tri de ta vue et la clé de recherche du DbLookup

tout d'abord, je te remercie pour tes divers conseils en ayant bien conscience qu il est difficile de comprendre lintégralité du besoin.
toute la conception : vue cachée, bouton .... n'était que maniére dont je pensais que mon besoin allé etre satisfait.

Maintenant, sans tenir compte de tous les dialogues précédents :

ma problématique est que j'ai un masque que je vais appelé une seule fois uniquement. Une fois le premier doc crée, ce sera toujours le meme que l'utilisateur appelera.

Pk une vue cachée? uniquement pour éviter d'avoir une vue avec un seul document.
je pensais pouvoir récupérer toujours le meme doc enregistrée dans ma vue cachée en recupérant son ID. Le contenu du doc ne sont pas des paramétre de la base mais des champs amené a etre modifié chaque mois ou semaine.
A la premiere création, mon bouton doit me permettre de compose le doc et ensuite il doit me permettre d'utiliser tjs le meme doc. Bien entendu jai besoin que ce bouton soit dans ma vue active.

en espérant avoir été un peu plus clair.

"uniquement pour éviter d'avoir une vue avec un seul document."
dans ce cas, pourquoi la vue visible alors ?
Le bouton peux être mis ailleurs que dans une vue listant ce doc unique. Ca peut être un agent accessible dans le menu action. Ca peux être un bouton d'une autre vue, ca peux etre une action d'un plan ...

bref, c'est pas le pb principal
tu ne dis toujours pas comment est faite la vue que tu utilises pour le dblookup. Si elle est triée et si la clé de recherche passée en argument du dblookup correspond bien à la première colonne

roubech a écrit:"uniquement pour éviter d'avoir une vue avec un seul document."
dans ce cas, pourquoi la vue visible alors ?
Le bouton peux être mis ailleurs que dans une vue listant ce doc unique. Ca peut être un agent accessible dans le menu action. Ca peux être un bouton d'une autre vue, ca peux etre une action d'un plan ...

bref, c'est pas le pb principal
tu ne dis toujours pas comment est faite la vue que tu utilises pour le dblookup. Si elle est triée et si la clé de recherche passée en argument du dblookup correspond bien à la première colonne

ma vue n'est pas triée elle est catégorisé sur une colonne via une concaténation de plusieurs de mon masque.

Ensuite quand tu dit "i la clé de recherche passée en argument du dblookup correspond bien à la première colonne" je ne comprend pas ce que tu veux dire

re,

lis ça => http://forum.dominoarea.org/le-dblookup ... 21093.html

oui cela jai bien compris,c juste que la clé correspond au champ du masque, moi jai besoin de l'ID du doc pour rappeller tjs le meme. Après moi javais utilisé le dblookup mais il peut mieux ou alors ma démarche de conception n'est pas bonne.
je ne sais pas trop la je suis un peu perdu.

re,

je crois en effet que ton approche n'est pas adapté. mais n'ayant ni le tenant ni les aboutissant, il est impossible de t'en dire plus

je crois que le pb vient du fait que tu ne comprend pas comment fonctionne le DbLookup et que tu l'a recopié tel quel sans l'adapter à ton cas de figure

"catégorisé sur une colonne via une concaténation de plusieurs de mon masque"
tu dis que ta vue est catégorisée. La 1ere colonne, si elle est catégorisée est donc bien implicitement triée
par contre, on ne doit pas parler de la même chose, car je pensais que tu faisait un DbLookup dans une vue qui n'affiche que l'unique document concerné.
Or tu parles là d'une vue qui semble afficher tous les docs et dont la 1ère colonne semble avoir pour formule Form et est catégorisée