[Nelson]

Hello,

J’utilise de plus en plus les contrôles modernes pour ne pas rater le train et prendre trop de retard pour le futur.

Je ne constate pas énormement de soucis avec. (voir pas du tout, sauf la galerie !!)

Tu serais nous en remonter pour qu’on test de notre côté ?

[R3dKap]

Salut @Jeremy,

Idem que pour @Nelson. Je les utilise aussi de plus en plus. En fait, concernant ton expérience, tout dépend de quand elle date. Car ces contrôles évoluent en permanence. Il y a plusieurs mois quand ils sont sortis ils étaient effectivement “inutilisables” car beaucoup trop limités. Désormais ils sont pas mal étoffés et offrent évidemment un rendu qui est “compliant” avec le design system de Microsoft : Fluent UI. Cela donne un look à tes applications qui s’approche vraiment de ce que Microsoft fait de son côté (si tant est que de ton côté tu construis tes écrans proprement 😅).

Le fait que tu les trouves petits est juste un effet de bords du fait que les classiques étaient en réalité beaucoup trop gros… 😋 Aujourd’hui, sur la plupart des contrôles modernes tu peux décider de la taille de la police ce qui te permet d’avoir visuellement quelque chose d’un peu moins petit si tu préfères.

Ceci étant dit, il y a un comportement natif qui peut rebuter sur les zones de saisies (les TextInputCanvas) : le fait que par défaut un paramètre oblige à quitter le champ de saisie pour que sa valeur soit prise en compte. De nombreuses personnes se sont plaintes que leur recherche de texte dans une galerie par exemple ne fonctionnait plus ou moins bien puisqu’il fallait soit faire ENTREE soit quitter le champ de recherche pour que le filtrage s’applique sur la galerie.
C’est la valeur Focus out de la propriété TriggerOutput qui provoque ce comportement. Il suffit, pour le régler, de la positionner à l’une des 2 autres valeurs : Key press (la valeur est interprété à chaque appui de touche -> instantané) ou Delayed (la valeur est interprétée 500ms après la dernière touche frappée).

Concernant les thèmes modernes, ils restent encore très limité mais ne vont pas non plus, à mon sens, beaucoup évoluer car un design system implique un nombre réduit de couleurs, une certaine cohérence dans les couleurs et un respect des tons pour des questions d’accessibilités. Ceci dit, depuis quelques temps maintenant on peut définir sa propre couleur de thème ce qui est quand même déjà pas mal. Le gros intérêt évidemment de ces thèmes c’est que l’on a plus besoin de se palucher toutes les couleurs des contrôles à la main. Et puis on peut aussi faire référence nativement aux couleurs du thème à l’aide de App.Theme.Colors.<la couleur>.

Le contrôle moderne qui à mon sens manque aujourd’hui le plus de fonctionnalité est le contrôle Table. Mais il va très probablement bientôt fournir plus de fonctionnalité. Selon les cas et les besoins je l’utilise ou en solution de contournement j’utilise le DetailsList du CreatorKit qui est, pour le coup lui, assez puissant. D’ailleurs, concrètement aujourd’hui je comble les lacunes éventuelles des contrôles modernes par les contrôles du CreatorKit (qui sera au passage voué à disparaître le jour les contrôles modernes seront complets).

Note : je comprends pas bien la remarque de @Nelson sur la galerie car celle-ci n’est PAS un contrôle moderne et n’a pas été modernisée récemment (sauf erreur de ma part). Cela reste un contrôle classique avec tous les défauts (de lenteur principalement) qu’il a.

[Jeremy]

Merci pour vos réponses.

Effectivement, le formulaire moderne me pose des problèmes sur les champs “Nombre”, le reset ne se fait pas avec le “NewForm”, et ce même champs a toujours 1 chargement de retard en mode affichage (il charge l’avant dernier enregistrement dans ma gallerie).

Autre exemple, sur les boutons modernes, imaginons 1 vert et 1 rouge, si je selectionne les 2 pour en changer une propriété, ils retrouvent leur couleur par défaut.

C’est pas grand chose dans l’absolu, mais ça ne donne pas confiance pour lancer d’autres éléments en production.

Je vais donc continuer à les essayer, en restant vigilant.

[Nelson]

Je fais référence à ceux ci :

Je ne sais plus avec lequel des 3 premiers mais j’avais eu des soucis d’utilisation.

J’avais donc utilisé une galerie classique mais cela fait un moment.

[R3dKap]

@Nelson mais quelle différence y a-t-il entre les modernes et les classiques… Pour moi ils ont juste fait ça pour intégrer les galeries dans les menus des contrôles modernes mais sans les modifier car il me semble que les propriétés sont les mêmes entre les classiques et les modernes… Ca me semble être du fake quand même cette histoire, ou je me trompe ?

[Nelson]

J’ai normalement trouvé une de mes apps où j’ai du passé en ancienne galerie vs “moderne”.

Je test ce week-end pour te faire un retour plus détaillé car là ce n’est plus tout frais tout frais je t’avoue 😅

Mais si mes souvenirs sont bons, c’était au niveau du comportement interne que j’avais eu un souci que je n’avais pas réussi à résoudre et qui m’a fait rétrogradé vers les galeries “classiques”.

[R3dKap]

@Nelson,

Ma question étant pas tant de savoir ce qui ne marche pas bien dans la galerie moderne mais plutôt de savoir quelles différences il y a entre la classique et la moderne… Parce-que je n’en vois pas de mon côté (j’ai regardé viteuf)…

[Benoit]

Bonjour,

Personnellement j’ai modernisé toute mon appli, mais il reste 2 à 3 cas ou je suis obligé d’utiliser la version classique.

Par exemple le textimput pour l’autoheight dans des cas particuliers.

J’ai aussi créé un bouton toggle perso, en phase de dev, aucun problème à l’affichage mais pas en prod.

Du coup j’ai du remettre un bouton classique

et pourtant aucun texte de renseigné sur le bouton moderne.

Pour la gallerie, je n’ai pas vu de différences donc j’utilise toujours la classique.

Sinon pour le reste tout est passé en moderne, il faut effectivement penser à mettre sur key press au lieu de focus out les textinput.

Cordialement.