Configuration d’un bouton “retour”
-
Configuration d’un bouton “retour”
Posté par CedZ sur 1 octobre 2024 à 5h37Bonjour,
J’aimerai configurer un bouton pour revenir au précédent enregistrement d’une collection dans un Canvasapp, je m’explique:
comme apparaissant sur l’image en pièce jointe, mon app me permet de prendre des notes sur différentes étapes d’un processus.
Par exemple, si je suis à l’étape 2 et que je clique sur “Étape suivante” ceci m’amène à mon écran de saisie pour l’étape 3.
Cependant, j’aimerai avoir la possibilité de revenir à l’étape précédente et que toutes les valeurs saisies dans le formulaire apparaissent “étape”, “responsable”, “commentaire” mais je ne suis pas sûr de quelle serait la meilleure approche. Pour le moment mes tests m’amènent à différents cas d’erreur ou à l’écran “étape 2” mais aucun des champs n’est renseigné.
Notez que j’ai déjà créé une variable pour identifier le numéro de l’étape (“2″,”3”, etc..) – voir variable plus bas- et je me demandais si je pouvais m’en servir comme point de référence.
Merci pour vos lumières,
Cédric
——-
<div>
<div>Collect(AuditData;</div>
<div> {Étape: Étape.Value;</div>
<div> Responsable: Responsable.Value;</div>
<div> Notes: Notes.Value;</div>
<div> Timestamp: Now()</div>
<div> }</div>
<div>);;</div>
<div>Reset(Étape);;</div>
<div>Reset(Responsable);;</div>
<div>Reset(Notes)</div>
<div>;;</div>
<div>UpdateContext({numÉtape: numÉtape + 1})</div>
</div>CedZ a répondu Il y a 1 mois, 1 semaine 3 Membres · 13 Réponses -
13 Réponses
-
Salut @CedZ,
- Est-ce que tes formulaires sont branchés sur une source de données SharePoint ou autre ? La même ou des sources différentes pour chaque écran ?
- Qu’as-tu mis dans la propriété Item de tes formulaires sur chaque écran ?
- As-tu un ResetForm() quelque part sur tes écrans ?
-
Bon Matin Cedz,
Pour ma part un bouton de retour ou de suivant, la formule devrait être uniquement
Retour :
Back(0
ou suivant :
Next() ou Navigate (non screen).
Car dans ta formule, tu demande de faire un reset des datacards ( Étapes, Responsable,)
Le reset doit se faire dans la sélection d’une nouvelle collection mais pas pour un retour en arrière (en cas de modification des informations).
-
Merci pour les réponses.
Pour le moment je ne suis pas encore connecté à une source externe, et je n’ai pas de ResetForm non plus.
J’avais déjà testé la fonction Back mais ceci me ramène à l’étape précédente sans les champs remplis.
Concernant la connection de mon app à 1 source de données c’est bien 1 requis que je voulais voir par la suite (ou peut-être que j’aurai du commencer par là 🙂 (?), pour le moment je voulais plus regarder le côté fonctionnel de l’app).
Idéalement je souhaiterai conservé l’ensemble des informations pour tous les champs dans un fichier Excel ou Sharepoint. Ma table ressemblerait à :
Client | Auditeur | Processus | Date Audit | # Étape | Description Étape | Note Étape | TimeStamp ÉtapeJe comptais m’inspirer de cette vidéo qui à priori semble faire le tour mais si vous avez des recommandations ou conseils ce serait extrêmement apprécié.
https://www.youtube.com/watch?v=imhxy3REgXc&t=209s
Merci d’avoir pris le temps de répondre à mes questions ces derniers jours encore.
Bonne journée
Cédric
-
Effectivement, il faut commencer par créer la source de données en s’assurant de bien concevoir le modèle de données : quelles tables/listes je vais utiliser, comment je vais les interconnecter, etc… Il faut que ce modèle de données reproduise simplement la réalité du terrain.
Je te recommande vivement de passer par des listes SharePoint, la solution du fichier Excel étant la plus pourrie “du marché”.
Pour créer tes listes et colonnes, suis les instructions de ce post (ça t’évitera des galères plus tard) : https://ppfc.fr/groupes/base-de-connaissances/forum/topic/comment-construire-son-modele-de-donnees-sharepoint/
Et sinon, pour ton problème actuel, @jerome a raison : ce sont les fonctions Reset() dans ton code qui vident tes champs. La fonction Reset() sur un champ a pour effet de lui redonner sa valeur par défaut (même s’il y a eu une saisie de l’utilisateur). Le plus souvent, la valeur par défaut étant vide, le champ se vide.
Mais franchement, commence par créer ta liste SharePoint avec les colonnes que tu as mentionné et connecte-là à un formulaire d’édition. Parce-que du coup le formulaire va fonctionner plus ou moins tout seul que s’il n’était connecté à rien comme actuellement.
N’hésite pas à revenir ici si tu as des questions par la suite… 😉
-
Mercibeaucoup R3dKap pour ces conseils.
Je vais commencer par la liste et vous reviendrai avec d’autres problèmes 😂.
Bonne fin de journée !
Cédric
-
——- Problème réglé avec le rempacement du “default mode” à “nouvel enregistrement”–
Bonjour Messieurs, j’ai recommencé mon projet et voici ce que j’ai pour le moment:
– création d’une liste Sharepoint qui contient pour le moment 3 lignes de tests saisies manuellement.
– création de l’app et connection à la liste. Je me connecte aux champs de celle-ci en utilisant un formulaire.
– j’ai également créé une collection “AuditData”
Quand je passe en mode “Aperçu” comme sur le “3” de l’image je n’ai pas accès aux champs.
Est-ce-que ceci est causé par l’utilisation du formulaire ? S’agit-il de la bonne option dans ce scénario ?
Merci et bonne journée
Cédric
- Cette réponse a été modifiée Il y a 1 mois, 1 semaine par CedZ.
-
Bonjour,
Concernant les boutons d’actions “précédent” et ” suivant” que je voulais configurer, je me permets de vous contacter afin de voir si la logique exprimée fait du sens ou pas.
J’ai résumé ci-bas les fonctions des boutons ainsi que le code développé pour le moment.
Pour le bouton “précédent” je n’ai pas de message d’erreur mais je suis pas vraiment certain que la logique employée soit la meilleure.
Merci pour votre aide,
Cédric
<table style=”border-collapse: collapse; width: 585pt;” border=”0″ width=”781″ cellspacing=”0″ cellpadding=”0″><colgroup><col style=”mso-width-source: userset; mso-width-alt: 4010; width: 85pt;” width=”113″> <col style=”mso-width-source: userset; mso-width-alt: 11861; width: 250pt;” span=”2″ width=”334″> </colgroup>
<tbody>
<tr style=”mso-height-source: userset; height: 131.4pt;”>
<td class=”xl63″ style=”height: 131.4pt; width: 85pt;” width=”113″ height=”175″>Précédent</td>
<td class=”xl63″ style=”border-left: none; width: 250pt;” width=”334″> Revenir à l’enregistrement précédent avec les champs “activités”,
“responsables”, “notes” tels qu’ils ont été remplis au moment de l’enregistrementMettre à jour la variable pour retrouver le précédent numéro d’étape</td>
<td class=”xl63″ style=”border-left: none; width: 250pt;” width=”334″>UpdateContext({numÉtape: numÉtape – 1});;
Last(FirstN(AuditData; currentIndex)).Étape;;
Last(FirstN(AuditData; currentIndex)).Responsable;;
Last(FirstN(AuditData; currentIndex)).Notes</td>
</tr>
<tr style=”height: 172.8pt;”>
<td class=”xl63″ style=”height: 172.8pt; border-top: none; width: 85pt;” width=”113″ height=”230″>Suivant</td>
<td class=”xl63″ style=”border-top: none; border-left: none; width: 250pt;” width=”334″>Enregistrer les informations dans la collection “AuditData” pour les champs “activités”,
“responsables”, “notes” ,
Enregistrer le “timestamp” associé à la réalisation de l’étape avec la fonction CollectRéinitialiser le formulaire pour la prochaine entrée avec la fonction Rest
Mettre à jour la variable pour obtenir le prochain numéro d’étape</td>
<td class=”xl63″ style=”border-top: none; border-left: none; width: 250pt;” width=”334″>Collect(AuditData;
{Étape: ‘DataCard Étape Auditée’;
Responsable: ‘DataCard Responsable’;
Notes:’DataCard Notes Sur l”étape’;
Timestamp: Now()
}
);;
Reset(‘DataCard Étape Auditée’);;
Reset(‘DataCard Responsable’);;
Reset(‘DataCard Notes Sur l”étape’)
;;
UpdateContext({numÉtape: numÉtape + 1})</td>
</tr>
</tbody>
</table> -
Salut @CedZ,
Q1. Pourquoi utilises-tu une collection AuditData ? Pourquoi ne pas travailler directement avec la liste SharePoint ? Passer par une collection complexifie la mécanique (mais peut-être y a-t-il une bonne raison).
Q2. Est-ce que les numéros d’étapes se suivent parfaitement d’un enregistrement à l’autre (sans trous) ? Que se passe-t-il au niveau de la numérotation si on supprime une étape ?
Q3. Qu’as-tu mis pour l’instant dans la propriété Item de ton formulaire ?
Q4. Comment remplis-tu aujourd’hui ta collection AuditData ?
Q5. Qu’as-tu prévu si l’utilisateur a commencé à saisir des données sur l’enregistrement en cours et qu’il clique sur PRECEDENT ? Popup de confirmation ? Il perd ce qu’il a saisit ? Enregistrement automatique ? Et si des champs obligatoires sont vides ?
Q6. Est-ce que le numéro d’étape est automatique et verrouillé ou il est saisi par l’utilisateur ? Que se passe-t-il s’il saisit un numéro complètement décalé avec le n° précédent et le suivant ?
—————-
Par rapport à ton code…
PRECEDENT
Les lignes
Last(FirstN(...))
ne servent à rien ici puisque le résultat n’est renvoyé nulle part, ni dans une variable, ni placées dans une propriété d’un contrôle (ou peut-être ne l’as-tu pas précisé).SUIVANT
Dans ton Collect() tu alimentes des colonnes avec des datacards “complets” (c’est-à-dire avec tous les contrôles qu’il y a dedans). C’est pas comme ça qu’on fait. Il faut que tu utilises les DataCardValueXXX qui sont les contrôles qui portent les saisies de l’utilisateur (listes déroulantes, zone de texte, etc.).
Donc par exemple :Collect(
AuditData;
{
Etape: DataCardValue3.Text;
Responsable: DataCardValue4.Text;
Notes: DataCardValue5.Text
})
Le plus souvent les développeurs ne renomment pas les DataCardValueXXX donc là j’ai mis n’importe quel numéro. Faudra mettre les tiens… 😉
Mais concrètement, pour ce que tu cherches à faire je ferais comme ceci :
- Champs obligatoires : Etape, Description, Responsable
- Sur le OnVisible de l’écran :
UpdateContext({numEtape: 1});; Reset(Form1);;
(on démarre à l’étape 1 et on réinitialise le formulaire) - Sur le Item du formulaire :
Last(FirstN(Sort(TaListeSP; Etape); numEtape))
(il faut bien trier la liste sur les étapes avant d’accéder à l’élément en cours sinon on sera pas sur le bon enregistrement) - Sur le DefaultMode du formulaire :
If(numEtape > CountRows(TaListeSP); FormMode.New; FormMode.Edit)
(en gros si on est sur une étape au-delà des étapes existantes c’est qu’on a cliqué sur le bouton SUIVANT alors qu’on était déjà sur la dernière étape existante -> donc on crée une nouvelle étape) - Sur le OnSelect du bouton PRECEDENT :
UpdateContext({indexationEtape: -1});; SubmitForm(Form1);;
(la variable indexationEtape va être ajoutée à la variable numEtape pour avancer ou reculer dans les étapes selon le bouton cliqué) - Sur le OnSelect du bouton SUIVANT :
UpdateContext({indexationEtape: 1});; SubmitForm(Form1);;
- Sur le OnSuccess du formulaire :
UpdateContext({numEtape: numEtape + indexationEtape});; ResetForm(Form1);;
(le changement d’étape ne doit se faire que si le formulaire a bien été enregistré -> c’est à ça que sert l’événement OnSuccess du formulaire : ainsi, tant qu’il y aura des champs obligatoire non renseignés, l’utilisateur restera bloqué sur l’étape en cours) - Sur le DisplayMode du bouton PRECEDENT :
If(numEtape > 1; DisplayMode.Edit; DisplayMode.Disabled)
(ça c’est histoire de verrouiller le bouton PRECEDENT si on est sur la première étape)
Voilou… J’ai p’têt oublié des trucs… Et c’est en supposant que c’est bien la logique que tu voulais mettre en place… 😉
-
Wow Génial merci encore Redkap !
Pour répondre à la question concernant l’utilisation d’une collection c’est parce-qu’il me semblait que c’était un requis à l’archi powerapps. De plus la logique de la collection me semblait plus adaptée car l’ensemble des enregistrements de mon audit y aurait été sauvegardé temporairement et après avoir finalisé l’audit toutes ces données auraient été envoyées dans ma liste.
J’avais pensé à les enregistrer directement dans Sharepoint en utilisant la fonction “Submitform”. De ce que je voyais et comprenais dans mon scénario ceci aurait sauvegardé chacune des étapes une par une et ça ne me semblait pas adapté à mon utilisation notamment pour les cas où j’aurai à revenir en arrière pour modifier une entrée, tu me suis ?
Si je prends un exemple d’usage concret, imaginons que mon audit contienne 7 étapes différentes.Pour une certaine raison, j’ai du revenir à une des étapes précédentes pour faire une correction.Quand j’ai terminé l’audit, mon bouton “Terminer” sauvegarderait directement l’ensemble des résultats dans ma liste Sharepoint, avec les données corrigées ?
Je vais regarder tes autres précieux conseils (et mes autres vidéos Powerapps pour les nuls 🙂 ! ).
Merci encore et bonne journée,
Cédric
-
Wow Génial merci encore Redkap !
Pour répondre à la question concernant l’utilisation d’une collection c’est parce-qu’il me semblait que c’était un requis à l’archi powerapps. De plus la logique de la collection me semblait plus adaptée car l’ensemble des enregistrements de mon audit y aurait été sauvegardé temporairement et après avoir finalisé l’audit toutes ces données auraient été envoyées dans ma liste.
J’avais pensé à les enregistrer directement dans Sharepoint en utilisant la fonction “Submitform”. De ce que je voyais et comprenais dans mon scénario ceci aurait sauvegardé chacune des étapes une par une et ça ne me semblait pas adapté à mon utilisation notamment pour les cas où j’aurai à revenir en arrière pour modifier une entrée, tu me suis ?
Si je prends un exemple d’usage concret, imaginons que mon audit contienne 7 étapes différentes.Pour une certaine raison, j’ai du revenir à une des étapes précédentes pour faire une correction.Quand j’ai terminé l’audit, mon bouton “Terminer” sauvegarderait directement l’ensemble des résultats dans ma liste Sharepoint, avec les données corrigées ?
Je pense que tu as très bien cerné mon besoin en terme de fonctionnalités, je t’ai ajouté deux captures d’écran pour que tu vois toutefois l’interface avec les boutons que j’avais prévu.
J’avais pensé à un bouton “Terminer l’audit” qui aurait permis d’afficher un recap des activités enregistrées (comme sur la pic 2) ainsi que de sauvegarder l’ensemble des enregistrements de l’audit.
Je vais regarder tes autres précieux conseils (et mes autres vidéos Powerapps pour les nuls 🙂 ! ).
Merci encore et bonne journée,
Cédric
-
Ok, je vois ce que tu veux faire. Mais avant de te détailler mes suggestions de réalisations, quelques informations importantes sur la logique et l’architecture générale de ton application :
- un contrôle Formulaire (constitué de datacards, eux-même constitutés des 4 contrôles habituels : DataCardKey, DataCardValue, ErrorMessage, StarVisible) est un objet semi-automatisé qui permet de manipuler un enregistrement d’une source de données (liste SharePoint, table Dataverse, table SQL, …) -> un Formulaire ne peut pas travailler avec une collection
- lorsqu’un contrôle Formulaire est placé sur un écran, la bonne pratique veut que l’on fasse l’appel au SubmitForm() soit lors du clic sur un bouton, soit lorsque l’on quitte l’écran -> on ne fait pas de SubmitForm() sur un formulaire qui ne se trouve pas sur l’écran actif !
- donc concrètement :
- soit tu utilises des contrôles Formulaire qui sont branchés sur tes listes SharePoint et à chaque fois que tu quittes un écran ou lors d’un clic sur un bouton tu fais ton SubmitForm() (c’est ce que j’ai plus ou moins décris dans mon post précédent)
- soit tu gères tes enregistrements via une collection et à ce moment-là tu n’utilises pas le contrôle Formulaire, tu construis toi-même tes formulaires de saisies en plaçant des libellés et des listes déroulantes ou des zone de texte sur tes écrans, et tu enregistres les données de ta collection via la fonction Patch() (mais c’est fastidieux car faut tout gérer “manuellement” : les messages d’erreurs, les réinitialisations de chaque contrôle au changement d’enregistrement, etc.)
<hr>
Maintenant il faut qu’on parle de ta liste SharePoint : il faut la revoir car tu mélanges dedans 2 notions différentes :
- les données générales de l’audit (client, auditeur, processus, commentaires, date de l’audit)
- les données des étapes (étape, description, responsable, notes)
Le problème avec ta liste actuelle c’est que tu as mis tous ces champs dans la même liste -> comme tu as un enregistrement par étape, tu vas répéter les données générales autant de fois qu’il y a d’étapes dans l’audit. Tu me suis ?
Il faut donc séparer ces notions dans 2 listes distinctes de la manière suivante :
- Liste AUDITS
- Client
- Auditeur
- Processus
- Commentaires
- Date de l’audit
- Liste ETAPES
- Audit (colonne de recherche qui pointe vers la liste AUDITS)
- Etape
- Description
- Responsable (peut être différent de l’auditeur ? sinon inutile)
- Notes
Bien définir ton modèle de données est crucial pour te faciliter la vie ensuite dans la construction de l’application.
<hr>
Perso ce que j’aurais bien vu en terme d’architecture pour ton appli c’est les écrans suivants :
- ACCUEIL
- Affiche la liste des audits dans une galerie
- Quand on clique sur un audit on arrive sur l’écran DETAILS AUDIT
- Un bouton NOUVEL AUDIT qui amènerait l’utilisateur sur l’écran AUDIT en mode création
- DETAILS AUDIT
- Un encart avec un rappel des données générales de l’audit sélectionné
- Une galerie qui récapitule les étapes de l’audit cliqué
- Ici à toi de voir si tu autorises de modifier les données générales de l’audit (auquel cas il y aurait un bouton MODIFIER L’AUDIT et on se brancherait en modification sur l’écran AUDIT)
- A voir aussi si tu autorises de modifier les étapes de l’audit (auquel cas il y aurait un bouton MODIFIER LES ETAPES et on se brancherait en modification sur l’écran ETAPES)
- AUDIT
- Un formulaire branché sur ta liste AUDITS qui se positionne en mode création
- Ton bouton DEMARRER L’AUDIT qui effectue le SubmitForm() et qui amène l’utilisateur sur l’écran ETAPES en mode création (pour créer à minima la première étape)
- ETAPES
- Un formulaire branché sur ta liste ETAPES et qui fonctionne plus ou moins comme je l’ai décris dans mon post précédent.
- J’ajouterai un bouton SUPPRIMER ETAPE pour se débarrasser d’une étape si nécessaire et je séparerai la notion d’étape suivante de la notion de nouvelle étape : donc je ferais un bouton NOUVELLE ETAPE et le bouton ETAPE SUIVANTE serait grisé lorsque l’on est sur la dernière étape.
- Le bouton TERMINER AUDIT qui ramène soit à l’ACCUEIL soit sur l’écran DETAILS AUDIT
Tu vois que pour moi les données s’enregistrent au fur et à mesure qu’elles sont manipulées. Et ce que je ferais c’est que je mettrais en place dans la liste AUDITS une colonne STATUT qui me permette de savoir si un audit est en cours ou s’il est terminé et qu’on ne peut plus le modifier.
Le truc c’est que tout ça dépend de la manière dont les audits se passent dans la vie réelle et quelles sont les règles de gestion associées. Comme je ne sais pas comment ça se déroule, je fais des suppositions. Typiquement :
- Est-ce qu’un audit peut être interrompu et repris plus tard ? Ne faut-il donc pas un statut de l’audit ?
- Peut-on supprimer des étapes ? Que se passe-t-il pour la numérotation des étapes dans ce cas ?
- Jusqu’à quel point un audit peut-il être modifié/rectifié ?
- etc…
En tout cas, pour répondre à l’une de tes remarques, fonctionner comme ça te permettrait quoiqu’il arrive de pouvoir revenir en arrière sur une étape pour la corriger.
<hr>
Non, la collection n’est pas du tout un élément requis au fonctionnement d’une application Power Apps. Tu peux très bien développer une application Power Apps qui n’utilise aucune collection et qui se “branche” uniquement directement sur les sources de données.
-
Salut Redcap et merci encore pour ton temps et explications.
J’avais pas pensé au scénario où l’audit serait suspendu, c’est un excellent point.
Ton archi est simple et je pourrai me servir d’un modèle Canvas par défaut au lieu de partir de 0 et bénéficier des fonctionnalités déjà établies.
Je vais cogiter autour de ça 🙂 , merci encore !
Cédric
Connectez-vous pour répondre.