[R3dKap]

Salut @Andre,

Je confirme le même comportement de mon côté. J’ai remonté le problème à l’équipe Power Apps chez Microsoft. J’attends leur retour.

En attendant, tu peux simplement masquer les 2 listes déroulantes des heures et des minutes ainsi que le “:” et cela ne posera pas de soucis à l’enregistrement de tes données… 😉 Tu peux aussi les supprimer complètement mais alors il te faudra corriger 2 ou 3 petites formulaires qui utilisaient ces données (propriété Update du date picker et propriété Y du ErrorMessage).

CommentID=86tf58VdC8dSV2t, PostID=H2cVHF5IZU63cNG

[R3dKap]

Salut @Alain,

Effectivement, le problème n’est pas que chez toi : https://powerusers.microsoft.com/t5/Building-Power-Apps/Menu-component-stopped-working-Published-version-still-works/m-p/1591536#M407807

Donc, potentiellement un effet de bord suite à une mise à jour du core Power Apps (encore 😌).

A mon avis y’a plus qu’à attendre un correctif et essayer de trouver des solutions de contournement en attendant…

CommentID=GPV0TSyd6egTAy0, PostID=M9aTsC8Cee4yibs

[R3dKap]

@Gabriel je ne pense vraiment pas que ce soit lié au volume de la bib. Là, je pencherais plutôt pour un problème de droits ou effectivement d’un type de bibliothèque ou d’un paramétrage sur la bibliothèque qui n’est pas supporté par Power Apps.

Déjà, est-ce que par hasard l’url de ta bibliothèque n’aurait pas changé (tu sais qu’il est possible désormais de changer l’url d’une bib. ou liste SP) ?

Du coup :

• essaie de rafraîchir ta source de données CONTRATS dans l’appli et reteste

• essaie de supprimer ta source de données CONTRATS de l’appli et ré-ajoute là puis reteste

CommentID=pD8l3JkfLpRMIIs, PostID=n1fwKtoJnmfOwlx

[R3dKap]

@Aurelien une idée pour aider @Dalila ? Ou vers qui pourrais-tu la rediriger ? 🙂

CommentID=zb2vNWlOUEYBf61, PostID=jpeVF2TFW1VjesN

[R3dKap]

Ok. 2 pistes à explorer :

1. Indexer la colonne Statut (dans les paramètres de ta liste) :

   

2. Utiliser le moniteur pour regarder ce qui se passe exactement au moment où tu cliques sur le bouton :

   

   Puis envoie la capture de ce que tu obtiens dans les traces en montrant bien le détail du message d’erreur dans le panel de droite :

   

CommentID=n9DEbXzaAi9ePre, PostID=n1fwKtoJnmfOwlx

[R3dKap]

Je me disais aussi… 😉

CommentID=6zgzcESlWelwINg, PostID=GStHvkqqB977fFG

[R3dKap]

Ok, je comprends. Quel est le type de ta colonne Statut ?

CommentID=m4AEkNgjnAXJKZj, PostID=n1fwKtoJnmfOwlx

[R3dKap]

@Gabriel alors une petite chose (que je crois avoir précisée dans l’article où j’explique comment faire les captures des erreurs car cela a son importance) : tant que tu ne cliques pas à l’INTERIEUR de la formule tu ne vois aucune erreur sur ta formule (pour peu qu’il y en aie une). Or, je crois voir un petit bout de rouge sur le fond bleu qui est en bas de ta capture et je soupçonne qu’en réalité il y a bien une erreur dans ta formule.

Est-ce que donc tu peux cliquer dedans et refaire une capture en t’assurant de bien survoler la partie la plus rouge de l’erreur ?

CommentID=2X0Z56X4b3Llmzm, PostID=n1fwKtoJnmfOwlx

[R3dKap]

Ah là je sais pas… Je viens de voir une autre question similaire posée par @Dalila ici :

Est-ce que c’est la même ?

CommentID=bDi0Uza0oXeAVFU, PostID=nMgWrUfaFlxiHh3

[R3dKap]

@Alain de base ton problème me semble bizarre. Ca fait 4 ans que je fait du Power Apps avec du SharePoint et je n’ai jamais constaté ce genre de problème. Lorsque tu fais une opération sur une source de données, celle-ci est immédiate et, comme indiqué par @DavidZed, ton objet source de données dans ton appli est aussi mise à jour instantanément (pas besoin de Refresh() sauf si tu as des colonnes calculées ou que tu as besoin de l’ID SharePoint d’éléments que tu viens de créer).

Perso, je creuserais plutôt du côté de la méthode de mise à jour. De quoi s’agit-il exactement ? Contrôle formulaire avec SubmitForm() ? Patch() ? UpdateIf() ?

Est-ce que tu peux nous en dire plus ?

CommentID=OMsT68GUJ7jqIKC, PostID=GStHvkqqB977fFG

[R3dKap]

@Sylvain je pense qu’il faut commencer par voir s’il est possible de découper ton formulaire Word en plusieurs “morceaux”. L’idée c’est que ces “morceaux” soient répartis sur différents écrans de ton application Power Apps, ceci afin de soulager chacun des écrans. Parce-que si tu mets un contrôle formulaire dans ton application avec l’ensemble des 20 pages de ton Word, ton écran va littéralement crever la gueule ouverte… 😁

Donc, plus concrètement :

• identifier les données à saisir à minima pour qu’une occurrence d’un PdP existe -> j’explique plus loin pourquoi

• saucissonner le contenu du formulaire et répartir les questions dans différents écrans

Côté application :

• un écran d’accueil E1 qui liste mes PdP

• un écran E2 avec un contrôle formulaire pour les données de base du PdP et des onglets qui permettent d’accéder aux différentes sections (saucissonnage précédent) des données à renseigner

• un écran En pour chacun des onglets avec un contrôle formulaire qui porte les données correspondantes

• il faut obligatoirement que le PdP existe, et donc à minima l’enregistrer au niveau de l’écran E2, avant de pouvoir accéder aux onglets et aux différentes sections du formulaire

• chaque écran En a son propre contrôle formulaire branché sur sa propre liste (voir plus bas le modèle de données que je te recommande)

• changer d’onglet implique que l’on a sauvegardé les données de l’onglet sur lequel on se trouve (sinon on perd sa saisie) -> chaque écran est “indépendant” (plus facile à maintenir aussi) -> mettre en place un système de détection de changement de données dans le formulaire pour afficher une popup de confirmation de changement d’onglet sans sauvegarder (ou plutôt de proposer de sauvegarder les données modifiées avant de naviguer)

Et comme indiqué par @DavidZed tu peux facilement mettre en place des petites règles de gestion simples pour afficher/masquer des datacards en fonction de certains critères.

Côté modèle de données, y’a plusieurs options dont celle d’avoir une seule liste avec la totalité des colonnes (mais ça va être monstrueux), et donc je suggèrerais plutôt :

• 1 liste principale avec les données de base du PdP

• 1 liste pour chaque section (si elles sont bien indépendantes) avec une colonne de recherche pour pointer sur le PdP de la liste principale et faire le lien avec le PdP en question

A la rigueur, ce qui peut être intéressant aussi c’est de voir dans quelle mesure lors de la création initiale d’un PdP il est possible de demander à l’utilisateur de quelles sections du formulaire il va avoir besoin : ça te permettrait de n’afficher que les onglets utiles.

Pour ce qui est du workflow de validation, ça dépend du besoin. Si c’est plutôt basique tu peux utiliser un flux d’approbation Power Automate. Sinon, faut le “coder” entièrement dans ton application avec des boutons de validation à chaque étape et pour chaque acteur.

Enfin, pour générer le fichier PDF je te recommande vivement de passer par de la génération d’HTML que tu convertis ensuite en PDF avec le convertisseur natif gratuit (attention l’HTML ne doit pas faire plus de 2Mo -> évite les images, ou alors seulement des petits logos). Mon avis strictement perso, d’expérience : passer par de l’HTML est plus simple et plus flexible que de passer par un modèle de document Word.

NOTE – Attention, à vu de nez comme ça, étant donné que ton formulaire Word de base est déjà plutôt monstrueux, y’a quand même beaucoup de boulot : entre la création des centaines de colonnes, des différentes listes SP, la création des différents écrans de l’appli, des nombreux formulaires à faire fonctionner avec pas mal de datacards avec des règles de gestion, …
Au bas mot (mais j’ai pas vu la tronche du Word), je dirais qu’il y a bien 20j de boulot tout compris si tu veux faire un truc propre… 😉

CommentID=EVHNx2DwXzWt4vT, PostID=nqb4ZT1WDagvuhu

[R3dKap]

@Hugotr35 j’oubliais : j’ai récemment poussé un composant hyper pratique pour créer des apps responsive :

Un “must-have” dans ton cas… 😉

CommentID=fs0TXVGGK8qLFlJ, PostID=ftZwKSf20oqbtPc

[R3dKap]

Tu peux déplacer ton libellé par rapport aux autres contrôles qui sont à côté de lui :

Mais tu ne peux pas le déplacer “à la main” car sa position est gérée automatiquement par le conteneur. Tu peux aussi déplacer un contrôle à l’aide du menu contextuel du contrôle :

Enfin, tu peux le faire avec les raccourcis clavier <Ctrl+)> et <Ctrl+^>.

CommentID=14xFkmqvXs3DqsY, PostID=JpdiSxMTtbDOb5f

[R3dKap]

@Youcef marrant je vais être confronté à cette problématique dans les semaines à venir. Relance-moi d’ici là pour voir comment j’aurais fait… 😋

CommentID=OLSyoSOmaKAGMdJ, PostID=PPEcpDVStySOmlk

[R3dKap]

@Hugotr35 attention faire une application responsive dans Power Apps c’est possible mais c’est chronophage et plutôt complexe.

Pour y parvenir il te faut effectivement commencer par désactiver la mise à l’échelle de ton app comme indiqué par @DavidZed :

Ensuite, il te faudra utiliser le conteneur horizontal et le conteneur vertical pour que tes contrôles s’agencent automatiquement les uns par rapport aux autres et faire en sorte qu’ils passent d’un affichage en ligne à un affichage en colonne si la largeur de l’écran est réduite (comme sur un téléphone). Pour cela, utilise bien la propriété Retour automatique à la ligne (LayoutWrap) :

Il te faudra imbriquer de nombreux conteneurs pour obtenir ce que tu veux :

Ensuite, il te restera le problème de la taille de la police : tu remarqueras que lorsque tu crées une application PC la taille de la police d’un bouton est à 13 et il est à 24 lorsque tu crées une app mobile. Cela est dû au fait que la densité de pixels par pouce est beaucoup plus élevée sur un mobile que sur un écran de PC et donc tout paraîtrait minuscule sur un mobile si on gardait les même tailles que celle sur PC.

Il te faudra donc définir des tailles de polices conditionnelles selon que ton application s’exécute sur un PC ou sur un mobile. Pour détecter si ton device est un mobile, tu peux mettre ce code dans le OnStart de ton app :

Set(n    gloPhoneMode;n    Acceleration.X > 0 && App.ActiveScreen.Width < 600n);;

Ensuite pour gérer l’histoire des tailles de polices, à la suite du code ci-dessus je fais ceci :

Set(n    gloSizes;n    If(n        gloPhoneMode;n        gloFontSizes.Phone;n        gloFontSizes.Desktopn    )n);;

gloFontSizes est définit précédemment comme ceci :

Set(n    gloFontSizes;n    {n        Phone: {n            S: 11;n            M: 14;n            L: 16;n            XL: 20n        };n        Desktop: {n            S: 13;n            M: 16;n            L: 18;n            XL: 24n        }n    }n);

Puis sur chaque libellé, bouton, etc. je définis la taille en utilisant ma variable gloSizes comme ceci :

Bon courage ! 😋

PS : autre technique plus simple = chaque écran est créé en double (un pour PC un pour mobile) -> tu utilises le code ci-dessus pour détecter si t’es sur un mobile (tu le mets dans App.StartScreen) et tu te branches sur le bon écran en fonction… GROS INCONVENIENT : bin tu dois tout faire en double et le risque de désynchro de version entre des écrans jumeaux est plutôt élevé…

CommentID=7ku9AwK5i817Flq, PostID=ftZwKSf20oqbtPc