Comme point de départ, Telerik en a un https://www.telerik.com/universal-windows-platform-ui/numericbox. Il est également disponible en Open Source : https://github.com/telerik/UI-For-UWP/blob/master/Controls/Input/Input.UWP/NumericBox/RadNumericBox.cs.

Ce que j'aime chez eux, c'est leur approche de la mise en forme avec la propriété ValueFormat.

Exemple : ValueFormat="{}{0,0:C2}"

Veuillez également vous assurer qu'il est correctement localisé. L'implémentation de Windows Community Toolkit présente quelques défauts :

L'extension TextBoxRegex avec ValidationType="Decimal" ne prend pas en charge toutes les cultures d'interface utilisateur. Au lieu de cela, il est fixé à InvariantCulture. En anglais, les valeurs décimales sont " 10.1234 " avec un point. En espagnol ou en allemand, les valeurs décimales sont écrites "10,1234". L'analyse de l'anglais sera correcte ; cependant, l'entrée de l'utilisateur espagnol ou allemand sera simplement "101234" avec la partie fractionnaire perdue.

Voir : https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/2700

Les flèches haut et bas doivent incrémenter ou décrémenter la valeur d'une valeur que le développeur peut définir, mais la valeur par défaut doit être un entier de 1

• les valeurs min/max enveloppantes sont bonnes, par exemple si vous sélectionnez un angle
• possibilité d'ajouter un suffixe
• cliquez sur la zone de texte et faites glisser vers le haut/bas pour modifier les valeurs, Adobe XD l'a dans les entrées numériques.

Mon implémentation dans WinRT XAML Toolkit prend également en charge le glisser haut/bas pour modifier les valeurs et le rend beaucoup plus utilisable lors de l'utilisation avec la souris que de cliquer sur des boutons dans certains scénarios.
https://github.com/xyzzer/WinRTXamlToolkit/tree/master/WinRTXamlToolkit/Controls/NumericUpDown

Bonjour, @sonnemaf , @ArchieCoder , @robloo , @mdtauk , @adrientetar et @xyzzer ! J'ai été affecté à cette proposition.

Tout d'abord, merci, @sonnemaf , d'avoir soumis ceci. Je l'ai montré à Microsoft Build 2019 la semaine dernière et il a reçu les applaudissements du public ! La réponse de la communauté ici dans les commentaires reflète également l'enthousiasme que nous avons de voir NumberBox se produire.

J'ai lu les commentaires de chacun et mis à jour la section sur la portée pour refléter les commentaires reçus. J'apprécierais si tout le monde pouvait essayer cette petite mise à jour et me faire savoir si je n'ai _pas_ capturé avec précision vos demandes , en notant que certains détails (tels que la localisation du formatage) seront traités au niveau des spécifications.

Salut @SavoySchuler ,

Cette semaine, je travaille sur la fonctionnalité d'accessibilité sur mon application. Ce serait un plus si l'accessibilité était gérée correctement avec le nouveau contrôle par exemple, l'incrément peut être dit à voix haute au lieu de "plus", "moins". Le reste me semble bien.

S'assurer que le narrateur est capable de lire les valeurs correctement afin qu'il soit clair que ce qui se passe est important.

Je ne sais pas si le contrôleur Xbox aura besoin d'une mise au point pour s'assurer que les sticks analogiques et le D-Pad fonctionneront correctement

Petite correction - faites glisser pour augmenter/diminuer devrait fonctionner sur le champ de texte lui-même jusqu'à ce qu'il soit activé. IIRC dans mon implémentation, j'ai dû mettre une superposition transparente au-dessus du champ de texte pour l'activer et également masquer le curseur de la souris pendant le glissement afin que les bordures du contrôle ou de l'écran ne limitent pas la distance de glissement et que lorsque vous avez terminé de faire glisser et je montre à nouveau le curseur - il apparaît là où il a disparu pour la première fois.

@SavoySchuler, vous avez une belle tâche. Je peux vivre avec ta portée. La calculatrice est agréable à avoir (WinUI 3.0 ou 3.1). J'ai développé dans de nombreux environnements de bureau (VB6, WinForms, WPF et UWP) et j'ai toujours raté une NumberBox. Enfin, nous l'obtiendrons.

Peut-être que vous pouvez également ajouter la molette de la souris pour Haut/Bas. Blend pour Visual Studio prend en charge cela.

J'aime aussi Drag-to-change, quelque chose que j'ai beaucoup utilisé dans Expression Blend.

Je ne sais pas ce que la validation d'entrée fera et ne fera pas. Sera-ce seulement min/max ou aussi limiter le clavier (lettres az, etc)? Gérera-t-il le collage de numéros non valides ?

J'aimerais lire les spécifications complètes.

@ArchieCoder , je vous entends haut et fort. L'accessibilité est une priorité et il est préférable de la gérer dès le départ. J'ai commencé une section Accessibilité et entrées sur cette proposition où j'ai ajouté votre note.

@mdtauk , excellente question comme toujours. J'ai ajouté ceci à la section Accessibilité et entrées en tant que note pour l'examiner.

@xyzzer , tu as raison. Lors de la réorganisation de la liste des portées, j'ai regroupé les boutons Haut/Bas et faire glisser pour modifier en tant que fonctionnalités associées. Lors de la relecture, il semblait que je suggérais de faire glisser pour modifier une fonctionnalité sur les boutons. J'ai déplacé glisser pour modifier dans sa propre section pour plus de clarté.

@sonnemaf , génial. Je posterai un lien vers la spécification dès son ouverture, ce qui sera probablement aujourd'hui ou la semaine prochaine. N'hésitez pas à vous joindre à moi pour l'écrire ! Jusque-là, j'ai ajouté scroll-to-change à la portée ici.

Tous , Avec une note sur le support de la calculatrice - Je crois en la valeur. Je travaille avec mon équipe pour déterminer si c'est quelque chose que nous devrions modulariser au cas où la fonctionnalité pourrait être exploitée davantage dans la plate-forme. De plus, il y a la question de savoir jusqu'où allons-nous avec le support de la calculatrice ? Un simple ordre d'opérations sur +-/* ferait-il l'affaire ? Ou quelque chose de plus complet comme la connexion à une sorte de service wolfram alpha ? L'exploration d'un itinéraire modulaire pourrait peut-être nous permettre de commencer par le cas le plus basique sans bloquer l'opportunité d'une forme plus complète de support de calculatrice. Je serais intéressé de connaître les besoins de chacun ici.

Pour la validation d'entrée, j'ai la même question. Est-ce que min, max, pas de lettres et pas de collage invalide le couvrent ?

Je trouve la fonction de calculatrice mignonne, mais concrètement, comment cette fonction est-elle découverte par un utilisateur ? Y aura-t-il un petit indice de widget à ce sujet ?

@ArchieCoder , pensez-vous que le texte d'espace réservé personnalisé décoloré dans la NumberBox pourrait inciter un utilisateur de manière appropriée? Si tel est le cas, j'imagine qu'une chaîne telle que "a + b - c" ou "entrer l'équation" pourrait être un moyen succinct de fournir cette information. Excel a également créé une norme avec "=" apparaissant au début d'une équation. Peut-être qu'une fois que l'utilisateur clique sur la NumberBox, un "=" immuable apparaît à l'avant que l'utilisateur tape ensuite derrière ?

Nous avons l'info-bulle ou l'info-bulle plus lourde pour des conseils au niveau de l'application sur lesquels nous pourrions demander aux développeurs de s'appuyer, mais ma forte préférence serait de résoudre ce problème dans NumberBox lui-même.

Je suis intéressé d'entendre vos pensées ici!

Un espace réservé serait en effet un bon moyen tant qu'un autre contexte n'est pas requis en raison de la limitation de l'espace. Je pense qu'une largeur de NumberBox sera plus petite qu'une zone de texte par exemple.

À moins que le contrôle ne prenne en charge les nombres nuls - il affichera toujours une valeur,
il n'y aura donc pas d'espace pour une chaîne d'espace réservé à l'intérieur.

Le vendredi 17 mai 2019 à 10h14 ArchieCoder [email protected]
a écrit:

Un espace réservé serait en effet un bon moyen tant qu'un autre contexte n'est pas
requis en raison de la limitation de l'espace. Je pense qu'une largeur de NumberBox sera
être plus petit qu'une zone de texte par exemple.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMAL7LUOVPIM55PYO4LPV3RWPA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMV5KWTIW992ZLODNGO ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AANMBMBKHP7GP5WUHLPWNZLPV3RWPANCNFSM4HA4PBNA
.

@ArchieCoder , en regardant les exemples de

@xyzzer , merci d'avoir soulevé cette question. Assurons-nous d'abord qu'il s'agit de la bonne expérience utilisateur et que nous puissions comprendre la mise en œuvre à partir de là ! Il n'est pas encore nécessaire de limiter notre recherche de la _bonne_ expérience utilisateur en raison de limitations techniques que nous pourrons peut-être atténuer. :détendu:

J'ai une question prioritaire pour tout le monde :

Préférez-vous avoir un contrôle NumberBox qui consolide ces fonctionnalités indépendamment d'un TextBox standard ou préférez-vous que ces fonctionnalités soient intégrées dans TextBox en tant que capacités natives pouvant être activées via des API ou InputScope ?

( @sonnemaf , @ArchieCoder , @robloo , @mdtauk , @adrientetar et @xyzzer)

C'est un changement important de mettre tout cela dans un contrôle TextBox.

La validation des caractères saisis.

Utiliser la bonne disposition de clavier avec InputScope

Les différents comportements de la souris.

La possibilité d'afficher les boutons spinner comme dans la version FabricWeb.

Si toutes ces choses pouvaient être ajoutées, avec une énumération de comportement pour définir le type de zone de texte, sans avoir d'impact sur tous les autres utilisateurs utilisant actuellement une zone de texte dans leur application, alors tant mieux.

Et vous pouvez même envisager de combiner d'autres comportements TextBox, comme une icône qui pourrait représenter une recherche ou un calendrier qui agit comme un bouton. Masques pour des choses comme les adresses IP ou les URL qui affichent "http://" dans le style du texte d'espace réservé lorsque vous entrez du texte à côté.

FabricWeb a une grande variété avec ses TextFields.

https://developer.microsoft.com/en-us/fabric#/controls/web/textfield

https://developer.microsoft.com/en-us/fabric#/controls/web/spinbutton

J'irais certainement avec un propre contrôle NumberBox au lieu de fusionner toutes ces fonctionnalités dans un contrôle TextBox (de la même manière qu'il existe également un contrôle PasswordBox et non un TextBox avec un "mot de passe" en mode de saisie).

Le champ NumberBox sera bien plus qu'un simple champ de saisie d'adresses IP par exemple. Il viendra avec ses propres fonctionnalités d'accessibilité / de défilement et de glissement uniques, la prise en charge de la calculatrice,... de données). Et comme encore plus de fonctionnalités/exigences spéciales seront proposées pour le contrôle NumberBox, nous pouvons garder une séparation agréable et nette entre NumberBox et TextBox.

Cette transgression se retrouverait également dans la documentation et la mise en page xaml de l'application (NumberBox plus facilement détectable que, disons, une TextBox avec un tas de propriétés dont l'une spécifiant le mode de saisie). Au lieu de lire la documentation TextBox sur ses capacités de saisie numérique, cette partie serait bien rangée dans une documentation de contrôle NumberBox spécifique (comme avec PasswordBox aujourd'hui).

En ce qui concerne l'apparence du contrôle, je pense que l'unité/suffixe pourrait être affiché de côté avec une taille plus petite/couleur désaturée afin qu'elle se différencie de la valeur elle-même :

Lorsque la souris survole la commande, les flèches haut/bas peuvent apparaître à la place de l'unité :

Une alternative est les commandes numériques de figma.com, lorsque vous survolez l'unité, vous pouvez cliquer + faire glisser vers la gauche/droite pour modifier la valeur.

Gauche/droite est intéressant car il est plus facile de déplacer la souris gauche/droite que haut/bas (vous n'avez pas besoin de lever le poignet).

Autres choses:

• Lorsque vous cliquez sur la zone de texte non focalisée, il doit sélectionner tout le contenu. pour que clic+taper une valeur+entrée change la valeur
• Shift+Click une flèche ou Shift+Up/Down lorsque le focus augmente ou diminue de 10 (cette valeur devrait aussi être personnalisable, je pense).
• Je ne pense pas que la flèche haut/bas soit très utile pour l'utilisateur. Si l'utilisateur veut une valeur précise, il la saisira simplement, s'il n'est pas sûr de la valeur qu'il souhaite, il peut visualiser un spectre de changements de valeur en cliquant + en faisant glisser. Ainsi, les flèches haut/bas devraient probablement être au moins facultatives.

@adrientetar mettre une indication de l'unité à l'intérieur du contrôle crée de nombreux problèmes supplémentaires :

• localisation
• accessibilité
• sélection
• coller
• conversions

Ceux-ci seraient tous évités en mettant cela dans l'en-tête, la description ou un TextBlock séparé.

J'opterais pour un contrôle NumberBox séparé avec une propriété Value et peut-être pas une propriété Text. La valeur doit être un double afin que nous puissions la lier (x:Bind). Je ne sais pas si nous devrions également prendre en charge le type de données Decimal, et comment.

La prise en charge des nombres nullables est un MUST je pense (merci @xyzzer). La propriété Value doit être un NullableType de données. Je ne sais pas si cela entraînera des problèmes de liaison lors de la liaison à une valeur non nullable.

Bien que la composition présente des avantages et qu'elle ait un comportement attaché aux numéros
le mode pourrait être implémenté et attaché à une zone de texte - je pense que cela ferait
c'est inutilement compliqué et limité.
Certains des plus gros problèmes que vous rencontrerez probablement avec la mise en œuvre concernent
accessibilité. Je pense soutenir certains des modèles d'accessibilité -
vous auriez besoin de cuire dans la mise en œuvre de certaines interfaces dans TextBox
cela rendrait confus si une zone de texte n'était pas en mode boîte numérique.

Le lundi 20 mai 2019 à 02h33 Fons Sonnemans [email protected]
a écrit:

La prise en charge des nombres nuls est un MUST je pense (merci @xyzzer
https://github.com/xyzzer ). La propriété Value doit être un Nullable
Type de données. Je ne sais pas si cela entraînera des problèmes de liaison lors de la liaison à
une valeur non nullable.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMBGVIQ36CDPQO6CWKLPWJV55A5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXH10WVA
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AANMBMBTHT2UXOAGRTEDF7LPWJV55ANCNFSM4HA4PBNA
.

J'ai une autre question pour tout le monde. Avez-vous besoin/préférez-vous la validation ou le masquage des entrées ?

( @sonnemaf , @ArchieCoder , @robloo , @mdtauk , @adrientetar , @xyzzer et @Felix-Dev )

La validation est essentielle, car vous ne pouvez pas ajouter de nombre à une chaîne. Et les opérateurs mathématiques doivent être évalués et traités.

A-t-il besoin d'un message d'erreur affiché s'il ne peut pas calculer, ce dont je ne suis pas trop sûr.

Le masquage serait utile, mais il devrait probablement être intégré à la zone de texte elle-même, afin que l'URL et l'entrée d'e-mail puissent être gérées. NumberBox serait des numéros de téléphone, des adresses IP, etc.

Je ne pense pas qu'un NumberBox devrait être utilisé pour les numéros de téléphone ou les adresses IP. Celles-ci ressemblent plus à de simples extensions de masquage/filtrage pour une zone de texte. Un NumberBox est quelque chose que vous voudriez utiliser pour entrer une valeur unique.
Il est peut-être possible d'avoir un contrôle de la boîte à monnaie, mais j'ai également l'impression qu'il devrait s'agir d'un contrôle distinct différent de TB ou NB.

@xyzzer Rendre la NumberBox plus flexible pour tout type de saisie numérique me semble être une bonne idée. Il peut être dérivé d'un contrôle TextBox et ce contrôle peut avoir une propriété Mask, ainsi que d'autres propriétés comportementales.

Certaines de ces propriétés sur la NumberBox pourraient être :

• Afficher/Masquer les boutons rotatifs
• Autoriser l'incrémentation et la décrémentation des valeurs
• Permettre le calcul des valeurs
• Autoriser la saisie masquée
• Masques localisés tels que les numéros de téléphone ou les adresses IP

Les propriétés qui pourraient être ajoutées à la zone de texte pourraient être :

• Une propriété Mask - Une chaîne XAML pour définir un format personnalisé ([email protected]) ainsi que des masques localisés tels que les codes postaux/zip
• Affichage du texte préfixe/suffixe (_http://_ comme préfixe par exemple)
• Afficher/masquer le bouton d'action - avec une icône et une propriété d'événement de clic
• Icône (la zone de recherche Fabric UI affiche son icône sur la gauche et s'anime lorsque la zone obtient le focus)

Ces images sont du Fabric UI TextField - et il prend en charge tous ces différents états - nous devrions viser à amener les contrôles Fluent WinUI 3.0 à la parité dans la mesure du possible

Les boutons Fabric UI Spinner sont trop petits pour le toucher, donc je le formaterais différemment afin que les boutons haut et bas soient côte à côte, pas empilés les uns sur les autres

Pour moi, la validation est un MUST HAVE et le masquage est un agréable à avoir. Je n'ai jamais aimé le masquage ; c'est trop rigide.

@rudyhuyn a proposé sur le référentiel Windows Calculator une fonctionnalité intéressante. @mdtauk l'a commenté .

Vous pouvez ouvrir une fenêtre contextuelle de la calculatrice à partir de la NumberBox similaire à un sélecteur de date/heure/calendrier.

Semblable à ce que @xyzzer a dit ci-dessus. Il existe une différence fondamentale entre un nombre et une chaîne contenant une séquence de chiffres.
La meilleure façon dont j'ai entendu la différence décrite est que vous pouvez effectuer des opérations de multiplication et de division sur un nombre. Vous pouvez demander la moitié d'un nombre et diviser par deux. Vous ne pouvez pas demander un demi-code postal ou un "numéro de téléphone" et obtenir quelque chose de significatif.

Mélanger un NumberBox spécifique doté de capacités mathématiques avec des fonctionnalités permettant de capturer d'autres valeurs comprenant des chiffres peut également entraîner d'autres problèmes.
Les "numéros de téléphone" peuvent commencer par des zéros non significatifs (ou un signe plus) et là, ils ont un sens. Pour un _nombre_ ils ne le font pas et seraient dépouillés.
Les « numéros de téléphone » sont souvent également formatés avec des crochets et des tirets. Lorsqu'elles sont traitées comme des opérations mathématiques, celles-ci pourraient facilement être interprétées comme nécessitant une multiplication et une soustraction.

Autoriser le masquage de la même manière qu'un TextBox et comme moyen de formatage des entrées risque de brouiller la différence entre un NumberBox et un TextBox et quand chacun doit être utilisé.

Une validation simple lorsque la validation arrive sur la plate-forme , cela n'entraîne pas des méthodes de validation conflictuelles ou quelque chose qui pourrait facilement pousser les développeurs à étendre leur validation à plusieurs emplacements .

Je garderais la validation uniquement basée sur ces propriétés :

• Valeur maximum
• Valeur minimum
• Autoriser les décimales

Séparément, il doit y avoir une indication de

• sortie invalide des calculs
• comment gérer une valeur entrée/collée/calculée et ce qui est utilisé dans une liaison. Il est nécessaire d'afficher le calcul ou la valeur invalide pour montrer qu'il n'est pas valide, mais cela ne peut être transmis à aucune propriété de sauvegarde,

Les masques auraient besoin d'une capacité visuelle pour indiquer clairement ce qui est requis, tandis que les entrées de calcul de base ne seraient pas utilisées avec les entrées masquées.

Les contrôles de texte Fabric Web semblent bien gérer cela - mais bien sûr, la portée de la NumberBox est distincte des améliorations générales de l'ajustement et de la finition du contrôle TextBox par défaut.

Les boutons rotatifs (et peut-être l'icône déroulante Calculatrice en option) sont les seuls éléments visuels qui semblent spécifiques à une NumberBox.

En ce qui concerne les propriétés, peut-être que si les boutons haut et bas du clavier sont activés pour modifier la valeur - une valeur de pas pourrait être incluse afin que vous puissiez choisir de combien incrémenter ou décrémenter en appuyant sur une touche.

@mdtauk , j'aime la valeur Step , mais pas seulement en appuyant sur une touche. Également sur le bouton de défilement et haut/bas.

@sonnemaf Bien sûr, le Step est bon pour quelque chose de binaire comme un clic de la molette de la souris, une pression sur une touche ou une touche enfoncée. Peut-être que la distance éloignée de la boîte pourrait augmenter le nombre de pas ?

Alors StepMinimum et un StepMaximum peut-être ?

Alors StepMinimum et un StepMaximum peut-être ?

Je n'ai aucune idée de ce à quoi ces valeurs pourraient se rapporter ou à quoi s'attendre pour elles.
Si le but de "Step" est de définir des incréments, appelez-le "Increment".

Cela permettrait à Max:100 Min:0 Increment:10 de n'autoriser que les valeurs 0, 10, 20, 30, 40, 50, 60, 70, 80, 90 et 100 à spécifier.

Le fait que la quantité de pas/incrément varie en fonction de la distance parcourue peut entraîner des changements de valeur imprévisibles. Si le but de ce contrôle est de faciliter la spécification de valeurs numériques, alors si la valeur commence à changer dans des quantités variables, je trouverais probablement cela très frustrant, ce qui irait à l'encontre de l'objectif sous-jacent d'avoir un contrôle dédié pour le rendre facile.

@mrlacey J'utilise Step car il s'agit de la propriété nommée pour le curseur et les barres de progression, mais l'incrément peut être utilisé si vous préférez. La valeur monte et descend tant que l'incrément n'est pas confondu avec seulement une augmentation de la valeur.

Il y a une proposition pour cliquer et faire glisser vers le haut ou vers le bas pour augmenter ou diminuer la valeur. Si l'utilisateur s'attend à ce que la valeur change plus rapidement, plus vous faites glisser vers le haut ou vers le bas, alors avoir une valeur Stap Min et Max permettrait au développeur de contrôler cela à mesure que le delta change. Ainsi, une petite distance de traînée peut être augmentée de 0,1 ou 1 - mais la poursuite de la traînée peut changer par étapes de 5 ou 10 par exemple.

Je ne dis pas que la distance de traînée doit changer la vitesse du changement de valeur - seulement que c'est une idée qui peut être utile, si cela semble naturel et donne à l'utilisateur un sentiment de confiance et de contrôle.

Super retour, tout le monde ! J'ai ouvert une spécification et des relations publiques pour commencer à définir les détails.

@KevinTXY me rejoindra en tant que développeur pour ce contrôle. Nous poursuivrons la conversation sur les exigences ici et commencerons la conversation spécifique à l'API/à l'exemple sur le PR.

N'hésitez pas à vous joindre à moi pour rédiger la spécification.

La spécification de TeachingTip est un exemple complet de ce à quoi ressemblera une spécification finie. Le schéma principal sera :

• La description
• Exemples pour chaque API/fonctionnalité
• Des lignes directrices
• API (IDL)

De bonnes idées, j'aime où tout cela va. Ajoutant mes deux cents:

• Sans aucun doute, je pense que cela devrait être une NumberBox distincte au lieu d'être intégrée à TextBox. De plus, il y a beaucoup de bonnes fonctionnalités discutées ici, mais nous devrions également garder la NumberBox légère. Par conséquent, je propose de dériver une CalculatorBox ou quelque chose de similaire de NumberBox et qui peut avoir les entrées avancées "2+3" ou un bouton pour ouvrir une calculatrice.
• La localisation doit être bien pensée dans les spécifications à l'avance. De plus, il existe des cas où vous voudriez remplacer l'interface utilisateur locale. Par conséquent, la définition d'une propriété NumberformatInfo ou CultureInfo peut être très utile. Par exemple, dans certaines applications, une valeur étrangère et une valeur locale sont suivies. Chacun pourrait potentiellement être un format différent.
• Le contrôle doit prendre en charge le déplacement d'une décimale. C'est plus délicat que de simplement valider un format sur chaque texte modifié. Chaque entrée de caractère doit être suivie et la décimale précédente remplacée si nécessaire.
• Toutes les flèches d'incrémentation/décrémentation doivent être configurables pour être désactivées afin d'avoir simplement une zone de saisie simple - encore une fois, nous avons besoin d'un contrôle léger ici pour les cas où il est nécessaire dans le cadre d'autres contrôles.
• Quelque chose d'autre qui n'a pas été discuté est que nous devons idéalement prendre en charge plusieurs types - Decimal, Integer et potentiellement Long, Double, etc... Cela pourrait fondamentalement changer beaucoup de choses et je n'y ai pas encore pleinement réfléchi moi-même. .
• La valeur doit absolument être nullable. Une valeur non définie est différente de zéro.
• Une autre idée qui n'est pas critique est de permettre à la précision décimale d'être spécifiée pour les types décimal, double ou flottant.

Je suis sûr que d'autres idées suivront. J'ai hâte de lire la spécification !

( @mdtauk , @xyzzer , @mrlacey , @sonnemaf , @robloo , @Felix-Dev, @adrientetar , @ArchieCoder )

J'ai rempli les spécifications / PR avec des API et des exemples pour chacun. Je pense avoir adressé la mise en forme à vos spécifications avec une énumération pour les types prédéfinis de base (encore en cours) ainsi qu'une propriété de mise en forme personnalisée qui remplacera les types prédéfinis s'ils sont définis.

Veuillez le vérifier et me faire savoir s'il ne résout pas vos problèmes ou s'il peut être ajouté ou amélioré. J'accepterai les demandes de tirage qui contribuent aux spécifications demandées ici.

• La validation est notée comme un must. J'ai prescrit que ce contrôle dérive de TextBox pour obtenir gratuitement le masquage et d'autres propriétés de support.

• À la préoccupation de @mrlacey , j'ai ajouté une API pour activer/désactiver la suppression des zéros non significatifs qui peut être utilisée en conjonction avec la chaîne de format personnalisée pour activer des scénarios de saisie de chaîne numérique personnalisée (en notant que les numéros de téléphone internationaux et les adresses IP sont déjà sur la liste des types de formats de base possibles).

• Cela, associé à la possibilité d'activer/désactiver la prise en charge de la calculatrice, constitue pour moi l'intersection d'un contrôle qui peut à la fois être léger pour les valeurs numériques/chaînes, mais également offrir une prise en charge suffisante de calcul et de personnalisation. Je pense que la concision des exemples le met en évidence, mais je suis intéressé d'entendre tous ceux qui pensent que cela rendrait le contrôle potentiel plus lourd à utiliser.

• @sonnemaf J'apprécie la nouveauté et l'intuitivité de l'exemple icône > calculatrice popup. Pour moi, cela dérive par exemple du concept de CalendarDatePicker et pourrait être une excellente considération pour une fonctionnalité V2 à moins qu'il n'y ait une forte pression de tout le monde ici pour qu'elle soit envisagée pour la V1 ?

Une calculatrice contextuelle peut avoir du sens s'il existe une coordination avec l'effort open source de la calculatrice. À la fois pour la cohérence dans l'apparence de la calculatrice Flyout, mais aussi dans le moteur qui la sous-tend.

Je ne sais pas si c'est l'endroit pour poster cette image, mais voici des conceptions pour les différents états qui sont conformes aux spécifications.

L'image est à l'échelle 200 %

@mdtauk à quoi

Quel état chaque image tente-t-elle de montrer ? Sans que vous le clarifiiez, nous pouvons faire des hypothèses différentes des vôtres.

Sont-ils destinés à être des références parfaites au pixel près ?

Pouvez-vous indiquer où quelque chose dans vos images diffère de la valeur par défaut de la plate-forme ou du contrôle de base afin de savoir clairement ce que vous ajoutez ou modifiez (le cas échéant).

@mrlacey, je pourrais faire une

Leur but est d'essayer d'illustrer à quoi pourraient ressembler ces contrôles avec les différents éléments de contrôle proposés tels que préfixe, suffixe, masques, boutons haut et bas. Ils sont extrapolés à partir des conceptions de contrôle FabricWeb, mais à l'aide d'éléments XAML tels que FocusReveal et contrôlent le dimensionnement des boutons.

Les exemples montrent l'état Rest - Focus - Disabled

La calculatrice contextuelle serait une fonctionnalité intéressante pour la V2.

Je ne sais pas trop où mettre mes remarques. Dois-je faire un PR sur les spécifications ou puis-je continuer à écrire mes réflexions dans ce numéro ?

Entier

Une valeur entière pour le NumberBoxFormatType serait-elle utile ?

enum NumberBoxFormatType
{
    IPAddress,
    InternationalTelephone,
    Currency,
    Integer,
}

Langue

Utiliseriez-vous la langue pour spécifier la devise, les symboles de regroupement de chiffres décimaux ?

Dans l'exemple suivant, la langue est définie sur nl-NL. Cela signifie-t-il que le préfixe est le signe Euro, le symbole décimal une virgule avec 2 décimales après et le groupement de chiffres est un point ? La devise négative a un signe moins devant et pas de parenthèse comme aux États-Unis.

<TextBlock Header="Price" 
    PlaceholderText="0,00" 
    FormatType="Currency"
    Language="nl-NL" />

Est-ce suffisant car il existe de nombreuses options de format de nombre et de devise dans Windows.

Valeur propriété ou propriétés

Avons-nous besoin d'une propriété Value et de quel type (numérique) ce serait. Je l'utiliserais pour le lier. Doit-il s'agir d'un double, d'un décimal ou d'un int. Avons-nous besoin du support Nullable (double ?, décimal ?, int ?). Je ne veux pas utiliser la propriété Text du contrôle TextBox hérité pour la liaison de données. Nous avons également besoin d'un support pour Decimal, le double ne suffit pas.

<TextBlock Header="Price" 
    Value="{x:Bind ViewModel.Employee.Salary, Mode=TwoWay}"
    PlaceholderText="0.00" 
    FormatType="Currency"
    Language="nl-NL" />

Que faire si la propriété Salary de l'employé est une valeur Nullable(décimal?). Avons-nous besoin de la propriété de dépendance ValueNullableDecimal. Le SelectedDate du contrôle DatePicker est un Nullable. Nullable est un problème, en particulier avec la liaison de données.

<TextBlock Header="Price" 
    ValueNullableDecimal="{x:Bind ViewModel.Employee.Salary, Mode=TwoWay}"
    PlaceholderText="0.00" 
    FormatType="Currency"
    Language="nl-NL" />

Même chose avec MinValue et MaxValue. Ils sont maintenant Integer dans la Spec mais cela ne devrait-il pas être un Double ?.

@sonnemaf parce que la spécification dit que le contrôle est pour tout ce où des chiffres peuvent être entrés, je pense que cela doit signifier qu'il traite la "Valeur" comme du texte et s'appuie sur le code de consommation pour convertir si nécessaire. Ce n'est pas idéal, mais même s'il y avait une propriété Value qui était longue ou flottante, il y aurait toujours de nombreuses occasions où des conversions seraient nécessaires.
C'est mieux que les surcharges pour chaque type numérique.
Ensuite, il y a des choses pour lesquelles le contrôle est conçu et qui ne peuvent pas être convertis en un type "numérique", comme le code postal américain, le numéro de téléphone ou l'adresse IP. Pour ce genre de valeurs, obtenir le texte semble être la meilleure (seule) option.
Je pense qu'il est plus simple (au moins dans la version initiale d'avoir un moyen d'accéder à la valeur entrée et de s'appuyer sur des convertisseurs si nécessaire. Je peux voir une place pour une collection d'assistants (ou de sous-classes) arrivant dans la boîte à outils au départ, puis certains de ceux-ci étant incorporés dans le contrôle principal sur la base du retour d'informations.

Une propriété Language nécessaire ? Pourquoi ce ne serait pas la même chose que UILocale ? Il peut y avoir de bonnes raisons, mais il semble que cela devrait être configurable par l'utilisateur (au niveau du système d'exploitation) et donner la possibilité de spécifier un format spécifique pourrait entraîner plus de problèmes pour les développeurs lorsque le format ne correspond pas ailleurs ou à ce que l'utilisateur de l'application veut. De mémoire : et si quelqu'un collait une valeur dans un format différent ?

@mdtauk à quoi

Quel état chaque image tente-t-elle de montrer ? Sans que vous le clarifiiez, nous pouvons faire des hypothèses différentes des vôtres.

Sont-ils destinés à être des références parfaites au pixel près ?

Pouvez-vous indiquer où quelque chose dans vos images diffère de la valeur par défaut de la plate-forme ou du contrôle de base afin de savoir clairement ce que vous ajoutez ou modifiez (le cas échéant).

@mrlacey Est-ce le genre de chose que vous vouliez ?

@mdtauk c'est un peu mieux car cela explique une partie de ce que vous essayez de montrer.

La question sous-jacente demeure cependant : quel est votre objectif en montrant cela ? C'est juste une idée ? Est-ce votre version préférée après avoir exploré différentes idées ? Si oui, pourquoi sont-ils les meilleurs/préférés ?

La comparaison des contrôles actuels avec la façon dont vous souhaitez que les nouveaux contrôles soient affichés dans vos nouveaux styles préférés à l'échelle du système signifie qu'il n'est pas possible de séparer ce qui est spécifique au contrôle avec ce qui est dans vos nouveaux styles préférés à l'échelle du système.

Par exemple, vous mentionnez la modification de la transparence sur une bordure. Ce changement est-il destiné à tous les contrôles ou uniquement à celui-ci ? Et dans quels états ?

Donner des tailles explicites (pour les boutons) peut être problématique dans les compositions de conception car elles ne se traduisent pas toujours de manière uniforme en fonction du redimensionnement de leur conteneur. Devraient-ils toujours être carrés ? ou leur largeur est-elle fixée en fonction de la hauteur de contrôle par défaut ?

Comment proposez-vous le pinceau d'arrière-plan pour les préfixes et les suffixes est déterminé? Je suppose qu'il s'agit d'un pinceau système existant, mais lequel ?

Le masquage n'est pas couvert dans cette spécification. Vos exemples « masqués » sont-ils destinés à être liés aux chaînes de format ?
Comment est-ce que tu es masqué par exemple correspond à un format ?
Je suppose que votre exemple montre l'entrée d'une adresse IP de version 4, mais il semble qu'il y ait beaucoup d'hypothèses basées sur la façon dont tout semble s'adapter parfaitement. Toutes les valeurs non saisissables doivent-elles avoir un arrière-plan et des marges ? Et s'ils ne sont pas toujours affichés ? Le contenu doit-il être étiré pour s'adapter à tout l'espace disponible, comme cela semble être le cas dans votre exemple ? Comment l'espace alloué aux valeurs non saisissables sera-t-il traité lors du panoramique de contenu plus large que l'espace disponible ?

@mdtauk c'est un peu mieux car cela explique une partie de ce que vous essayez de montrer.

La question sous-jacente demeure cependant : quel est votre objectif en montrant cela ? C'est juste une idée ? Est-ce votre version préférée après avoir exploré différentes idées ? Si oui, pourquoi sont-ils les meilleurs/préférés ?

La comparaison des contrôles actuels avec la façon dont vous souhaitez que les nouveaux contrôles soient affichés dans vos nouveaux styles préférés à l'échelle du système signifie qu'il n'est pas possible de séparer ce qui est spécifique au contrôle avec ce qui est dans vos nouveaux styles préférés à l'échelle du système.

Par exemple, vous mentionnez la modification de la transparence sur une bordure. Ce changement est-il destiné à tous les contrôles ou uniquement à celui-ci ? Et dans quels états ?

La spécification NumberBox n'incluait aucun exemple visuel et les images de la proposition originale sont des exemples approximatifs de fonctionnalité. Il existe un autre PR #524 où les modèles de contrôle sont mis à jour avec les valeurs CornerRadius à 2epx, qui est également le même arrondi utilisé par Fabric Web.

Donc, en supposant que les contrôles dérivés de TextBox seront également mis à jour de la même manière, je l'ai utilisé comme guide pour montrer comment la fonctionnalité proposée de NumberBox pourrait s'y intégrer. Les champs de texte Fabric Web prennent déjà en charge les valeurs de préfixe et de suffixe. J'ai donc simplement pris cette conception et utilisé les métriques XAML.

Donner des tailles explicites (pour les boutons) peut être problématique dans les compositions de conception car elles ne se traduisent pas toujours de manière uniforme en fonction du redimensionnement de leur conteneur. Devraient-ils toujours être carrés ? ou leur largeur est-elle fixée en fonction de la hauteur de contrôle par défaut ?

La zone de texte actuelle comporte des boutons intégrés, tels que la zone de recherche, le bouton Révéler le mot de passe et le bouton Effacer le texte. Les cibles tactiles pour XAML suggèrent que les boutons soient de 32 x 32 epx - je les ai juste gardés carrés et j'ai utilisé ces conseils.

Comment proposez-vous le pinceau d'arrière-plan pour les préfixes et les suffixes est déterminé? Je suppose qu'il s'agit d'un pinceau système existant, mais lequel ?

Dans mon exemple, j'ai utilisé la couleur de premier plan du thème mais en utilisant une opacité de 15%. Les FabricWeb utilisent près de 10 % et les boutons XAML 20 %.
Il existe des valeurs de pinceau similaires comme ListLowBrush, mais il peut nécessiter un nouveau pinceau TextBoxAppendixBackground. Le premier plan de texte utiliserait le même pinceau PlaceholderTextForeground.

Le masquage n'est pas couvert dans cette spécification. Vos exemples « masqués » sont-ils destinés à être liés aux chaînes de format ?
Comment est-ce que tu es masqué par exemple correspond à un format ?
Je suppose que votre exemple montre l'entrée d'une adresse IP de version 4, mais il semble qu'il y ait beaucoup d'hypothèses basées sur la façon dont tout semble s'adapter parfaitement. Toutes les valeurs non saisissables doivent-elles avoir un arrière-plan et des marges ? Et s'ils ne sont pas toujours affichés ? Le contenu doit-il être étiré pour s'adapter à tout l'espace disponible, comme cela semble être le cas dans votre exemple ? Comment l'espace alloué aux valeurs non saisissables sera-t-il traité lors du panoramique de contenu plus large que l'espace disponible ?

Je ne prétendrai pas avoir toutes les réponses à cela, et la façon dont elle est visiblement affichée sur le contrôle dépendra de la façon dont la mise en forme du masque est implémentée dans les contrôles.

J'ai utilisé l'adresse IP v4 car c'est l'exemple présenté dans la spécification, et mon intention initiale était d'illustrer ce qui était proposé (bien que les exemples de préfixe et de suffixe manquaient, j'ai donc choisi d'autres valeurs)

J'ai examiné comment d'autres contrôles gèrent le masquage et certains utilisent du texte en ligne qui déplace le curseur au fur et à mesure que les valeurs sont entrées. D'autres entreront des choses comme des parenthèses et des traits d'union lors de la saisie d'un numéro de téléphone. Certains utilisent la tabulation ou les touches fléchées pour se déplacer entre les segments. L'exemple le plus proche de Microsoft qui me vient à l'esprit est la saisie des clés de produit lors de l'installation de Windows.

Je pensais qu'utiliser le même style que les éléments ajoutés conviendrait à l'esthétique, mais je suis conscient que cela ajoute à la longueur du contrôle pour l'intégrer à tout, et l'inline peut mieux utiliser l'espace.

Juste une note car je travaille avec TextBox maintenant, avec elle, il n'y a pas d'événement unique pour signaler une valeur modifiée par l'utilisateur (c'est-à-dire l'union de la mise au point perdue et de la touche de retour enfoncée), similaire à https://doc.qt.io /qt-5/qlineedit.html#textEdited ce serait formidable d'avoir cela dans le NumberBox car il est destiné à ce type de modifications. Au fait, s'il doit gérer toutes sortes de valeurs comme les adresses IP, peut-être que "Number" Box est un nom trop étroit ? Il pourrait ValueBox ou ainsi

@adrientetar NumberBox semble bien comme nom, car toutes les entrées comptent comme des nombres. L'adresse IP a 4 numéros, numéros de téléphone, devise, mesures, etc.

DigitBox, NumeralBox, etc. sont toutes des variantes qui ne correspondent pas tout à fait au style de dénomination de Microsoft.

Les valeurs ne doivent pas non plus être de nature numérique, donc ValueBox peut également être un peu trompeuse.

@sonnemaf et @mdtauk , j'ai parlé à mon équipe de l'idée de la calculatrice embarquée et en bref nous l'ADORONS - sans exagération. Nous sommes plus que ravis de la façon dont vous avez tous déjà amélioré la qualité et la créativité des contrôles que nous livrons.

J'aurai besoin de votre aide pour y arriver. La façon dont nous restons au courant de la litanie d'idées géniales qui viennent de notre référentiel est d'être non seulement axée sur les idées, mais également sur les scénarios. (Je partage cela car parler ce langage donnera à vos demandes de fonctionnalités un poids concret tout au long de notre référentiel.)

L'un de vous peut-il m'offrir des scénarios réels pour une calculatrice intégrée dans l'une des applications que vous développez ? Le contexte, les captures d'écran, les profils d'utilisateurs sont tous utiles. (Mon e-mail est également sur mon profil GitHub si vous préférez garder les détails confidentiels.) @xyzzer , @mrlacey , @robloo , @Felix-Dev, @adrientetar et @ArchieCoder , n'hésitez pas à partager votre scénario d'utilisation si cette fonctionnalité vous intéresse également.

Au-delà de cette étape, la seule chose qui pourrait obstruer cette fonctionnalité serait un risque de gonfler la taille de la DLL de WinUI avec le moteur de l'application de calculatrice. Je vais étudier cela en parallèle pour évaluer la faisabilité.

J'ai précédemment évoqué le problème du traitement de ce contrôle pour plus que des types numériques.

Il existe une différence fondamentale entre un nombre et une chaîne contenant une séquence de chiffres.

C'était avant la publication de la première ébauche de la spécification, donc je suppose que cela a été pris en compte et que la décision a été prise de faire en sorte que ce contrôle gère à la fois les "valeurs numériques traditionnelles" et les "chaînes contenant des chiffres".

Je ne pense pas que quiconque essaierait vraiment de soutenir qu'une adresse IPv4 était un "nombre" par une autre définition que celle qui n'est généralement pas représentée que comme une séquence formatée de chiffres. En réalité, c'est juste une valeur de 4 octets.

@SavoySchuler

• Saisir les dépenses peut-être - saisir ces éléments à partir d'un reçu où certains éléments sont personnels et d'autres font partie du travail.
• Application de restaurant lors du fractionnement d'une facture, ou peut-être pour le calcul du pourboire ?
• Application d'édition hexadécimale, pour calculer une valeur de décalage vers laquelle déplacer la sélection ?

Avoir un contrôle prenant en charge les adresses IP serait un excellent ajout à la plate-forme, mais je ne pense pas que NumberBox soit le bon contrôle pour ce scénario.

Comme mentionné précédemment, le contrôle NumberBox :

• utiliser le clavier virtuel Number lorsqu'il est utilisé sur un appareil sans clavier physique
• avoir 2 boutons -/+
• afficher une fenêtre contextuelle avec une calculatrice ou permettre à l'utilisateur de saisir des opérations arithmétiques de base

Aucune de ces fonctionnalités n'a de sens avec l'adresse IP. Même la conception du contrôle est très différente.

De plus, nous devons garder à l'esprit que si nous prenons en charge les adresses IPv4, nous devons également prendre en charge les adresses IPv6, en utilisant non pas des chiffres mais des hexadécimaux.

Je pense qu'il serait plus logique de ne pas inclure la prise en charge des adresses IP dans ce contrôle, mais plutôt de travailler sur un nouveau contrôle MaskedTextBox pour UWP (prenant en charge IPv4, IPv6, numéro de téléphone, code postal, SSN, etc...) avec une interface utilisateur riche (comme démontré par @mdtauk) pour remplacer/améliorer TextBoxMask de la boîte à outils communautaire (https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask)

Avoir un contrôle prenant en charge les adresses IP serait un excellent ajout à la plate-forme, mais je ne pense pas que NumberBox soit le bon contrôle pour ce scénario.

Comme mentionné précédemment, le contrôle NumberBox :

• utiliser le clavier virtuel Number lorsqu'il est utilisé sur un appareil sans clavier physique
• avoir 2 boutons -/+
• afficher une fenêtre contextuelle avec une calculatrice ou permettre à l'utilisateur de saisir des opérations arithmétiques de base

Aucune de ces fonctionnalités n'a de sens avec l'adresse IP. Même la conception du contrôle est très différente.

De plus, nous devons garder à l'esprit que si nous prenons en charge les adresses IPv4, nous devons également prendre en charge les adresses IPv6, en utilisant non pas des chiffres mais des hexadécimaux.

pense qu'il serait plus logique de ne pas inclure la prise en charge des adresses IP dans ce contrôle, mais plutôt de travailler sur un nouveau contrôle MaskedTextBox pour UWP (prenant en charge IPv4, IPv6, numéro de téléphone, code postal, SSN, etc...) avec une interface utilisateur riche (comme démontré par @mdtauk) et remplaçant/améliorant TextBoxMask de la boîte à outils communautaire (https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask)

@rudyhuyn Je suis principalement d'accord avec ce que vous venez de dire ici, et mes illustrations étaient pour la spécification proposée.

Mais comme cela a été mentionné par d'autres, une zone de texte masquée n'a pas besoin d'être limitée uniquement aux chiffres et peut également inclure des chaînes. La zone Clé de produit Microsoft est un bon exemple, où 5 jeux de caractères 0-9 AZ sont acceptés.

Même si le masquage était séparé, je pense toujours qu'il existe de bons cas d'utilisation pour inclure les propriétés PrefixText et SuffixText au contrôle NumberBox. La devise, les mesures, toutes nécessitent une sorte de contexte.

Les boutons rotatifs servent uniquement à incrémenter et à décrémenter des valeurs, ils entrent donc également dans le champ d'application d'un contrôle NumberBox.

Le préfixe et le suffixe pourraient devenir des propriétés du contrôle TextBox lui-même, et donc hérités par les autres contrôles. (Il peut être nécessaire d'avoir une exception pour le PasswordBox s'il ouvre des vulnérabilités)

Les masques pour les valeurs communes peuvent être une énumération (avec un CustomFormatMask) pour ce contrôle séparé. Certains de ces masques peuvent impliquer un contexte culturel, tel qu'un code postal britannique alphanumérique et des numéros d'assurance nationale britanniques suivant un formatage spécial, etc.

SW1A 2AA

Exemple de code postal au Royaume-Uni (pour le n° 10 Downing Street)

Il semble que je n'ai pas réussi à rafraîchir la page ce matin avant d'envoyer ma réponse... Merci à toutes les rockstars d'avoir

@mdtauk - vos maquettes sont fantastiques. Je n'avais pas encore rédigé de prototypes pour ce contrôle. Puis-je décomposer votre maquette et les ajouter à la spécification en tant que prototypes pour que nos concepteurs puissent commencer leur palette ? Je vais contacter un designer aujourd'hui et voir si je peux l'amener à répondre à votre fil avec @mrlacey ici. Je vais lire votre fil et vous répondre plus en détail sous peu.

@sonnemaf , encore merci ! Je vous encourage à copier votre commentaire et à le republier ici sur l' onglet de conversation de Pull Request . C'est là que notre équipe d'ingénierie commencera à s'engager au niveau de l'API et de la mise en œuvre. Dans un souci de fournir une réponse complète, c'est aussi là que je commence à rédiger des directives et de la documentation. Je préface les commits avec [DEV] pour le premier et [PM] pour le second. Sinon, c'est toujours le bon forum pour les discussions de haut niveau sur les exigences (comme la calculatrice intégrée et les maquettes de @mdtauk ).

@mdtauk : Je suis d'accord avec toi, un Préfixe/Suffixe serait un bon ajout à TextBox et ne se limiterait pas aux nombres, quelques exemples :

• demander à un employé de saisir son adresse e-mail lorsque le domaine est toujours le même (@microsoft.com par exemple).
• saisir le nom d'un formulaire lorsqu'il commence toujours par un W-

etc...

Vous devriez ouvrir un autre ticket pour que nous puissions commencer une discussion à ce sujet !

@rudyhuyn voyez -vous la possibilité de ne pas prendre en charge quelque chose comme une adresse IP, mais la possibilité de prendre en charge un numéro de téléphone ou un code postal comme réalisable ?
Ma pensée est que si vous commencez à restreindre certaines choses mais pas d'autres, les règles de ce qui est couvert doivent être très clairement définies.
Le simple fait de prendre en charge des valeurs qui peuvent être présentées sous forme d'entier, de flottant, etc. rend les choses très claires et crée toujours un contrôle qui fournit beaucoup de valeur.

@SavoySchuler Mes designs sont entièrement à votre disposition, je les ai postés pour essayer d'aider à visualiser le contrôle pour tous ceux qui contribuent.

@rudyhuyn Si vous deviez publier une proposition de MaskedTextBox ou de FormattedTextBox, cela pourrait avoir plus de poids ! Comme pour le NumberBox, je suis heureux que l'un de mes designs soit inclus dans une telle proposition, et je peux faire plus d'exemples selon vos besoins.

@mrlacey Les numéros de téléphone (à part les caractères de mise en forme) sont des nombres purs - mais ils ne relèvent d'aucun type de cas d'utilisation de calcul.

Lors de la création du contrôle et de la documentation fournissant un cas d'utilisation clair et des exemples pour quel contrôle utiliser dans quel contexte est important.

@mrlacey : Non.

Comme vous l'avez dit précédemment, nous devrions séparer les nombres réels, non seulement quelque chose utilisant 0-9 caractères, mais associé à une valeur arithmétique.

Une adresse IP, un numéro de téléphone, un SSN, un code postal utilisent de 0 à 9 caractères mais n'ont pas de valeurs arithmétiques (vous pouvez en ajouter 2, si vous ajoutez ".00" à la fin vous changez le sens de la valeur, etc..) . Dans ces cas, la valeur est une chaîne, pas un int/double, un MaskedTextBox aurait plus de sens.

De plus, un code postal n'utilise que des chiffres aux USA, mais pas au Canada par exemple, une adresse IPv6 peut contenir des caractères AF, un numéro de téléphone peut contenir un signe + (555-123-4567 et +555-123-4567 sont 2 différents numéros de téléphone), etc...

Pour résumer mon opinion, NumberBox.Value devrait être un double, pas une chaîne.

@mrlacey Les numéros de téléphone (à part les caractères de mise en forme) sont des nombres purs - mais ils ne relèvent d'aucun type de cas d'utilisation de calcul.

Les numéros de téléphone peuvent être entièrement composés de chiffres (plus la mise en forme), mais cela n'en fait pas des numéros. Vous ne pouvez faire aucune opération arithmétique sur eux et obtenir quelque chose de significatif.
En outre, certains peuvent commencer par un signe plus.
De plus, le nombre de zéros non significatifs dans un numéro de téléphone est significatif. Pour une valeur numérique, ce n'est pas le cas.
Les autres fonctionnalités du contrôle, telles que les calculs ou les boutons haut et bas, n'ont aucun sens pour un "numéro de téléphone".

Ce contrôle doit être limité aux valeurs pouvant être converties en int/uint ou en décimal sans risque de perte d'informations.

Pour vous assurer que je synthétise ces commentaires de manière appropriée, veuillez me donner un coup de pouce sur ce commentaire si vous pensez que c'est le meilleur endroit pour tous les types de saisie de chaînes numériques (comme les numéros de téléphone et IPv4) via les types de format et un pouce- vers le bas si cette fonctionnalité doit être différée vers un autre ou un nouveau contrôle afin que NumberBox se concentre exclusivement sur les mathématiques et la capture de valeurs mathématiques. (En notant les fonctionnalités qui prennent en charge les opérations mathématiques telles que le mode calculatrice et les boutons Haut/Bas nécessitent une activation via les API respectives.)

Je ne peux pas garantir que cela sera décidé démocratiquement car je prendrai la décision qui se traduira par le meilleur retour sur investissement pour nos clients à l'échelle mondiale - mais cela aidera à valider ce que je pense voir ici : personne ne demande cela pour soutenir le numérique chaînes et préférerait un contrôle dédié pour cela.

@SavoySchuler Des nombres pouvant être utilisés, incrémentés et décrémentés, ainsi que des préfixes et des suffixes qui ajoutent du contexte et du sens à la valeur.

Je viens de me synchroniser avec l'équipe ici et je voulais partager des mises à jour sur certaines de nos questions ouvertes :

• Nous écoutons vos commentaires et nous convenons que NumberBox n'est pas le bon endroit pour les chaînes numériques. Les propriétés FormatKinds et CustomFormat ont été remplacées par des API plus spécifiques pour contrôler le format des nombres de manière plus intuitive.
• Le préfixe et le suffixe appartiennent vraiment à la TextBox (dont NumberBox les héritera). Je vais donner à @mdtauk , @mrlacey , ou à toute autre personne quelques jours d'avance pour proposer la demande de fonctionnalité, sinon je vais la démarrer et la lier ici. Pour le moment, cela évitera à NumberBox de se bloquer sur la sortie de localisation/automatisation.
• Le flux final dans un NumberBox (après calcul, arrondi, etc.) sera conservé en tant que chaîne dans la propriété Text qui sort de TextBox ET en tant que Double dans une nouvelle propriété Value. Nous avons l'intention d'avoir ces commentaires les uns aux autres afin que la modification de l'un se reflète dans l'autre. Le but de ceci est de vous décharger le plus de travail possible et d'avoir la valeur prête à être consultée lorsque vous en avez besoin.
• StepSize manquait en tant que propriété dans la spécification.
• Les types entiers seront remplacés par Double.
• Nous sommes toujours enthousiasmés par l'idée d'une calculatrice intégrée et recherchons plus de scénarios pour nous aider à affiner cela. @mdtauk , merci d'avoir déjà répondu à ce point de retour !
• En ce qui concerne la validation des entrées, l'idée est d'abord d'envoyer un événement de type ValueChanged qui donnera au développeur la possibilité de manipuler l'entrée ou de la gérer lors de la soumission du formulaire de fin/bloc selon les besoins. Si aucune mesure corrective n'est prise (telle que la contraindre dans les min/max, supprimer les caractères invalides, etc.), NumberBox affichera à la place une indication d'erreur à l'utilisateur concernant sa saisie. Cette double approche permet aux développeurs de répondre s'ils le souhaitent mais permet également de reporter la correction à l'utilisateur.

Il y a eu une quantité impressionnante de commentaires auxquels je réponds toujours. Merci pour votre patience, je répondrai à tout le monde ici et sur le dépôt de spécifications également !

"Concept art de NumberBox avec une calculatrice intégrée." Communauté WinUI, mai 2019. (colorisé)

(Compliment de @ryandemopoulos )

@SavoySchuler Vous avez demandé des exemples de scénarios dans lesquels le type de contrôle dont nous discutons pourrait être utilisé. J'en ai deux dans mon application qui peuvent être de bons exemples.

Cas 1 : Il existe un éditeur de paramètres pour les graphiques 2D où vous pouvez ajuster l'axe.

• Cela nécessite juste une simple entrée numérique. Les boutons d'incrémentation +/- seraient utiles ici.
• Une valeur double conviendrait, mais les entrées doivent être validées à la pression du caractère. L'utilisateur ne devrait même jamais pouvoir appuyer sur 'a' et le faire apparaître dans la zone de saisie. La validation d'entrée ne doit pas rendre la bordure rouge et avertir l'utilisateur - il ne devrait tout simplement pas être possible d'entrer une valeur invalide.
• La localisation devrait être prise en charge par le contrôle et le déplacement de la décimale (qu'il s'agisse d'une virgule, d'un point, etc.) traité comme un cas particulier (je continue de soulever cela car il est facile de le rater)

Cas 2 : Il existe un champ de saisie pour une valeur monétaire comme indiqué ci-dessous. Ceci est un contrôle personnalisé "CurrencyBox"

• Cela pourrait utiliser un bouton de calculatrice et la possibilité d'entrer les équations 2 + 3 aurait une certaine valeur ici (je pense toujours que cela devrait être un contrôle séparé cependant)
• Une valeur double n'est PAS idéale pour cela. Je suggérerais de changer la spécification de Value de double à décimale pour prendre en charge ce type de cas d'utilisation . Sinon, c'est au développeur d'analyser le texte de la chaîne.
• Il existe ici un cas particulier où le signe négatif est traité séparément. Cela permet à l'utilisateur de ne pas se tromper de signe plus facilement. Je ne m'attends pas à ce que la NumberBox prenne en charge cela dès la sortie de la boîte.
• L'alignement du texte est important à définir et un préfixe/suffixe serait extrêmement utile pour afficher un symbole monétaire (la localisation serait toujours potentiellement un problème pour savoir s'il faut afficher le symbole à droite ou à gauche ; cependant, l'application elle-même pourrait avoir cette logique)
• L'utilisateur peut saisir à la fois une valeur étrangère ou locale. Le NumberFormatInfo et CultureInfo pour ces deux valeurs PEUVENT différer de la culture de l'interface utilisateur. Par conséquent, pour la localisation, le contrôle doit prendre en charge le remplacement par un NumberFormatInfo personnalisé.

À l'heure actuelle, dans l'application, Windows Community Toolkit est utilisé dans les deux cas avec des propriétés attachées à la zone de texte comme ci-dessous :
TextBoxRegex.ValidationMode="Dynamique"
TextBoxRegex.ValidationType="Decimal"

Quelques derniers commentaires (désolé c'est si long !)

• Je pense que nous discutons ici potentiellement de 3 contrôles différents. Une NumberBox bar-bones, une CalculatorBox qui peut avoir des équations et une entrée numérique avancée (bouton de la calculatrice !), et enfin une MaskedTextBox pour la saisie non numérique comme les numéros de téléphone et les adresses IP. Nous ne devons pas les confondre et se mettre d'accord sur la façon de séparer ces concepts est la clé pour aller de l'avant avec la spécification.
• Nous ne pouvons pas perdre de vue le cas d'utilisation le plus basique et sans doute le plus utile : une zone de texte d'apparence normale avec rien de plus qu'un filtrage d'entrée afin que seul un nombre valide puisse être entré. Toutes les autres options devraient pouvoir être désactivées (je pense aux boutons d'incrémentation +/-)
• Je suggère toujours de passer du double au décimal dans la spécification pour capturer avec précision la précision décimale dans la valeur analysée. De plus, nous devrions probablement considérer l'entrée de nombres entiers différente de l'entrée de nombres rationnels. C'est probablement une nouvelle propriété dans l'API "IsInteger = true" pour changer la valeur décimale par défaut.

Edit : Suppression de l'idée de passer du double au décimal pour le type NumberBox.Value. J'avais tort de supposer que cela existait dans le monde C++ WinRT. Ce n'est pas le cas, et c'est seulement dans .net core/framework.

@robloo , à propos de ce dernier commentaire, il n'y a pas de type Decimal dans WinRT.

Le débogueur Visual Tree de XAML Toolkit est un outil qui repose fortement sur le contrôle NumericUpDown de la boîte à outils où l'incrémentation/décrémentation avec la souris, les boutons et le clavier sont tous importants. La saisie de la calculatrice peut également aider :

@robloo et @xyzzer , c'est exactement le genre d'info que je recherche !

Validation/Masquage

@robloo , je suis particulièrement intéressé par le cas 1 : Puce 2 - validation vs masquage. Parlons maintenant du scénario de "mauvaise entrée" :

• Un nouvel utilisateur tape "deux" dans votre NumberBox.
• Le NumberBox déclenche l'événement "ValueChanged" qui vous donne la possibilité de renvoyer une entrée non numérique à "0" - ou autrement - si vous le souhaitez. Si aucune mesure n'est prise, alors...
• Les lancements de validation dans NumberBox s'allument en rouge et font apparaître un message d'erreur à l'utilisateur l'informant que seule la saisie numérique est autorisée (cette partie n'a pas encore été entièrement rationalisée, il ne s'agit donc que d'une hypothèse).

Cette série d'événements vous donne-t-elle la possibilité de créer l'expérience dont vous avez besoin ?

Je comprends que le masquage pourrait être une valeur par défaut souhaitable, mais permettez-moi de partager ce que mon équipe a discuté la semaine dernière - nous avons atterri sur la direction que la validation (indicateur d'erreur/message) est préférée dans les contrôles Fluent car l'alternative, le masquage, peut être frustrant et déroutant pour les utilisateurs finaux lorsqu'ils ne reçoivent aucune sortie de leur entrée au clavier. Une autre façon de penser est que la validation offre un niveau de transparence et d'information à l'utilisateur qui le rend plus conscient de l'expérience au lieu d'être contraint en silence. Ainsi, notre plan d'action actuel consistait à intégrer une validation de base sans bloquer la possibilité pour le développeur d'ajouter une validation avancée (bientôt disponible dans TextBox) ou de masquer via l'événement ValueChanged selon les besoins. Pour comprendre, cela est suffisamment flexible pour permettre de répondre à tous les besoins tout en offrant l'expérience recommandée par défaut.

Quelles sont vos pensées ici? Je serais intéressé par toutes vos idées pour approfondir ces concepts ou créer une expérience encore meilleure si nous le pouvons.

Formatage des valeurs

Pour vos autres points, @robloo , j'ai ajouté une propriété de précision DecimalPrecision au Spec . Définir ce ="0" permettra d'obtenir des nombres entiers. De plus, la définition de MinValue="0" peut aider à garder les nombres non négatifs (ou l'événement ValueChanged est une autre occasion de forcer la saisie à des valeurs absolues).

Avez-vous déjà consulté la spécification ? Je pense avoir inclus toutes les propriétés nécessaires pour activer pleinement vos expériences (en attendant la discussion de validation vs masquage), mais je suis impatient de savoir si vous pensez que j'ai raté quelque chose.

masquage, peut être frustrant et déroutant pour les utilisateurs finaux lorsqu'ils ne reçoivent aucune sortie de leur entrée au clavier.

100% d'accord oui. La meilleure chose à faire est de valider sur LosingFocus/EnterPressed et de restaurer l'oldValue si la valeur saisie ne se valide pas, c'est pourquoi un signal qui se déclenche sur LosingFocus/EnterPressed et qui contient oldValue/newValue serait parfait.

@adrientetar , excellent point ! Est-ce une expérience que vous devez créer ? Si c'est le cas, je vais voir ce que nous devons faire pour que l'événement ValueChanged envoie à la fois l'ancienne valeur et la nouvelle valeur.

@SavoySchuler C'est quelque chose que je veux faire dans mon application en effet, je construirais ce comportement moi-même à moins que le contrôle ne le fasse par défaut.

L'autre chose que je voudrais, c'est Shift+↑/↓ pour des incréments de 10 et Ctrl+Shift+↑/↓ pour des incréments de 100, bien que je pense que les incréments de 100 n'ont pas toujours de sens.

Excellent point ! Nous devons nous assurer que le contrôle dérive de RangeBase qui
définit à la fois SmallChange et LargeChange et que nous utilisons les deux à
le moins.
Existe-t-il un exemple de combinaisons de touches standard à utiliser pour invoquer
grand changement sur RangeBase d'UWP ou WinForms/ComCtl (?) NumericUpDown?

Le lun 3 juin 2019 à 15h50 Adrien Tétar [email protected]
a écrit:

@SavoySchuler https://github.com/SavoySchuler C'est quelque chose que je veux
faire dans mon application en effet, je construirais ce comportement moi-même à moins que le contrôle ne le fasse
par défaut.

L'autre chose que je voudrais, c'est Shift+↑/↓ pour des incréments de 10 et
Ctrl+Maj+↑/↓ pour des incréments de 100, bien que je compte des incréments de 100
n'a pas toujours de sens à avoir.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMFZBHJIE4DR2KN46TTPYWN3BA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVL5WW2KN46TTPYWN3BA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVL5WWZHJ2K45
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AANMBMG4AWBK44VE4O4GYR3PYWN3BANCNFSM4HA4PBNA
.

Je vais vérifier pour vérifier, mais je suis assez confiant que les raccourcis clavier devront être laissés aux applications à mettre en œuvre. J'ai essayé cela avec la justification d'accessibilité pour # 21 et l'introduction de nouveaux raccourcis clavier est un jeu risqué à jouer car presque tous ceux qui n'étaient pas revendiqués par Windows ont maintenant été pris au niveau de l'application (cela étant dit, TeachingTip a pu sauter dessus le train en marche F6) - mais je vais vérifier si le focus de contrôle permet une exception ici !

La version 2018 a eu lieu lorsque les états de validation des contrôles TextBox ont été annoncés, en utilisant INotifyDataErrorInfo.
Ce serait bien à utiliser avec le masquage pour valider ou invalider la chaîne de texte actuelle.

EDIT : L'utilisation de l'icône et de la couleur de la bordure inférieure plus épaisse est d'aider à la reconnaissance dans les situations de daltonisme et lorsqu'on les regarde en noir et blanc. Le texte d'erreur inférieur peut être affiché sous forme d'info-bulle sur l'icône si l'espace est limité.

@mdtauk, vous êtes phénoménal à ces

@SavoySchuler Extrapolation facile basée sur l'exemple montré à Build 2018

Et il y a beaucoup d'exemples à regarder :)

Mes excuses, c'est encore un long !

@SavoySchuler @adrientetar Je vois vraiment d'où vous venez avec vos déclarations ci-dessous. Je ne prétendrai pas que dans la grande majorité des cas, c'est la meilleure façon de gérer la validation. Cependant, je dois penser qu'il existe des cas particuliers où il s'agit si manifestement d'une entrée numérique que vous rendez en fait une faveur à l'utilisateur en ne lui permettant pas de saisir le mauvais caractère.

masquage, peut être frustrant et déroutant pour les utilisateurs finaux lorsqu'ils ne reçoivent aucune sortie de leur entrée au clavier.

100% d'accord oui. La meilleure chose à faire est de valider sur LosingFocus/EnterPressed et de restaurer l'oldValue si la valeur saisie ne se valide pas, c'est pourquoi un signal qui se déclenche sur LosingFocus/EnterPressed et qui contient oldValue/newValue serait parfait.

Néanmoins, j'ai décidé de fouiller dans d'autres applications pour voir comment c'est géré. Je ne pense pas que quiconque fasse plus de recherches que Microsoft sur l'interaction avec l'utilisateur, j'ai donc récupéré la version Desktop 64 bits de Word, puis la version UWP de OneNote pour référence. Il est plus ou moins tout à fait d'accord avec ce que vous dites. Je peux taper n'importe quel texte dans les zones de saisie de taille de police ou de taille de forme qui ne sont clairement que des saisies numériques. Il valide en grande partie la perte de focus et revient à la dernière entrée valide.

| Titre | Photo | Commentaire |
|------|-----|-----------|
| Saisie de la taille de la police UWP OneNote | | N'importe quelle valeur peut être saisie à partir du clavier, elle est automatiquement validée et réinitialisée à la dernière valeur valide en cas de perte de focus |
| Entrée de la taille de la police Word du bureau | | Toute valeur peut être saisie au clavier, elle est automatiquement validée en cas de perte de focus et un message d'erreur apparaît si invalide. En cliquant sur [OK], la dernière valeur valide est réinitialisée. |
| Graphique 2D UWP OneNote | | Toute valeur peut être saisie à partir du clavier. Les valeurs invalides seront simplement ignorées et la dernière entrée valide utilisée dans le calcul (ne valide pas en cas de focus perdu). Appuyez sur les boutons d'incrémentation +/- pour incrémenter en utilisant la dernière entrée valide. |
| Entrée de taille de forme de mot de bureau | | N'importe quelle valeur peut être saisie à partir du clavier, elle est automatiquement validée en cas de perte de focus et réinitialisée à la dernière valeur valide en cas de perte de focus. |

Donc je suppose que je viens de prouver que j'avais tort, ce qui signifie que je devrais être d'accord avec vous !

Commentaires secondaires :

• Comme mentionné précédemment par quelqu'un d'autre, lorsque NumberBox a le focus clavier avec un clavier tactile/virtuel, seul le clavier numérique doit être affiché.
• L'incrément vers le bas à gauche et l'incrément vers le haut à droite est une idée intéressante à discuter ici en termes de style. Je l'aime bien!
  

• Un nouvel utilisateur tape "deux" dans votre NumberBox.
• Le NumberBox déclenche l'événement "ValueChanged" qui vous donne la possibilité de renvoyer une entrée non numérique à "0" - ou autrement - si vous le souhaitez. Si aucune mesure n'est prise, alors...
• Les lancements de validation dans NumberBox s'allument en rouge et font apparaître un message d'erreur à l'utilisateur l'informant que seule la saisie numérique est autorisée (cette partie n'a pas encore été entièrement rationalisée, il ne s'agit donc que d'une hypothèse).
  Cette série d'événements vous donne-t-elle la possibilité de créer l'expérience dont vous avez besoin ?
  Quelles sont vos pensées ici? Je serais intéressé par toutes vos idées pour approfondir ces concepts ou créer une expérience encore meilleure si nous le pouvons.

Je comprends et suis tout à fait d'accord que l'ajout de la validation des entrées est excellent pour l'ensemble de la plate-forme. Cependant, vous venez essentiellement de décrire la validation d'entrée sans traitement spécial pour un nombre. Par conséquent, à quoi sert une NumberBox à part l'analyse automatique d'une valeur ? En tant que développeur, il semble qu'un TextBox avec validation des données soit plus ou moins le même.

Je pense que sur la base de mes exemples ci-dessus, la fonctionnalité prête à l'emploi devrait être un mélange de nos deux idées et c'est ce que dit

En termes d'événements, j'aimerais toujours avoir la possibilité d'annuler les modifications de texte si jamais ce cas d'utilisation devient plus clair. Par conséquent, en plus de ValueChanged, je recommanderais un événement ValueChanging et TextChanging pour permettre la comparaison et l'annulation des entrées. Une OldValue et une NewValue sont définitivement nécessaires, cela nous permettrait au moins de la remplacer rapidement par OldValue si nécessaire (bien que UWP aime se bloquer lorsque vous modifiez la TextValue dans un événement).

Concernant la spécification : Bonnes idées avec DecimalPrecision, il me faudra cependant plus de temps pour la parcourir et ajouter mes commentaires. Il y a beaucoup de petites nuances comme la valeur par défaut devrait être String=Empty, Value=Null et lorsqu'un bouton d'incrémentation +/- est enfoncé, la valeur devrait plutôt être traitée comme zéro au lieu de vide.

@mdtauk Il ne devrait pas être humainement possible de faire de si bonnes illustrations si rapidement :)

@robloo Merci pour ce gentil commentaire. Je n'ai qu'un petit commentaire à faire concernant votre +/-
Il peut être préférable de s'en tenir aux symboles Haut et Bas utilisés dans les boutons de rotation actuels, pour éviter toute confusion avec les opérations mathématiques que cette NumberBox peut effectuer.

iOS utilise un contrôle "pas à pas", mais la saisie de texte est séparée et il n'y a pas de calcul en ligne.

Voici d'autres modèles que j'ai trouvés

Le design que j'ai choisi semble correspondre au style typique de Microsoft pour ce contrôle, mais est-ce le meilleur choix ou le bon choix. Je serais curieux de savoir ce que les autres en pensent.

EDIT : Ajout de quelques maquettes de formes alternatives (mais je pense que la première idée est la meilleure...)

Je suis d'accord avec @mdtauk sur l'emplacement +/-, le premier est le meilleur.

Il existe un ControlTemplate XAML afin que l'utilisateur (développeur) puisse toujours créer un modèle personnalisé pour les deux autres mises en page.

@robloo , vous n'avez pas besoin de vous excuser pour des réponses détaillées - surtout quand elles ont quelques bons rires ! Excellente idée avec le clavier tactile/virtuel - je l'ai ajouté à la section Questions ouvertes sur les spécifications à exécuter par les développeurs/l'équipe et je m'assure qu'il n'y a pas de surcharge de performances inacceptable en le faisant. Je pense que ce serait une merveilleuse commodité pour les utilisateurs si nous pouvions y arriver.

Vous soulevez un grand point sur la validation...

[1] Heure des questions : quelqu'un serait-il contre un système de validation qui ramène automatiquement les entrées inacceptables à la valeur précédente tout en exposant des événements qui permettraient au développeur d'annuler ce comportement et de décider à la place quoi faire/soulever des indicateurs ou des messages d'erreur ?

Visuellement, je vois le mérite des UpDownButtons disjoints dans l'exemple que vous avez posté. Je pense que @mdtauk et @sonnemaf sont sur la bonne voie pour la valeur par défaut. La proximité des UpDownButtons est leur véritable commodité, que l'on teste le résultat aller-retour d'une entrée différente (mais pas distante) ou que l'on corrige une entrée dépassée. La distance, à moins qu'elle ne soit méritée par une conception ou une fonctionnalité améliorées, semblerait ajouter du travail évitable à l'expérience et pourrait également compromettre la clarté des propriétés/étiquetage des préfixes/suffixes par opposition au regroupement distinct en tant que partie fonctionnelle du contrôle, par exemple : $ [ - ] 192 [+]

Je crois qu'il existe des scénarios pour les UpDownButtons disjoints. Mon esprit va aux tâches qui attendent une entrée minimale et unidirectionnelle ou à celles où le développeur cherche à rendre les erreurs de saisie plus difficiles à commettre. Je crois que c'est l'expérience que plusieurs applications et sites Web donnent lorsque, par exemple, on achète des billets de cinéma ou de concert.

Ma question est alors...

[2] Heure des questions : devrions-nous nous fier au Xaml ControlTemplate pour créer un NumberBox avec des UpDownButtons disjoints (c'est-à-dire que ce n'est pas assez courant pour justifier la prise en charge prête à l'emploi) ou devrions-nous inclure une propriété pour définir si les UpDownButtons apparaissent contigus vs disjoint ?

Je vais envoyer un ping à

Je devrais inclure des considérations d'accessibilité pour la conversation UpDownButtons : la proximité des UpDownButtons les uns par rapport aux autres permet une clarté conceptuelle pour les utilisateurs de Narrateur/lecteur d'écran tout en maintenant l'efficacité de la navigation pour les utilisateurs de navigation au clavier et il est également important de ne pas compromettre cela.

Si le contrôle n'est pas très large, vous voudriez que les flèches s'empilent verticalement (je sais que j'en ai besoin dans mon application). Peut-être que le contrôle pourrait être rendu sensible à sa largeur définie ? C'est aux directives de conception fluides de le spécifier de cette façon s'ils pensent que cela a du sens.

J'ai mis à jour la proposition avec nos 3 questions ouvertes.

Merci @mdtauk pour les concepts design !

@adrientetar Je suis content que vous ayez souligné cela comme un besoin. On dirait que nous avons peut-être besoin d'une énumération pour ces trois configurations ?

Si le contrôle n'est pas très large, vous voudriez que les flèches s'empilent verticalement (je sais que j'en ai besoin dans mon application). Peut-être que le contrôle pourrait être rendu sensible à sa largeur définie ? C'est aux directives de conception fluides de le spécifier de cette façon s'ils pensent que cela a du sens.

Il y avait une proposition pour permettre aux commandes d'être conscientes et réactives de la quantité d'espace dont elles disposent. #677 Cela pourrait être utilisé pour repositionner les boutons de rotation à mesure que la commande devient plus étroite. Peut-être qu'il doit y avoir une propriété pour NarrowWidth similaire à MinWidth, ou peut-être même un NumberOfDigits pour servir d'indice ?

En ce qui concerne l'exemple de texte grisé, je crains que cela n'encourage l'utilisateur à saisir les valeurs qui apparaissent, plutôt que d'agir comme un indice sur le résultat final. Il ressemble au PlaceholderText.

Qu'en est-il de l'utilisation de l'AccentColor et d'un poids de police différent pour le faire ressortir

Super lien, @mdtauk. J'imagine que s'il s'agit d'une route que nous empruntons, nous pourrions gérer cela avec une énumération qui a des valeurs telles que [Auto, Vertical, Horizontal, Détaché] où Auto préférera Horizontal jusqu'à ce que la compacité impose Vertical. Les pensées?

Aussi, j'ai mis à jour l'image! Je pense que vous avez raison de dire que le texte grisé pourrait ressembler à une invite qui, si elle est suivie, entraînerait une erreur en raison du "=".

Super lien, @mdtauk. J'imagine que s'il s'agit d'une route que nous empruntons, nous pourrions gérer cela avec une énumération qui a des valeurs telles que [Auto, Vertical, Horizontal, Détaché] où Auto préférera Horizontal jusqu'à ce que la compacité impose Vertical. Les pensées?

Une première réflexion est la suivante : le nombre dans le conteneur sera-t-il un jour assez grand là où une orientation verticale serait nécessaire ? L'AutoCompleteBox ne déplace pas son bouton de recherche et les chaînes sont généralement plus longues que les nombres.

S'il s'agit de quelque chose qui dépend uniquement de l'espace disponible, un comportement réactif automatique (si cette proposition recevait le feu vert) serait mieux qu'une énumération. Donner aux développeurs l'option dans le contrôle lui-même pourrait conduire à une utilisation moins que cohérente du contrôle, mais je pense que cela devrait être quelque chose que la recherche utilisateur devrait examiner, je pense, plutôt que prescrit par nous seuls sur github.

Les développeurs ont toujours la possibilité de remodèler le contrôle s'ils ont vraiment besoin d'une disposition différente pour le contrôle, et il est possible d'inclure un style alternatif pour cela si vous voulez A) faire l'effort de faire à la fois le

@mdtauk Je suis d'accord que les symboles haut/bas sont les meilleurs. Je voulais juste montrer un exemple avec les flèches sur les côtés opposés de l'entrée. Comme mentionné précédemment, cela permet de garantir que l'utilisateur n'appuie pas sur le mauvais, ce qui est presque obligatoire dans une interface utilisateur tactile. L'exemple que j'ai donné de OneNote comportait des symboles +/- mais j'aurais dû ajouter pour ignorer les symboles eux-mêmes.

@SavoySchuler

[2] Heure des questions : devrions-nous nous fier au Xaml ControlTemplate pour créer un NumberBox avec des UpDownButtons disjoints (c'est-à-dire que ce n'est pas assez courant pour justifier la prise en charge prête à l'emploi) ou devrions-nous inclure une propriété pour définir si les UpDownButtons apparaissent contigus vs disjoint ?

Je sais que lorsque UWP a été créé pour la première fois, il était tactile en premier - par conséquent, des UpDownButtons disjoints seraient sans doute meilleurs. Depuis lors, les exigences relatives au toucher d'abord se sont assouplies et les boutons côte à côte sont certainement meilleurs lorsque l'utilisateur dispose d'une méthode de saisie précise telle qu'une souris (moins de distance de déplacement). Comme cela dépend du cas d'utilisation, je conviens qu'une énumération est utile pour spécifier comment les UpDownButtons doivent apparaître.

Pour les valeurs enum, nous avons discuté de plusieurs états et en généralisant nous pouvons en ajouter quelques autres :

• SéparéHorizontal : Flèche bas à gauche, Flèche haut à droite
• SéparéVertical : Flèche bas en bas, Flèche haut en haut
• Gauche : Flèches vers le bas et vers le haut côte à côte sur la gauche (dans une orientation horizontale)
• Droite : Flèches vers le bas et vers le haut côte à côte sur la droite (dans une orientation horizontale)
• Haut : Flèches vers le bas et vers le haut côte à côte en haut (dans une orientation verticale)
• Bas : Flèches vers le bas et vers le haut côte à côte en bas (dans une orientation verticale)

Si tout cela devient trop complexe (comme c'est rapidement le cas), je suis heureux de remodèler le contrôle pour mes propres cas d'utilisation en XAML.

Juste pour jeter une autre idée : changer l'orientation du symbole pour les UpDownButtons disjoints pourrait également avoir du sens [<] 123 [>] . N'hésitez pas à ignorer cette complexité supplémentaire, car cela pourrait certainement être relooké en fonction de l'application.

De plus, certains problèmes d'accessibilité ont peut-être déjà été résolus dans OneNote, d'où j'ai tiré l'exemple.

@robloo Je pense que les emplacements gauche et droit que vous mentionnez doivent être conservés pour la localisation RtL et LtR - plutôt que pour des paramètres discrets.

Ci-dessous mes avis

Je ne suis pas non plus sûr que le fait de placer les boutons au-dessus du champ de texte ait un sens sémantique, encore moins lorsque vous mettez votre doigt sur le bouton, peut rendre difficile de voir le nombre changer.

Avoir chaque combinaison intégrée dans le contrôle conduira à une utilisation chaotique, et toutes ces choses peuvent être faites avec un nouveau modèle s'il y a un besoin urgent.

Les boutons situés sous le champ de texte peuvent avoir une certaine utilité dans les zones confinées dans l'espace et en option sur la commande elle-même, car cela rend les boutons beaucoup plus gros sur lesquels appuyer. Qu'il s'agisse d'un style fourni avec le contrôle ou d'une énumération entre :

NumberBox.SpinButtonOrientation = SpinButtonOrientation.Horizontal  
NumberBox.SpinButtonOrientation = SpinButtonOrientation.Vertical  

Juste une petite question, suggestion possible : en théorie, dans une boîte numérique, on ne devrait pouvoir saisir que des nombres dans une boîte numérique. Serait-il difficile d'analyser des nombres écrits et de les traduire en nombres réels pour ces champs ?

Par exemple:
un + deux = 3
traduit
1 + 2 = 3

Ou
un plus deux égale trois
Se traduit par
1 + 2 = 3

C'est juste une idée.

Juste une petite question, suggestion possible : en théorie, dans une boîte numérique, on ne devrait pouvoir saisir que des nombres dans une boîte numérique. Serait-il difficile d'analyser des nombres écrits et de les traduire en nombres réels pour ces champs ?

Par exemple:
un + deux = 3
traduit
1 + 2 = 3

Ou
un plus deux égale trois
Se traduit par
1 + 2 = 3

C'est juste une idée.

Cela a du sens, pour l'anglais. Cela devient un problème lorsque vous devez traduire et analyser ces chaînes pour d'autres langues. Et qu'en est-il d'un utilisateur polonais, tapant des mots anglais ?

À l'heure actuelle, seule la forme des chiffres 0-9, les décimales, les séparateurs de nombres et les opérateurs mathématiques - ont été discutés. Mais d'autres systèmes de numérotation peuvent devoir être pris en compte.

L'ajout de traductions linguistiques sera un gros effort, et on ne sait pas quel en sera l'avantage.

Maintenant, si ce contrôle devait être manipulé par une entrée audio, donc prononcer le numéro ou l'opération - cela peut impliquer l'interprétation de la langue parlée.

NARRATEUR:
"Pixels NumberBox sans valeur"

UTILISATEUR:
"Cent vingt-huit pixels"

[ 128 _________ | pixels ]

UTILISATEUR:
"Ajouter soixante-quatre pixels"

[ 192 _________ | pixels ]

NARRATEUR:
« Cent quatre-vingt-douze pixels »

[1] Heure des questions : quelqu'un serait-il contre un système de validation qui ramène automatiquement les entrées inacceptables à la valeur précédente tout en exposant des événements qui permettraient au développeur d'annuler ce comportement et de décider à la place quoi faire/soulever des indicateurs ou des messages d'erreur ?

Si le texte saisi devient invalide, pourquoi la valeur serait-elle remplacée par quelque chose de plus ancien ? Je ne pense pas qu'essayer de maintenir un " dernier bon Value " soit quelque chose dont le contrôle doit être responsable. Laissez le contrôle gérer une seule valeur actuelle (ou état d'erreur) et laissez l'application s'occuper de tout traitement historique supplémentaire si nécessaire via l'événement ValueChanged .

Pour la version initiale, je pense que ce sera bien de ne prendre en charge qu'une seule position des boutons Haut/Bas car ils peuvent être reconfigurés si nécessaire.
Si la possibilité de déterminer la position des boutons Haut/Bas est considérée comme une nécessité, toute énumération ajoutée devrait supprimer le besoin d'avoir la propriété UpDownButtonsEnabled et une valeur d'énumération de Hidden pourrait être ajouté à la place.
Notez également que la prise en charge intégrée de la manipulation de la position des boutons Haut/Bas ajoutera de la complexité pour toute personne ayant besoin d'ajuster les modèles pour autre chose qu'une option fournie.

@shaheedmalik , et excellente idée intuitive. Avez-vous vérifié la spécification? Nous avons un événement ValueChanged qui vous permettrait d'intercepter cette entrée et d'analyser manuellement les nombres saisis en valeurs numériques - ce serait donc une expérience possible à créer, surtout si vous avez un langage spécifique en tête. Quant à la cuisson d'un analyseur de langage global dans le V1 par défaut du contrôle - @mdtauk a raison, cela ajouterait de la complexité et des frais généraux qui nécessiteraient une justification importante. L'un des avantages de l'open source de ces contrôles est qu'ils peuvent être bifurqués par la communauté. Dans ce cas, vous ou d'autres membres de la communauté pouvez créer des variantes spécifiques à la langue de ce contrôle. Je pense que ce serait la voie la plus réaliste pour démocratiser une version d'analyse linguistique de NumberBox.

@mrlacey, avez - vous eu l'occasion de l » examen @robloo analyse comparative des NumberBox de contrôle similaire utilisé tout au Windows ? Le comportement de réinitialisation de ces champs à la dernière entrée numérique valide a en fait un précédent à l'échelle du système - ce qui signifie que le contrôle lui-même ou les directives du développeur seraient pressés pour s'aligner sur ce modèle. Mon inclination serait d'aligner ce contrôle de manière cohérente sur l'expérience Windows standard et de créer une voie pour la déviation nécessaire par opposition à la normalisation d'un comportement qui s'écarte du reste de l'écosystème et à l'affirmation de directives pour créer ce comportement par défaut du système, car ce dernier créerait facile et efficace pour le cas commun. J'encourage le désaccord, alors faites-moi savoir si vous pensez que cela ajoute une complexité inutile au contrôle ou, peut-être, devrions-nous réévaluer ce précédent ?

| Titre | Photo | Commentaire |
|------|-----|-----------|
| Saisie de la taille de la police UWP OneNote | | N'importe quelle valeur peut être saisie à partir du clavier, elle est automatiquement validée et réinitialisée à la dernière valeur valide en cas de perte de focus |
| Entrée de la taille de la police Word du bureau | | Toute valeur peut être saisie au clavier, elle est automatiquement validée en cas de perte de focus et un message d'erreur apparaît si invalide. En cliquant sur [OK], la dernière valeur valide est réinitialisée. |
| Graphique 2D UWP OneNote | | Toute valeur peut être saisie à partir du clavier. Les valeurs invalides seront simplement ignorées et la dernière entrée valide utilisée dans le calcul (ne valide pas en cas de focus perdu). Appuyez sur les boutons d'incrémentation +/- pour incrémenter en utilisant la dernière entrée valide. |
| Entrée de taille de forme de mot de bureau | | N'importe quelle valeur peut être saisie à partir du clavier, elle est automatiquement validée en cas de perte de focus et réinitialisée à la dernière valeur valide en cas de perte de focus. |

@mdtauk , en notant votre commentaire sur les langues LTR et RTL et le côté du contrôle sur lequel les UpDownButtons apparaissent. Je vais l'exécuter par des experts en localisation pour m'assurer qu'il s'agit d'une considération qui doit être prise en compte.

@mrlacey, vous avez également raison de dire que le booléen serait redondant par rapport à une énumération. J'essaierai de vérifier bientôt si d'autres configurations sont nécessaires.

@adrientetar , vous êtes notre principal client pour les boutons verticaux. Avez-vous des captures d'écran ou du contexte qui pourraient m'aider à mieux comprendre vos contraintes d'espace ? @mdtauk m'a fait réfléchir avec cette réponse plus tôt :

Une première réflexion est la suivante : le nombre dans le conteneur sera-t-il un jour assez grand là où une orientation verticale serait nécessaire ? L'AutoCompleteBox ne déplace pas son bouton de recherche et les chaînes sont généralement plus longues que les nombres.

@SavoySchuler (concernant la réinitialisation à la dernière bonne valeur) Comme la spécification ajoutera plus de capacités à la NumberBox pour la gestion des erreurs et la création de rapports que les commandes de l' examen de parti de ces capacités.

Considère ceci:

1. NumberBox avec AllowsCalculations=True
2. entrez manuellement 1100 et tabulez jusqu'au contrôle suivant
3. réalise que ce n'est pas ce que je voulais entrer
4. retournez au contrôle et entrez "99 x 12"
5. tab sur le contrôle suivant et la valeur revient à afficher "1100" ('x' n'est pas le même que '*' donc il échouera dans l'étape de calcul. Ou considérez tout autre calcul invalide qui échoue si 'x' le ferait' t être affiché si pressé.)
6. Il affiche maintenant une valeur qui n'est pas le résultat du calcul, aucun message d'erreur ne s'affiche et la somme saisie est perdue, il n'y a donc aucune trace de ce qui s'est passé.

Ce que je voudrais qu'il se passe lorsque l'onglet vers le contrôle suivant à l'étape 5 est

• "99 x 12" reste la Text
• L'état d'erreur est affiché.
• ValueChanged événement déclenché et transmis (Text='99 x 12', OldValue=1100, NewValue=Double.NaN)
• L'utilisateur peut alors voir que quelque chose n'allait pas
• L'utilisateur peut corriger le problème sans avoir à ressaisir la somme entière.
• La logique Code/App est capable de faire quelque chose d'approprié si nécessaire.

Si vous souhaitez revenir automatiquement à la dernière valeur correcte connue lors de l'entrée :

• En dehors du moment où aucune valeur n'est saisie dans un champ obligatoire, l'état d'erreur serait-il indiqué ?
• La valeur de l'événement ValueChanged n'est-elle pas considérablement diminuée car il ne rapporterait jamais un état invalide ?

@SavoySchuler @mrlacey En regardant ces exemples dans d'autres applications Microsoft...

Toute fenêtre contextuelle modale doit être exclue. Au lieu de cela, cela devrait être géré par un état de validation sur le contrôle lui-même.

IMAGE

S'il existe une valeur non valide, le contenu doit peut-être rester dans cet état non valide, mais uniquement pendant que le contrôle est actif. Si le focus est perdu, la valeur du champ de texte revient, mais l'avis de validation affiche ce que l'utilisateur a entré ?

InputScope : nombre ou numéro de formule ?

Comme mentionné précédemment (dans un commentaire PR), FormulaNumber n'inclut pas « l'espace » que tous les exemples de calcul ici et dans la spécification incluent. FormulaNumber inclut également des symboles mathématiques qui ne sont pas pris en charge par ce contrôle

Je vote pour 'Nombre'

Nombre

Numéro de formule

@SavoySchuler Je veux dire que je

D'ailleurs, le contenu de TextBox ne sera pas centré verticalement, et c'est avec VerticalContentAlignment="Center".

Cela ressemble au type de barre latérale de propriétés que Paint 3D utilise (qui utilise également son propre style de contrôle avec des bordures plus fines et plus claires, et ce qui ressemble à une propriété de suffixe)

Si le glissement ne doit pas être implémenté, vous pouvez toujours faire ce que Paint 3D a fait et avoir un curseur lié à la NumberBox.

C'est également similaire à ce que fait Adobe en ayant un curseur déroulant sur leur contrôle.

@adrientetar Vous semblez

Pour le NumberBox, il pourrait y avoir un cas pour avoir des caractères visuellement centrés, mais alors ces NumberBox ne s'aligneraient pas lorsqu'ils étaient placés à côté d'un contrôle dérivé TextBox ou TextBox standard comme les ComboBox.

Lors de la création des modèles et styles par défaut, vous devez prendre en compte les différentes propriétés Windows.UI.Xaml.Documents.Typography ...

• Typographie.CaseSensitiveForms
• Typography.NumeralAlignment + Typography.NumeralStyle (Tabulaire peut être préférable à Proportionnel)

@mrlacey , vous faites un argument valide. Sur la base de la réponse de @adrientetar , qu'en est-il du scénario suivant :

Les événements de valeur/texte modifiés sont déclenchés à _chaque_ changement (pour les cas où les utilisateurs de glisser/défiler testent la plage) et, par conséquent, la validation peut se produire en continu lorsque le message d'erreur et l'indicateur sont affichés jusqu'à ce que "Entrée" soit enfoncé/le focus est perdu, dans auquel cas, le remplacement de la valeur de validation démarre et écrase la dernière bonne valeur (à moins que ce comportement ne soit désactivé par sa propriété respective).

Je discuterai avec l'équipe cet après-midi pour valider si ce tir/validation d'événement constant est une idée réaliste - sinon nous pourrions construire dans la plage délimitant d'une autre manière.

@mdtauk , mais je pense que vous avez raison avec vos affirmations sur la représentation visuelle de la validation. @LucasHaines , pouvez-vous me vérifier?

@jevansaks , êtes-vous en mesure de vous prononcer sur la considération InputScope ci-dessous ?

Comme mentionné précédemment (dans un commentaire PR), FormulaNumber n'inclut pas « l'espace » que tous les exemples de calcul ici et dans la spécification incluent. FormulaNumber inclut également des symboles mathématiques qui ne sont pas pris en charge par ce contrôle

Je vote pour 'Nombre'

Nombre

Numéro de formule

@SavoySchuler à propos de ça

Les événements de valeur/texte modifiés sont déclenchés à chaque modification (pour les cas où les utilisateurs de glisser/défilement testent la plage) et, par conséquent, la validation peut se produire en continu lorsque le message d'erreur et l'indicateur sont affichés jusqu'à ce que "Entrée" soit enfoncé/le focus est perdu, dans auquel cas, le remplacement de la valeur de validation démarre et écrase la dernière bonne valeur (à moins que ce comportement ne soit désactivé par sa propriété respective).

ValueChanged événement Value réel change, pas à chaque fois que le Text change.

à moins que ce comportement ne soit désactivé par sa propriété respective

Quelle est cette nouvelle propriété ?

Je ne sais pas comment des événements plus fréquents résolvent le problème des valeurs incorrectes et des états d'erreur perdus lors du retour à une dernière bonne valeur connue.
Je pense qu'une certaine expérimentation est nécessaire ici pour comprendre à quoi cela ressemblera réellement. (Si seulement je pouvais trouver le temps...)

Sur une note connexe.

Je suppose que l'événement TextChanged existant hérité de TextBox ne sera pas modifié pour le consommateur. Mais qu'en est-il de l'événement TextChanging ? Est-ce que c'est là que le nouveau traitement spécifique au contrôle est effectué ? Le consommateur du contrôle pourra-t-il également gérer cet événement ?

D'accord - vaut la peine d'être exploré mais mieux évitable. J'ai révisé la section sur la validation et ajouté une propriété IsInvalidInputOverwrite qui est désactivée par défaut. Que pense tout le monde des éléments suivants :

• Une entrée qui n'est pas numérique ou dépasse les valeurs min/max déclenchera un avertissement de validation d'entrée .
• Le développeur peut intercepter les événements ValueChanged ou TextChanged (qui exposent la propriété modifiée et celle à mettre à jour) et manipuler manuellement une entrée non valide avant qu'un avertissement de validation d'entrée ne s'affiche.
• L'activation de la propriété IsInvalidInputOverwrite ramènera l'entrée non valide au dernier état valide sans afficher l' avertissement de validation d'entrée . Par exemple, si IsInvalidInputOverwrite est activé, StepSize=0.2, MaxValue=3.0 et la valeur 2.9 est incrémentée, 3.1 sera enregistré comme invalide et sera écrasé à 2.9.

Une grande partie de cela pourrait être résumée par la question de savoir si la validation doit avoir lieu tout au long de la saisie ou après. Je me penche après pour des raisons de performance et parce que l'expérience de recevoir des validations au fur et à mesure que vous tapez peut être choquante et peu accessible - ce qui fait de ce qui précède ma mise en œuvre actuellement préférée.

FWIW, Adobe Photoshop et Illustrator reviennent à la valeur précédente lorsque vous essayez d'entrer une valeur non valide. Cela a le comportement de calcul, mais le suffixe de l'unité de mesure fait partie du texte, ce qui en soi peut poser des problèmes de validation :)

Je voulais lancer une idée sur laquelle je me suis disputé - je me souviens de nombreuses expériences passées où j'ai eu une boîte de numéro de tri avec une fonctionnalité d'incrémentation/décrémentation, descendre en dessous de la valeur minimale me ramènerait à la valeur supérieure, et vice versa. Je voulais voir si quelque chose comme une propriété _ValuesWrap_ a du sens ici.

Cela n'a évidemment pas de sens dans tous les cas, mais dans les cas de plage numérique limitée, il m'a été intuitif dans le passé de supposer que les nombres s'enroulent dans des cas tels que l'entrée Age ou DateOfBirth ou pour d'autres cas de petite plage. D'un autre côté, cela se produit parfois uniquement parce que dans ces cas, une boîte de sélection à choix multiples est utilisée, et celles-ci encapsulent généralement les valeurs au lieu de s'arrêter. Je voulais juste vérifier s'il y a une justification ou un besoin pour cela - cela pourrait bien sûr être implémenté du côté du développeur également via n'importe quel événement onValueChanged avec un travail supplémentaire.

cc @SavoySchuler

Super idée, @KevinTXY. Si l'un de nos développeurs ici a besoin de quelque chose comme ça, nous pouvons envisager de l'ajouter !

Heure des questions : quelqu'un a-t-il des scénarios d'application réels qui justifient la prise en charge de l'hexadécimal ou du binaire ? Envelopper les valeurs max/min ?

Je voulais voir si quelque chose comme une propriété ValuesWrap a du sens ici.

ouais, si vous avez comme une propriété d'angle, vous voulez aller 359 → 0, essentiellement mod 360. Ce qui est amusant, c'est que je devais toujours sous-classer le contrôle (était dans Qt) car MaxValue ne pouvait être inclusif, donc je pouvais spécifier 359 ou 360, mais je voulais vraiment pouvoir écrire 359,99 mais pas 360 (c'est-à-dire que je voulais <, pas ≤).

La QSpinBox a une propriété d'emballage à cette fin https://doc.qt.io/qt-5/qabstractspinbox.html#wrapping -prop

@SavoySchuler En ce qui concerne l'hexadécimal, je soupçonne qu'un éditeur hexadécimal pourrait le souhaiter, mais cela semble être un cas d'utilisation vraiment spécialisé, vous n'avez pas à prendre en charge tout ce qui est possible, assurez-vous simplement que le contrôle est facile à sous-classer. Dans Qt, le contrôle a une méthode qui convertit la chaîne de texte en valeur numérique (soit int soit double) qui peut être remplacée.

Par exemple, si IsInvalidInputOverwrite est activé, StepSize=0.2, MaxValue=3.0 et la valeur 2.9 est incrémentée, 3.1 sera enregistré comme invalide et sera écrasé à 2.9.

Vous pourriez probablement vous limiter à MaxValue dans ce cas.

@SavoySchler @xyzzer @mrlacey J'ai vu sur Twitter qu'il y a quelque chose à venir dans 20H1 qui fournit une saisie de texte prédictive.

Cela peut interférer avec la fonctionnalité d'achèvement de l'aperçu dont nous avons parlé et peut nécessiter une suppression dans le contrôle NumberBox. Venant aux contrôles Win32 et XAML, il semble...

https://twitter.com/thebookisclosed/status/1137012461616488448?s=20

Je suppose que la gestion hexadécimale ou binaire sont des scénarios encore plus spécialisés que la gestion de "chaînes qui ressemblent à des nombres" telles que des numéros de téléphone et des codes postaux. (et apportent leur propre complexité)
En tant que tels, je pense qu'ils devraient être hors de portée du contrôle NumberBox.

En parlant de la fonction de prévisualisation des calculs, au cas où elle serait manquée, je proposerais de donner à un utilisateur le choix de l'activer/de la désactiver. Alors peut-être en ajoutant une propriété comme

public bool ShowPreviewResult { get; set; }

Pourquoi afficher le résultat de l'aperçu ? Pas comme si l'utilisateur changerait sa formule en fonction du résultat, s'il connaît le résultat qu'il veut, il le tapera tout de suite

Pourquoi afficher le résultat de l'aperçu ? 🤔 Pas comme l'utilisateur le ferait en fonction du résultat, s'il sait ce qu'il veut, il le tape tout de suite

L'une des caractéristiques du contrôle est de pouvoir entrer dans un calcul, comme 32 * 4 qui se résoudrait à 128 - la fonction de prévisualisation montrerait ce que serait ce résultat lorsque le contrôle perd la mise au point ou que la touche Entrée est enfoncée.

@adrientetar L'aperçu est une fonctionnalité provisoire à partir de maintenant. Je crois que la valeur serait en partie dans la validation orientée utilisateur avant que la validation du contrôle ne démarre, par exemple, elle ne montre que si ce qui est entré peut être calculé/est dans les limites ; par exemple, vérifier les attentes ("Ai-je atteint les temps au lieu de plus ?"). L'intérêt et le retour sur investissement ici ne sont pas encore clairs.

Merci encore pour vos retours, tout le monde ! Il semble qu'il n'y ait pas de besoin pressant ou d'intérêt justifié pour le support binaire ou hexadécimal pour le moment. Il peut également être sous-classé, proposé en tant que nouveau contrôle ou proposé pour la V2 selon les besoins.

@SavoySchuler en ce qui concerne "Quelqu'un a-t-il des scénarios d'application réels qui justifient la prise en charge de l'hexadécimal ou du binaire?", un exemple est le propre contrôle ColorPicker de WinUI. Il comprend une zone de saisie hexadécimale. Il comprend également un certain nombre d'autres zones de texte d'entrée de nombre. Il peut être intéressant d'étudier la possibilité de mettre à jour ColorPicker pour utiliser le nouveau contrôle NumberBox comme moyen de valider le nouveau contrôle. Si NumberBox peut simplifier l'implémentation actuelle de ColorPicker, ce serait une victoire.

Au cas où le style de bordure plus mince pour les zones de texte ne dépasserait pas

@kmahone - d'accord. Comme vous l'avez mentionné au refroidisseur d'eau ce matin, pouvoir supprimer beaucoup de code derrière ColorPicker en remplaçant ses instances de TextBox + logique de validation locale par NumberBox pourrait être une victoire en soi.

@mdtauk - vous ai-je dit trop de fois que vos maquettes étaient incroyables ? Je vais les mettre dans les spécifications sous peu !

@SavoySchuler Si l'équipe de conception de Windows décidait de se ranger du côté de l'équipe Fabric Web et de passer de bordures épaisses de 2 epx à des bordures de 1 epx - je pense que cela fonctionnerait mieux avec la NumberBox - mais étant pratique, l'équipe de conception de Windows peut creuser leurs talons et garder les bordures plus épaisses.

Bien sûr, @mdtauk ! J'espère verrouiller les exigences fonctionnelles pour @KevinTXY ici dans un avenir proche et je passerai alors à cette conversation de convergence de conception avec @chigy (qui a été occupé à faire un travail incroyable sur #524) alors !

Merci pour toutes les discussions, je suis ravi de travailler sur cette fonctionnalité cet été en tant que stagiaire !

Si cela concerne quelqu'un, j'ai commencé un prototype C# du contrôle dans le référentiel suivant.
https://github.com/KevinTXY/NumberBox

C'est essentiellement la première fois que j'apprends C#/UWP donc ça viendra lentement et si quelqu'un y regarde, je suis heureux d'avoir des retours sur ce qui pourrait être amélioré !

Les fonctionnalités suivantes sont grossièrement implémentées :

• Validation d'entrée numérique (ne suit pas encore les spécifications de la proposition de validation , attendra le code pour cela)
• Stockage de valeur/liaison
• Zéro coupe
• Prise en charge complète de la calculatrice/saisie de formules

Travaille actuellement sur les boutons rotatifs et teste des trucs d'application ainsi que la validation Min/Max.

À votre santé!

Mise à jour de la chronologie !

J'ai intégré plusieurs mises à jour, suggestions et commentaires dans la spécification que je vais valider avec l'équipe WinUI aujourd'hui (jeudi). J'espère ainsi finaliser plus ou moins l'API et les composants comportementaux pour la V1.

Maintenant, je vais passer aux entrées et à l'accessibilité, aux données et à l'intelligence et aux composants visuels.

La dernière étape consistera à ranger la documentation et à former des directives.

Je pense que l'option disjointe et contiguë est très niche sans cas d'utilisation que l'interface utilisateur des applications/shell de première partie de Microsoft a dû faire dans WPF ou Win32.

Si vous souhaitez l'inclure, je préférerais que ce soit un style inclus que vous pouvez appliquer au contrôle plutôt qu'une option. Comment les contrôles NumberBox re-modèles traiteraient-ils cette propriété, dans leurs nouveaux modèles ?

Si le consensus est que ce mode doit être inclus, puis-je suggérer qu'il devienne une valeur enum dans le cadre de SpinButtonPlacementMode . Je ne sais pas comment cette option s'appellerait. _Straddled_ n'est peut-être pas assez professionnel lol, et je ne suis pas sûr que _Bookended_ soit mieux.

Je regardais juste la dernière version Canary d'Edge et j'ai vu la conception d'un <input type="number"/> qui est le plus proche d'un contrôle NumberBox.

J'ai juste pensé que je partagerais cette image de celui-ci.

@mdtauk - d'accord, SpinButtonPlacementMode serait le bon endroit pour ajouter d'autres options de placement SpinButton.

Au sujet des noms, @Felix-Dev a fait surface à juste titre sur la spécification que SpinButton n'est peut-être pas le nom le plus intuitif ou le plus connu. SpinBox et UpDownButtons ont également la priorité dans l'écosystème Windows. Je vais creuser cela plus sous peu, mais s'il vous plaît laissez-moi savoir si quelqu'un a des arguments contre l'une de ces options.

@mdtauk - Merci de partager ça ! Je dirige également Canary, donc je vais jeter un œil et voir s'il y a quelque chose que nous pouvons apprendre ou s'il y a de la place pour suggérer d'aligner les développements !

@SavoySchuler J'utilise le drapeau Fluent Controls Enabled (y compris les contrôles expérimentaux)

Je pense que l'implémentation de WinUI serait une conception plus réfléchie vers laquelle Fabric Web et Edge devraient se tourner, mais l'alignement est une bonne chose à faire.

Numéro de type d'entrée w3schools

De plus, ce curseur est proche, mais pas tout à fait identique à ce que WinUI prévoit de faire (pouce en cercle souligné, par rapport à un pouce en cercle rempli)

Je ne sais toujours pas comment je peux définir les fonctionnalités de localisation. Aux États-Unis, le point est utilisé pour un séparateur décimal. Aux Pays-Bas (où j'habite), nous utilisons la virgule. Le séparateur de groupement aux États-Unis est la virgule, mais aux Pays-Bas, c'est le point.

Exemple:

Dois-je utiliser la propriété Language de l'élément Framework pour spécifier le séparateur de chiffres et de regroupement ?

<StackPanel Spacing="12" Padding="12" Width="200">
    <NumberBox Header="Dollar (US)"
               Value="1234.56"
               FractionDigits="2"
               Language="en-US" />
    <NumberBox Header="Euro (Netherlands)"
               Value="2345.67"
               FractionDigits="2"
               Language="nl-NL"/>
</StackPanel>

Je regardais juste la dernière version Canary d'Edge et j'ai vu la conception d'un <input type="number"/> qui est le plus proche d'un contrôle NumberBox.

J'ai juste pensé que je partagerais cette image de celui-ci.

@mdtauk , @SavoySchuler ,
Je ne sais pas d'où vient ce contrôle. D'après mon contact dans l'équipe Edge, voici les contrôles qu'ils utiliseraient.

Curseur : https://explore.fastdna.net/components/slider/
Boîte numérique : https://explore.fastdna.net/components/number-field/

Je ne sais pas s'ils mettront à jour le visuel et la sortie finale pourrait ne pas ressembler exactement à ceci (je suppose que oui, mais c'est ma supposition folle).

@chigy Cette image

Je suppose que cela explique à quoi sert ce projet fastdna, que j'ai évoqué dans un numéro précédent. ??

Dois-je utiliser la propriété Language de l'élément Framework pour spécifier le séparateur de chiffres et de regroupement ?

Ces paramètres proviennent généralement de la "région", donc je pense que nous passerions simplement

Je ne vois pas de moyen de personnaliser les caractères de séparation dans l'API DecimalFormatter, ils doivent donc être extraits des paramètres de langue. ??

@jevansaks , merci pour la perspicacité ! Je vais taguer @sonnemaf pour m'assurer qu'il voit la réponse.

@jevansaks pouvez-vous écrire un exemple xaml sur le DecimalFormatter pour le NumberBox ? Je veux le définir en XAML et non à partir de codebehind. Avoir des propriétés DecimalSymbol et GroupingSymbol fonctionnerait également pour moi. Cela pourrait être trop facile cependant.

<StackPanel Spacing="12" Padding="12" Width="200">
    <NumberBox Header="Dollar (US)"
               Value="1234.56"
               FractionDigits="2"
               DecimalSymbol="."
               GroupingSymbol="," />
    <NumberBox Header="Euro (Netherlands)"
               Value="2345.67"
               FractionDigits="2"
               DecimalSymbol=","
               GroupingSymbol="." />
</StackPanel>

* Does anyone have any real app scenarios that justify needing support for hexadecimal or binary?

Désolé d'intervenir, je viens de découvrir ce sujet, mais OUI OUI OUI. Les deux manquent souvent dans les commandes numériques et moi-même et de nombreux autres développeurs sur github devons avoir des solutions de contournement pour cela. Surtout avec l'exemple de la calculatrice, il ne doit pas seulement formater un nombre en hexadécimal, mais prend entièrement en charge l'entrée.

En ce moment, je voudrais vous suggérer de personnaliser le préfixe des nombres hexadécimaux. À un moment donné, il vaut mieux ne pas avoir de préfixe du tout et sur d'autres points ce n'est pas toujours 0x

pouvez-vous écrire un exemple xaml sur le DecimalFormatter pour le NumberBox ? Je veux le définir en XAML et non à partir de codebehind. Avoir des propriétés DecimalSymbol et GroupingSymbol fonctionnerait également pour moi. Cela pourrait être trop facile cependant.

@sonnemaf tout ce avec

Respecter la région de l'utilisateur pour ces paramètres semble cependant correct - avez-vous un scénario où vous devez les remplacer ?

@sonnemaf

Quelqu'un a-t-il des scénarios d'application réels qui justifient la prise en charge de l'hexadécimal ou du binaire ?

Désolé d'avoir remarqué cela et de répondre un peu tard. Je crois que le support hexadécimal/binaire serait très utile. Je suis fortement impliqué dans le projet .NET IoT et nous travaillons principalement dans le monde hexadécimal/binaire car nous manipulons des bits/octets qui lisent/écrivent dans des registres et des broches pour contrôler les choses.

Soutenir hexadécimal/binaire serait très apprécié. Merci

Je n'ai pas besoin d'hexa ou de binaire. Ce serait un "agréable à avoir", surtout binaire.

Mise à jour des développeurs

Salut à tous! Nous nous contentons de la spécification NumberBox, et je veux juste attirer l'attention sur le fait que je travaille activement sur le contrôle , idéalement un premier PR avec les fonctionnalités les plus importantes sera fait très très bientôt, peut-être ce soir.

Quelques notes:

• Nous avons choisi de ne pas sous-classer TextBox, en particulier en raison de certaines complications de conception avec InputValidation, NumberBox sera son propre contrôle contenant un TextBox.
  
  
  
  • Cela signifie que toutes les propriétés TextBox ne seront pas exposées. Je suis curieux de savoir si l'un de ces éléments est important à apporter à NumberBox - je pourrais voir le désir de _Header, PlaceHolderText_, et peut-être aussi _Text_ ? Je voulais vraiment ouvrir un peu celui-ci car c'est un changement très facile à faire de mon côté.
  
  
• J'ai apporté de très petites modifications à la spécification, ce ne sont pour l'instant que des corrections de formulation, mais il reste des questions ouvertes telles que la prévisualisation de la valeur, et au fur et à mesure que j'écris le contrôle, je génère certaines de mes propres questions de conception. C'est encore le bon moment pour ajouter de l'entrée 😄

@KevinTXY Il y avait une suggestion à dériver de la base Slider plutôt que de TextBox - est-ce ce qui a été choisi ?

• PlaceHolderText
• Entête
• Texte
• Icône de validation
• Message de validation
• SélectionAu premier plan
• SélectionContexte
• États/ressources ciblés, etc.

Ce sont certaines des choses TextBox que je pense sont nécessaires. Pas sûr du bouton "texte clair", qui a plus de sens avec de longues chaînes de texte.

La prévisualisation de la valeur Je pensais qu'il s'agissait d'une fonctionnalité V2, mais cela a-t-il changé ? Le contrôle Slider a une infobulle affichant la valeur, au fur et à mesure que le pouce glisse. J'ai suggéré cela comme un moyen de le gérer, ainsi que d'utiliser le message de validation pour gérer cela ou de l'afficher en ligne.

Inline a un problème avec le fait que Windows Insider expérimente la saisie prédictive de texte, apparaissant soit sous forme d'info-bulle, soit dans les champs de texte. Quelle que soit la méthode d'aperçu choisie, elle ne doit pas entrer en conflit avec celles-ci ou avec cette fonction prédictive désactivée pour ce contrôle.

@KevinTXY Il y avait une suggestion à dériver de la base Slider plutôt que de TextBox - est-ce ce qui a été choisi ?

NumberBox est actuellement son propre contrôle (étend Windows.UI.Xaml.Controls.Control) qui contient un TextBox dans son balisage plutôt que d'étendre TextBox. Le curseur semble intéressant, mais je pense que cela rendrait l'implémentation un peu compliquée, il y a aussi beaucoup de propriétés dans ces contrôles qui ne nous semblent pas appartenir à NumberBox. Je ne suis pas un PM mais d'après mon expérience de développement, je pense que c'est une bonne voie pour simplifier le développement et pour l'extensibilité future.

Ce sont certaines des choses TextBox que je pense sont nécessaires. Pas sûr du bouton "texte clair", qui a plus de sens avec de longues chaînes de texte.

C'est génial - exactement ce que je cherchais! Je suis d'accord qu'il y a de la valeur dans tout cela. Le bouton Effacer tout est actuellement là car il s'agit d'une fonctionnalité par défaut de la zone de texte - je suppose qu'il a de la valeur pour les entrées volumineuses ou les utilisateurs d'écrans tactiles, bien que je n'aie pas encore vraiment réfléchi à sa désactivation. Je vais certainement au moins essayer d'obtenir les trois que j'ai mentionnés (En-tête, PlaceholderText, Text) dans l'aperçu.

Quant à la prévisualisation de la valeur, rien n'est finalisé là-bas et ce n'est que dans la spécification en tant que question ouverte. Je suppose que la solution temporaire la plus simple serait d'exposer simplement la valeur d'aperçu pour que les développeurs l'affichent comme ils le souhaitent - cela pourrait être facilement dans la portée de la version d'aperçu, mais je laisserai à @SavoySchuler & Co. le

@KevinTXY Idéalement, il y aurait une collaboration avec l'équipe Calculator, pour créer un moteur de calcul de base qui pourrait être intégré - ainsi que pour une utilisation future avec l'idée CalculatorPicker qui a été discutée parallèlement à ce contrôle. (Un contrôle avec un bouton de calculatrice, qui affiche un menu volant avec une calculatrice standard)

En fait, la collaboration avec les mainteneurs de Calculator semble être une excellente idée. Vous pouvez exposer un service d'application de Calculator qui effectuerait les calculs mathématiques, de sorte que vous n'auriez même pas besoin de charger le binaire WinUI - parlez simplement au service d'application si l'application est installée et sinon - échouez simplement en silence.

Quant à dériver de Slider - j'ai en fait dit RangeBase et je suis toujours assez confiant que c'est la bonne chose à faire car le contrôle fournit essentiellement presque toutes les propriétés et fonctionnalités d'accessibilité dont vous aurez besoin et en dérivant fournira une surface API cohérente parmi votre contrôle et le curseur, ce qui en fait des remplacements faciles.

Ah oui, RangeBase, c'était ça.

La calculatrice a récemment travaillé pour prendre en charge un mode CompactOverlay toujours au top - il est donc plus possible d'intégrer un clavier plus petit dans un flyout de taille similaire au CalendarFlyout. (Si le contrôle CalculatorBox est approuvé pour inclusion.

Je ne sais pas s'il s'agit d'un service d'application (qui lierait les mises à jour WinUI semi-dépendantes des mises à jour du magasin Calculator - ou s'il s'agit d'un binaire de service qui peut être ajouté à WinUI et dérivé du moteur de Calculator.

Mise à jour : Un Code PR existe désormais 🎆 !

Je suis en train de suivre certains problèmes là-bas, bien que la plupart ne soient pas liés à la conception.

Merci @xyzzer et @mdtauk ! Nous avons vérifié RangeBase et il semble transporter autant de bagages que la sous-classe TextBox. À partir de maintenant, nous continuerons à contenir une zone de texte dans le contrôle et à ajouter uniquement les propriétés et les fonctionnalités d'accessibilité nécessaires. C'était toujours une considération valable et a contribué à éclairer notre conversation sur l'accessibilité qui se déroule actuellement.

@mdtauk , merci pour la liste de départ ! @KevinTXY a commencé à exposer les API que vous avez répertoriées et

Aperçu et calculatrice contextuelle , comme @KevinTXY a

Appellation

Il y a eu tellement de commentaires que la spécification m'a échappé, donc je commence juste à regarder une fois que les choses se sont réglées. Tout d'abord, j'ai remarqué que certains noms ne suivent pas vraiment la convention C# - oui, je sais que ces contrôles sont écrits en C++, mais je pense toujours que cela est incompatible avec les autres noms de la plate-forme.

| Type | Nom actuel | Nom proposé |
|-------|----------------|-------------------|
| Booléen | AccepteCalcul | EstCalculAccepté |
| Booléen | HyperDragEnabled | IsHyperDragEnabled |
| Booléen | HyperScrollEnabled | IsHyperScrollEnabled |

Fréquence de pas

Aussi, qu'est-ce que StepFrequency ? Ce n'est pas défini dans la spécification et je n'ai aucune expérience avec "XAML Toolkit's NumericUpDown". Selon ce que cela fait, l'ajout du mot Fréquence peut ne pas avoir de sens. C'est probablement juste une « étape » ? Dans le contrôle Slider, TickFrequency est logique car les ticks sont affichés sur un module de la plage max-min globale. Cependant, dans ce contrôle, je pense que ce n'est que la taille minimale d'incrément/pas. Fondamentalement, l'utilisateur pourra-t-il saisir une valeur en dehors de l'étape ?

Par exemple MinValue = 0, MaxValue = 6, StepFrequency = 2. L'utilisation de la valeur de la flèche vers le haut sera {2, 4, 6} assez juste. L'utilisateur peut-il cependant saisir 0,5 comme valeur valide ? Ou cela sera-t-il arrondi à 0 ou 2 selon le RoundingMode ?

Valeur Min/Max

Pour les deux propriétés ci-dessous, je pense que celles-ci devraient simplement être Minimum et Maximum comme dans les autres contrôles (Slider, RangeBase). Les API doivent être cohérentes.
Double MinValue ;
Double MaxValue ;

Boutons de répétition haut-bas

Une autre fonctionnalité qui n'a pas été discutée pour autant que je sache est de savoir s'il faut réellement répéter les boutons haut/bas (je pense qu'ils devraient l'être). S'il s'agit de boutons de répétition, les propriétés Delay/Interval doivent être ajoutées comme le contrôle Slider : Slider.Interval Slider.Delay

Chiffres

Pouvez-vous ajouter une description de ce que représentent IntegerDigits et FractionDigits ? Je suppose qu'ils limitent le nombre de chiffres pour chaque partie du numéro. IntegerDigits = 2 signifie que la valeur maximale peut être 99. FractionDigits = 3 signifie que MaxValue peut être 0,999. De plus, comment les chiffres significatifs remplacent-ils ces deux propriétés ?

Zéro négatif ?

Pourquoi cette propriété est-elle nécessaire ? Est-ce un problème de localisation en soi ? Je n'ai jamais vu "-0.0" ou "-0". C'est toujours juste "0".
Booléen IsZeroSigned ;

Localisation

Je suis catégorique, j'ai besoin de ce contrôle pour prendre en charge le remplacement de la localisation de l'interface utilisateur et du format de nombre. J'ai plusieurs utilisations (applications financières) où j'ai besoin de montants locaux et étrangers qui doivent être affichés différemment. Je ne vois cela nulle part dans les spécifications.

La conversion de double en texte doit être personnalisable via ValueConverter, dans l'esprit de Slider.ThumbToolTipValueConverter. De cette façon, la partie la plus complexe pourrait être personnalisée pour tous les besoins, comme dans certains exemples concrets ci-dessous :

Notez que le séparateur décimal pour les nombres et l'argent peut être différent, ainsi que la désignation des sommes négatives, donc probablement l'approche la plus sûre pour NumericBox sans ValueConverter est de fonctionner en mode entier. La calculatrice pourrait également être implémentée en tant que ValueConverter, il n'est pas nécessaire de surcharger le contrôle avec ce travail.

@eugenegff Vous avez une très bonne idée de rendre générique la conversion de nombres en chaînes. Cela me permettrait de gérer la localisation, mais permettrait également aux développeurs de faire tout ce qu'ils voudraient, comme ajouter des unités.

La seule complexité que je vois est de conserver une Culture/NumberFormatInfo liée au contrôle. Je suppose que cela pourrait être un paramètre de convertisseur dans XAML allant vers un IValueConverter personnalisé, mais il devrait probablement y avoir un moyen plus propre de gérer cela dans le contrôle lui-même.

Pourquoi cette propriété est-elle nécessaire ? Est-ce un problème de localisation en soi ? Je n'ai jamais vu "-0.0" ou "-0". C'est toujours juste "0".

C'est une propriété de la classe DecimalFormatter dans Windows. C'est bizarre ? Probablement. Il y a certaines propriétés comme IsGrouped et les propriétés de localisation que nous avons laissées de côté, donc peut-être que celle-ci n'est pas nécessaire non plus. En même temps, il est également déjà implémenté, donc le supprimer n'aurait d'autre but que de dégonfler 3 lignes de code. Il est intéressant de noter qu'il existe des usages et des prérequis IEEE pour avoir des zéros signés .

Je suis catégorique, j'ai besoin de ce contrôle pour prendre en charge le remplacement de la localisation de l'interface utilisateur et du format de nombre. J'ai plusieurs utilisations (applications financières) où j'ai besoin de montants locaux et étrangers qui doivent être affichés différemment. Je ne vois cela nulle part dans les spécifications.

@SavoySchuler peut-être

Ok, je pense que je comprends le problème fondamental ici. Dans le monde C++, vous avez accès à DecimalFormatter mais dans le monde C# (si je consomme WinUI), j'utiliserais normalement un IFormatProvider (NumberFormatInfo d'une culture spécifiée). NumberFormatInfo a déjà la plupart des propriétés (manquant IsZeroSigned par coïncidence), donc je pensais simplement permettre aux développeurs de spécifier cela ou un IFormatProvider. Eh bien, il y a le problème, C++ ne peut pas utiliser un IFormatProvider car il vient du monde .net.

Alors, comment ce contrôle prend-il pleinement en charge la localisation en C# et C++ étant donné qu'ils ont deux manières différentes de le faire ? Eh bien, à moins que Microsoft n'ait une solution intelligente, je ne peux penser qu'à deux possibilités :

1. Ajoutez entièrement toutes les propriétés pour la mise en forme des nombres (en réimplémentant efficacement NumberFormatInfo et DecimalFormatter). L'ajout de IsZeroSigned, IntegerDigits, FractionalDigits, etc. ne le couvrira pas. NumberNegativePattern, NumberGroupSeparator, NumberGroupSizes, etc. sont également tous requis.
2. Faites comme @eugenegff suggéré et autorisez les développeurs à remplacer le formatage par une sorte de rappel. Honnêtement, cela semble être l'approche la plus simple.

Je suis un peu préoccupé par la façon dont la localisation se présente dans ce contrôle. J'évoque la localisation depuis le début (3ème commentaire sur ce sujet !). Il doit exister un moyen de personnaliser entièrement le format des nombres lorsque le contrôle est converti en chaîne. Sans cela, ce contrôle sera assez limité dans le monde réel.

Alors, comment ce contrôle prend-il pleinement en charge la localisation en C# et C++ étant donné qu'ils ont deux manières différentes de le faire ?

Nous vous entendons! C'est quelque chose que nous avons étudié hors ligne, mais fondamentalement, .NET effectue sa propre localisation séparément de la plate-forme. Je pense qu'un rappel pour passer outre est une excellente issue de secours, mais j'espère que votre option 1 est la voie que nous pouvons emprunter. Pour le moment, les API WinRT pour le formatage et l'analyse ne disposent pas de tous les boutons de personnalisation dont nous avons besoin. Nous enquêtons toujours.

Je n'ai pas vérifié si cela a déjà été discuté, mais je voulais demander rapidement si quelqu'un voit un grand besoin ou, plus important encore, un précédent pour la prise en charge des fonctions pour les calculs, c'est-à-dire l'un des éléments ci-dessous ou plus :
cos(), sin(), tan(), asin(), acos(), atan(), sqrt(), log(), abs(), ceil(), floor(), degree equivalents of trig functions, hyperbolic functions, etc

J'assemble des analyseurs mathématiques pour répondre à nos besoins et à nos fonctions, ce qui complique le processus de conversion en RPN (cela dit, j'ai déjà une version qui les prend en charge avec quelques bugs), donc je suis intéressé de voir si l'un d'entre eux vaut la peine le problème ou si cela ressemble à des ballonnements. Personnellement, je ne pense pas que cela corresponde trop bien, mais s'il y a beaucoup de précédents, ce n'est pas trop gênant.

Je pense que ceux-ci ne seraient pas très détectables dans la plupart des cas et si quelqu'un a besoin de support pour des fonctions plus compliquées - il est préférable de travailler sur l'ouverture de l'analyse à un événement de rappel permettant aux utilisateurs d'implémenter leur propre logique d'analyse ou de prétraitement.

Ce qui serait plus utile, c'est de permettre de commencer à taper du texte avec un opérateur, donc si vous cliquez sur le texte - il sélectionnera tout par défaut et vous pourriez soit taper une nouvelle valeur sans avoir à appuyer d'abord sur supprimer pour supprimer la précédente ou tapez simplement quelque chose comme "*1.2" ou "x1.2" [Enter] et multipliez la valeur actuelle par 1,2 même si le texte entré ne contient plus la valeur entrée. La même chose fonctionnerait pour "+2", "-5", "/3", "%120", etc.

Il est utilisé dans certaines applications professionnelles.

Nous (BeLight Software, projet Live Home 3D) avons besoin d'un ValueConverter enfichable pour la conversion de texte de valeur <=>, sinon NumberBox ne nous conviendrait pas.

Je pense que l'utilisation de ces fonctions serait assez rare, j'ai une entrée d'angle dans mon application mais c'est juste une valeur en degré. L'utilisation la plus importante pour moi est de pouvoir ajouter une valeur à l'existant ou diviser l'existant par un nombre, juste pour gagner du temps et éviter de faire ce calcul mentalement. (Au fait, je pense que c'est ce que les applications Adobe ont, les 4 opérateurs arithmétiques : https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/suggestions/12992463-support-math-operators-in-number -des champs)

De plus, des fonctions comme cos(), vous ne le voulez probablement pas là où cela n'a pas de sens, à moins que vous ne créiez une sorte d'application Excel.

L'utilisation la plus importante pour moi est de pouvoir ajouter une valeur à l'existant ou diviser l'existant par un nombre, juste pour gagner du temps et éviter de faire ce calcul mentalement

D'accord, super! Cela ressemble à ce que

Nous (BeLight Software, projet Live Home 3D) avons besoin d'un ValueConverter enfichable pour la conversion de texte de valeur <=>, sinon NumberBox ne nous conviendrait pas.

J'ai jeté un coup d'œil à l'exemple de Slider que vous avez donné et cela semble très raisonnable - je pouvais voir la valeur d'un IValueConverter pour NumBox. Je l'examinerai bientôt et nous essaierons de décider si cela correspond aux spécifications de manière appropriée. Aucune promesse sur quoi que ce soit pour le moment!

@KevinTXY Je soupçonne que l'ajout des fonctions que vous mentionnez ci -
Cela casserait également la première ligne de la description au début de la spécification "La zone numérique est un contrôle de texte uniquement numérique ...".

Je suis surpris qu'il y ait encore des questions sur la localisation. Comme le contrôle héritera (doit ?) de FrameworkElement il aura accès à la propriété Language et ainsi, comme tous les autres FrameworkElement, prendra en charge la définition directe des paramètres régionaux et ne dépendra pas des paramètres de l'interface utilisateur des paramètres régionaux du système.
Cela signifie que des éléments tels que les caractères décimaux et de regroupement peuvent être définis par instance.

Je suis surpris qu'il y ait encore des questions sur la localisation.

Le problème est que la langue n'est pas la chose qui contrôle le formatage, ce sont les paramètres de région/culture. La localisation consiste à mettre à jour les chaînes de l'interface utilisateur pour qu'elles s'affichent dans la langue correcte, tandis que le formatage des nombres/devises/dateheure est contrôlé par région. Plus d'informations ici : https://docs.microsoft.com/en-us/globalization/locale/locale-and-culture. Et pour compliquer les choses, Windows vous permet de personnaliser vos paramètres régionaux dans l'interface utilisateur en remplaçant les valeurs par défaut - vous pouvez donc dire que vous voulez que votre séparateur décimal soit n'importe quel caractère aléatoire au lieu de la valeur par défaut. Et en plus de cela, .NET permet aux applications de le personnaliser également, de sorte que les développeurs s'attendent à ce niveau de personnalisation ici.

Le problème est que la langue n'est pas la chose qui contrôle le formatage, ce sont les paramètres de région/culture. La localisation consiste à mettre à jour les chaînes de l'interface utilisateur pour qu'elles s'affichent dans la langue correcte, tandis que le formatage des nombres/devises/dateheure est contrôlé par région. Plus d'informations ici : https://docs.microsoft.com/en-us/globalization/locale/locale-and-culture. Et pour compliquer les choses, Windows vous permet de personnaliser vos paramètres régionaux dans l'interface utilisateur en remplaçant les valeurs par défaut - vous pouvez donc dire que vous voulez que votre séparateur décimal soit n'importe quel caractère aléatoire au lieu de la valeur par défaut. Et en plus de cela, .NET permet aux applications de le personnaliser également, de sorte que les développeurs s'attendent à ce niveau de personnalisation ici.

Language prend une valeur qui est traduite en CultureInfo --notez qu'une culture est appelée un paramètre régional dans le développement de code non managé. Cela contient une propriété NumberFormat qui est un type NumberFormatInfo qui contient des propriétés pour les décimales, le regroupement, les signes négatifs, etc.

D'après ce que je comprends, si vous souhaitez forcer un formatage spécifique ou d'autres spécificités de localisation sur un contrôle, plutôt que de vous fier aux paramètres système, la façon de le faire est de spécifier le Language .

La description de la propriété indique clairement qu'elle "définit les informations de langue de localisation/globalisation qui s'appliquent à un FrameworkElement"

Ou peut-être que j'ai mal compris les documents auxquels je fais référence, mais ils semblent tous sauvegarder ce qui est couvert dans la page à laquelle vous vous êtes lié.
C'est peut-être un problème de terminologie avec C++ et C# utilisant des termes différents.
Ce que je sais, c'est que la définition de la langue dans XAML est la façon dont je forcerais une culture/locale dans n'importe quelle autre application et avec n'importe quel autre contrôle.

Les questions que j'ai vues sur la localisation concernaient le forçage de formats de nombres spécifiques ou de séparateurs de groupes et de décimales. Ou est-ce que le vrai problème est de savoir comment les contrôler sans affecter la localisation des propriétés basées sur le texte (En-tête, PlaceholderText, etc.) du contrôle ?

Language prend une valeur qui est traduite en CultureInfo

Pas en natif/WinRT, nous obtenons juste une chaîne langs BCP-47. Et c'est le problème. Dans .NET, vous regroupez CultureInfo qui contient les paramètres de langue et les paramètres de format. Dans WinRT, c'est séparé et il n'y a pas d'équivalent à l'objet CultureInfo.

J'ai entendu dire que les API ICU peuvent permettre ce que nous recherchons, mais nous n'avons pas encore eu l'occasion d'enquêter là-dessus.

Je pense que Microsoft va devoir envisager de mordre la balle sur celui-ci et de mettre pleinement en œuvre un mécanisme de conversion entre les cultures/localisation .net (CultureInfo) et native/WinRT. Idéalement, vous n'envisageriez pas une nouvelle façon de faire les choses :

Je pense que le code managé est ce dans quoi la majorité des applications LOB sont écrites et cela doit être fait correctement dès le début. WinRT doit obtenir les mêmes mécanismes/techniques de localisation que .net et les conversions doivent être automatiques.

Serait-ce beaucoup plus de travail? Court terme : oui, long terme : non. Cela retarderait-il probablement la sortie du contrôle NumberBox ? Probablement, à moins que les rappels n'aient été utilisés à court terme.

Cela doit être fait correctement, sinon il y aura des problèmes ailleurs. Je peux déjà prévoir des problèmes similaires avec d'autres scénarios comme CalendarDatePicker modifiable, etc. (#735)

@SavoySchuler @jevansaks @chigy @mrlacey @KevinTXY
Apparemment, l'équipe FastDNA travaille également sur son contrôle Spinner pour la conception de son champ de numéro d'entrée, et elle a présenté une proposition qui pourrait valoir la peine d'être prise en compte.

Ils ont également demandé pourquoi nous utilisions des chevrons plutôt que des flèches.

https://github.com/microsoft/fast-dna/issues/2202

Même si nous gardons les boutons côte à côte, avec le design étendu empilé en survol, cela pourrait-il être une idée lorsque la largeur du contrôle est trop étroite ? Peut-être qu'il pourrait y avoir un consensus sur une mise en page qui fonctionne dans tous les frameworks d'interface utilisateur Microsoft ?

@mdtauk , merci de nous l'avoir
Vérifier avec les gens de FastDNA s'il s'agit de la conception sur laquelle ils testent et valider la convivialité.

De retour sur NumberBox

Bien l'équipe,

Toutes nos excuses pour la pause inattendue. Je suis de retour sur NumberBox à plein régime et @teaP me rejoint en tant que développeur de fonctionnalités ! Nous visons toujours la fin novembre pour l'aperçu de ce contrôle, qui nous amènera à envisager une version stable avec WinUI 2.4.

Il y a beaucoup de bagages dans l'ancien flux de travail, je vais donc conserver toutes les questions ouvertes ou répondues et les transférer vers un nouveau PR de spécification où @teaP et moi finirons de résoudre nos sujets ouverts restants concernant :

• localisation
• design (notamment en ce qui concerne les boutons Haut/Bas)
• hyperscroll/hyperdrag

Notez que le sujet de validation a été résolu. Avec des @LucasHaines de validation d'

enum NumberBoxBasicValidationMode
{
Désactivée,
InvalidInputOverwrite,
} ;

Venez WinUI 3.0 et le travail de validation d'entrée co-requis, nous chercherons à étendre cette énumération avec les modes de validation IconMessage et TextBlockMessage initialement prévus dans un NumberBox V2.

Je vais revenir sur tous nos progrès antérieurs maintenant, et je posterai des questions et solliciterai des commentaires si cela est pertinent. Merci d'être resté avec nous. ??

Phew. Il se rapprochait de moi d'essayer de le faire moi-même.

Haha j'aurais aimé continuer à travailler sur ça passivement mais ce semestre m'a dépassé. Contente de voir que ça s'arrange, je vais garder un œil dessus !

Le commit initial de NumberBox est en ligne maintenant !

S'IL VOUS PLAÎT - Gardez à l' esprit que ce travail est encore en cours avec suivi des problèmes actif tant sur le dev et PM côté des choses. Si vous voyez des bogues ou des problèmes généraux sur des fonctionnalités qui n'ont pas déjà été signalés sur l'un des liens appropriés, n'hésitez pas à nous le faire savoir. ??

@SavoySchuler , allez-vous ouvrir un nouveau PR pour la spécification ? Aussi, avez-vous pris note de ce que j'écris dans ce commentaire en particulier autour de l'affichage NaN ? Merci.

@SavoySchuler Quelques commentaires sur le code spec/NumberBox jusqu'à présent. Espérons que les commentaires à ce sujet puissent également se retrouver dans la spécification/la documentation. Dans l'ensemble, c'est génial de voir cela se réunir!

Fréquence de pas

L'utilisation du mot « fréquence » ici ne me convient tout simplement pas. Dans le contrôle Slider, TickFrequency est logique car les ticks sont calculés et affichés sur un module de la plage max-min globale. Cependant, dans ce contrôle, il ne s'agit que de la taille d'incrément/pas. C'est plus un "StepAmount" ou "StepValue" -- mieux encore, juste "Step" similaire à "Minimum" au lieu de "MinimumValue".

De plus, l'utilisateur pourra-t-il saisir une valeur en dehors de l'étape définie ?
Par exemple Minimum = 0, Maximum = 6, StepFrequency = 2. L'utilisation de la valeur de la flèche vers le haut sera {2, 4, 6} assez juste. L'utilisateur peut-il cependant saisir 0,5 comme valeur valide ? Ou cela sera-t-il arrondi à 0 ou 2 ?

Arrondi

Comment l'arrondi mathématique est-il géré ? Ceci est particulièrement important lors de la saisie de valeurs monétaires à l'aide d'expressions. Nous devons être en mesure de spécifier - ou de fournir - un arrondi personnalisé après le calcul d'une expression. HalfAwayFromZero est ce que je recherche pour commencer, mais d'autres modes d'arrondi devraient également être autorisés.

Localisation

Veuillez confirmer que NumberBox acceptera toute implémentation d'INumberFormatter/ INumberFormatter2 -- et continuera à le faire à l'avenir (c'est ainsi qu'il est implémenté dans le code, je veux juste m'assurer que la spécification l'appelle aussi). Cela devrait permettre un contrôle total sur la localisation du texte par rapport à l'utilisation d'un CurrencyFormatter/DecimalFormatter existant. C'est génial que nous ayons une solution pour cela!

L'habillage de texte

Edit : Je devrais lire toute la spécification la prochaine fois.

Pourquoi avez-vous créé une nouvelle propriété « IsWrapEnabled » ? Est-ce parce que vous pensez que le terme « Texte » ne s'applique pas très bien à une NumberBox ?

De plus, je comprends que Wrap et WrapWithOverflow sont implémentés de la même manière, mais permettent simplement aux deux valeurs d'énumération d'être équivalentes et décrivent la fonctionnalité dans la documentation.

Gérer correctement les accélérateurs de clavier

Veuillez vous assurer que ce contrôle prend en charge l'utilisation de l'accélérateur de clavier mieux que TextBox. Peut-être que cela ne peut pas être fait tant que TextBox n'est pas corrigé, mais #1435 est vraiment un problème pour moi qui provoque de nombreux problèmes de contournement. La zone de texte gérera elle-même une pâte 'Ctrl+V', puis tout KeyboardAccelerator sera levé. Cependant, il n'y a aucun moyen dans KeyboardAccelerator de savoir que TextBox vient de faire sa propre chose.

Une réflexion rapide. Devrait-il y avoir un mode d'angle qui ajouterait le glyphe de degré à la valeur (et toute logique pour l'enroulement à 360 °)

°

Ou cet appendice serait-il mieux géré à l'avenir avec ma proposition de suffixe pour la zone de texte #784

@mdtauk , L'ajout du symbole du degré serait possible avec un INumberFormatter2 - c'est une autre bonne raison pour laquelle cela doit rester générique. Vous pouvez faire tout ce qui est nécessaire pour convertir un nombre en chaîne et renvoyer la chaîne au contrôle.

Pour le wrapping, c'est en fait à ça que sert la propriété IsWrapEnabled... Je dois lire la fin de la documentation la prochaine fois.

En bout de ligne, je pense que nous pouvons faire tout ce que vous voulez avec l'API existante.

@mdtauk , L'ajout du symbole du degré serait possible avec un INumberFormatter2 - c'est une autre bonne raison pour laquelle cela doit rester générique. Vous pouvez faire tout ce qui est nécessaire pour convertir un nombre en chaîne et renvoyer la chaîne au contrôle.

Pour le wrapping, c'est en fait à ça que sert la propriété IsWrapEnabled... Je dois lire la fin de la documentation la prochaine fois.

En bout de ligne, je pense que nous pouvons faire tout ce que vous voulez avec l'API existante.

Je connais le Min, Max, Wrap, le gère, mais les degrés sont-ils assez communs pour avoir un mode Angle explicite pour la boîte ? Et devrait-il afficher le symbole dans le texte de la zone de texte, alors que la valeur interne n'est que le nombre.

@teaP En regardant le nouveau Compact SpinButtonMode, serait-il possible d'ajouter une animation d'affichage et de masquage aux boutons de rotation superposés ?

Avez-vous également envisagé d'ajouter de l'acrylique à cela, pour mieux faire correspondre les zones de liste déroulante et d'autres champs de formulaire avec des éléments volants ?

Edit : Cela résoudrait ce problème de visibilité dans le thème sombre. L'intention est-elle de faire correspondre la couleur ciblée de la zone de texte ou de faire correspondre les couleurs du thème actuel ? Quoi qu'il en soit, l'acrylique résout ce problème.

@SavoySchuler , allez-vous ouvrir un nouveau PR pour la spécification ? Aussi, avez-vous pris note de ce que j'écris dans ce commentaire en particulier autour de l'affichage NaN ? Merci.

@adrientetar bien sûr. Lorsque NumberBox est vide, Value sera défini sur NaN (comme vous l'avez demandé) et PlaceholderText s'affichera.

@SavoySchuler Quelques commentaires sur le code spec/NumberBox jusqu'à présent. Espérons que les commentaires à ce sujet puissent également se retrouver dans la spécification/la documentation. Dans l'ensemble, c'est génial de voir cela se réunir!

Fréquence de pas

L'utilisation du mot « fréquence » ici ne me convient tout simplement pas. Dans le contrôle Slider, TickFrequency est logique car les ticks sont calculés et affichés sur un module de la plage max-min globale. Cependant, dans ce contrôle, il ne s'agit que de la taille d'incrément/pas. C'est plus un "StepAmount" ou "StepValue" -- mieux encore, juste "Step" similaire à "Minimum" au lieu de "MinimumValue".

J'ai partagé ces commentaires avec @MikeHillberg et nous en parlons maintenant. Pour être auto-documenté parmi toutes les autres propriétés ici, nous envisageons quelque chose du genre "SpinButtonStep" si ce raisonnement est une justification suffisante pour s'en écarter. Je vous le ferai savoir. Merci d'avoir soulevé le point !

De plus, l'utilisateur pourra-t-il saisir une valeur en dehors de l'étape définie ?
Par exemple Minimum = 0, Maximum = 6, StepFrequency = 2. L'utilisation de la valeur de la flèche vers le haut sera {2, 4, 6} assez juste. L'utilisateur peut-il cependant saisir 0,5 comme valeur valide ? Ou cela sera-t-il arrondi à 0 ou 2 ?

L'utilisateur peut saisir n'importe quelle entrée de formule numérique ou légale qu'il souhaite. Consultez la section de mise en forme pour un exemple sur la façon d'utiliser la propriété NumberFormatter pour ensuite forcer cette entrée à votre mise en forme configurée.

Le SpinButton n'incrémentera ou décrémentera cette valeur que par la taille d'étape SpinButton définie (le nom de l'API est maintenant en attente). Assurez-vous donc de configurer le formatage et une taille de pas qui fonctionnent bien ensemble.

La stratégie d'arrondi utilisée est définie via votre mise en forme . Pour exposer l'exemple DecimalFormatter, voici un exemple de propriété d'arrondi que vous pouvez configurer.

Arrondi

Comment l'arrondi mathématique est-il géré ? Ceci est particulièrement important lors de la saisie de valeurs monétaires à l'aide d'expressions. Nous devons être en mesure de spécifier - ou de fournir - un arrondi personnalisé après le calcul d'une expression. HalfAwayFromZero est ce que je recherche pour commencer, mais d'autres modes d'arrondi devraient également être autorisés.

L'arrondi est géré par le formatage . Voici un exemple de propriété d'arrondi qui peut être définie pour DecimalFormatter. J'ajouterai un exemple dans les Lignes directrices pour aider à rendre cela plus clair. Merci encore. ??

Localisation

Veuillez confirmer que NumberBox acceptera toute implémentation d'INumberFormatter/ INumberFormatter2 -- et continuera à le faire à l'avenir (c'est ainsi qu'il est implémenté dans le code, je veux juste m'assurer que la spécification l'appelle aussi). Cela devrait permettre un contrôle total sur la localisation du texte par rapport à l'utilisation d'un CurrencyFormatter/DecimalFormatter existant. C'est génial que nous ayons une solution pour cela!

C'est l'intention de la mise en œuvre actuelle. Quant aux garanties de pérennité, NumberBox continuera d'avoir une solution pour les besoins de localisation et de formatage. Pour l'instant et dans un avenir prévisible, nous l'avons mis en œuvre.

L'habillage de texte

Edit : Je devrais lire toute la spécification la prochaine fois.

~Pourquoi avez-vous créé une nouvelle propriété « IsWrapEnabled » ? Cela va à l'encontre de la convention TextBox/XAML d'utiliser TextBlock.TextWrapping et TextWrapping Enum. Est-ce parce que vous pensez que le terme « Texte » ne s'applique pas très bien à une NumberBox ?~

~ De plus, je comprends que Wrap et WrapWithOverflow sont implémentés de la même manière, mais permettent simplement aux deux valeurs d'énumération d'être équivalentes et de décrire la fonctionnalité dans la documentation. Créer une nouvelle propriété ici signifie simplement que nous avons besoin de nouveaux convertisseurs de valeur, etc... il n'y a aucune raison de briser une convention existante, je pense.~

Gérer correctement les accélérateurs de clavier

Veuillez vous assurer que ce contrôle prend en charge l'utilisation de l'accélérateur de clavier mieux que TextBox. Peut-être que cela ne peut pas être fait tant que TextBox n'est pas corrigé, mais #1435 est vraiment un problème pour moi qui provoque de nombreux problèmes de contournement. La zone de texte gérera elle-même une pâte 'Ctrl+V', puis tout KeyboardAccelerator sera levé. Cependant, il n'y a aucun moyen dans KeyboardAccelerator de savoir que TextBox vient de faire sa propre chose.

NumberBox contient une zone de texte et ajoute des propriétés et des configurations par-dessus. Je vais marquer @jevan car il pourrait avoir une compréhension plus complète, mais mon intuition est que cela pourrait devoir être corrigé au niveau de la zone de texte.

Dans l'ensemble, super retour @robloo ! J'apprécie le temps que vous avez pris pour nous assurer que nous sommes aussi complets et complets que possible avec V1 NumberBox ! S'il vous plaît laissez-moi savoir si vous avez d'autres questions. ??

@mdtauk

Une réflexion rapide. Devrait-il y avoir un mode d'angle qui ajouterait le glyphe de degré à la valeur (et toute logique pour l'enroulement à 360 °)

°

Ou cet appendice serait-il mieux géré à l'avenir avec ma proposition de suffixe pour la zone de texte #784

Jusqu'à présent, NumberBox ne prend pas en charge l'affichage des caractères non numériques (car même les caractères de formule sont supprimés lors de l'évaluation des expressions).

Je pense que votre proposition pour le #784 est de loin la plus complète pour notre plateforme. Si cette proposition n'est pas suivie d'effet, cela me semble être une fonctionnalité V2 appropriée, NumberBox comme solution de secours.

Nous prévoyons déjà la sortie d'une V2 parallèlement ou peu de temps après WinUI 3.0, car deux des modes de validation d'entrée très demandés pour NumberBox sont bloqués pour avoir besoin de WinUI 3.0. J'ouvrirai donc un numéro V2 après la mise en ligne de la V1 et j'essaierai de m'assurer de le noter également.

Pour être auto-documenté parmi toutes les autres propriétés ici, nous envisageons quelque chose du genre "SpinButtonStep" si ce raisonnement est une justification suffisante pour s'écarter

Je vois que StepFrequency est ce que Slider utilise, donc je pense que nous essayions d'être cohérents avec cette terminologie. N'oubliez pas que ce n'est pas seulement pour les boutons de rotation, mais aussi pour les valeurs de changement de déplacement et de changement du fournisseur UIAutomation.

@robloo et @mdtauk , j'aurais dû lire plus loin dans le fil avant de répondre à propos de °. Je ne pense pas qu'il soit actuellement pris en charge d'afficher ce symbole à l'intérieur de Text car NumberBox garde Text et Value étroitement synchronisés afin de vous permettre en tant que développeurs de saisir quel que soit le type dont vous avez besoin sans les frais de conversion. Je n'ai pas vu de moyen d'y parvenir grâce aux propriétés de formatage disponibles, mais si vous connaissez un moyen, faites-le moi savoir !

Nous nous attaquons maintenant à la version V1, mais pour la V2, nous jetterons un nouveau coup d'œil sur les caractères préfixes/suffisants/spéciaux. En attendant, je pense que la proposition de

@adrientetar , scroll-to-change l'a fait pour V1 mais drag-to-change a été retardé à V2. Comme nous cherchons toujours à compléter ces fonctionnalités, nous n'avons pas encore discuté de votre demande de faire Shift+Up/Down par unités de 10 et Ctrl+Shift+Up/Down par unités de 100.

Pourriez-vous me donner plus de contexte sur les scénarios dans lesquels vous utiliseriez cette fonctionnalité ? Comment vos utilisateurs savent-ils que cela est disponible ? Pouvez-vous m'aider à comprendre pourquoi cela devrait être par défaut (ou au moins disponible) dans toutes les NumberBox par rapport à implémenté localement dans votre solution ?

@SavoySchuler

Merci beaucoup pour vos commentaires.

Pour être auto-documenté parmi toutes les autres propriétés ici, nous envisageons quelque chose du genre "SpinButtonStep" si ce raisonnement est une justification suffisante pour s'écarter

J'aime beaucoup cette terminologie, mais j'ai raté que Slider ait déjà la propriété StepFrequency. Puisque c'est le cas, cela n'a pas de sens de s'écarter de la convention comme l' a déclaré

L'arrondi est géré par le formatage. Voici un exemple de propriété d'arrondi qui peut être définie pour DecimalFormatter.

Supposons que l'utilisateur entre "1 / 3" dans la NumberBox. La séquence suivante est-elle alors correcte :

• En cas de perte de focus / enter l'expression sera évaluée et la double valeur de 0.333333333...34 sera calculée
• Le 0.333333333...34 sera passé au DecimalFormatter
• Le 0.333333333...34, en fonction de vos paramètres, pourrait être arrondi à "0,30" (juste pour être difficile)
• Cette valeur "0,30" sera ensuite placée dans la zone de texte pour être affichée à l'utilisateur
• Le double Value est maintenant {0,33333333...34} et la Text est maintenant "0,30"
• La lecture du double Value ne renverra PAS le nombre arrondi qui est affiché dans Text
  (Ou la valeur au format décimal est-elle à nouveau analysée après la conversion en chaîne ? puis le tout réévalué ?)

Je suis également préoccupé par le fait que les propriétés Value et Text sont si étroitement couplées en interne. La documentation ne définit pas ce couplage et s'il n'est pas très structuré, les dépendances bidirectionnelles ne sont jamais amusantes.

Je ne sais pas encore comment cela est implémenté en interne, mais il semble que la bonne façon de procéder serait de traiter la double valeur comme la seule propriété réelle. Le texte n'est qu'une version formatée de Value. Ensuite, le développeur pourrait formater la valeur comme il le souhaite pour qu'elle soit affichée dans la zone de texte et la propriété Text (nous obtiendrions le symbole de degré ou les symboles de pieds/pouces précédemment demandés). Ce ne serait pas du tout difficile à faire si tout est déjà piloté en interne par la propriété Value. L'entrée textuelle de l'utilisateur n'est de toute façon pas conservée et ne serait utilisée que pour recalculer la valeur qui est ensuite formatée à nouveau pour l'affichage.

La séquence doit être :

• Saisie textuelle utilisateur -> Analyseur syntaxique -> Double valeur -> Formatage -> Texte

Changer la valeur du texte à partir du code serait comme si l'utilisateur avait saisi du texte. La modification directe de la valeur passerait simplement par l'étape Formatage et Texte.

Pour que l'arrondi soit précis entre la séquence de valeur et de texte, cela ressemblerait plutôt à :

• Saisie textuelle utilisateur -> Analyseur -> Valeur -> Arrondi -> Valeur -> Formatage -> Texte

Edit: Pour implémenter l'arrondi dans l'analyseur d'expression/d'entrée et le moteur d'évaluation (quel que soit son nom), vous devrez probablement ajouter une nouvelle propriété pour définir l'algorithme comme RoundingAlgorithm . Cette énumération est déjà définie dans Windows.Globalization.NumberFormatting comme vous l'avez souligné. INumberFormatter2 doit être utilisé pour le formatage et rien d'autre - encore une fois, gardez les étapes découplées entre le calcul et le texte finalement affiché.

@adrientetar , scroll-to-change l'a fait pour V1 mais drag-to-change a été retardé à V2. Comme nous cherchons toujours à compléter ces fonctionnalités, nous n'avons pas encore discuté de votre demande de faire Shift+Up/Down par unités de 10 et Ctrl+Shift+Up/Down par unités de 100.

Pourriez-vous me donner plus de contexte sur les scénarios dans lesquels vous utiliseriez cette fonctionnalité ? Comment vos utilisateurs savent-ils que cela est disponible ? Pouvez-vous m'aider à comprendre pourquoi cela devrait être par défaut (ou au moins disponible) dans toutes les NumberBox par rapport à implémenté localement dans votre solution ?

L'un doit être un incrément plus grand, et l'autre doit être plus petit - similaire au décalage des zones/objets sélectionnés dans les applications Adobe

Pourriez-vous me donner plus de contexte sur les scénarios dans lesquels vous utiliseriez cette fonctionnalité ?

C'est génial lorsque vous souhaitez modifier une valeur avec des implications visuelles (par exemple la rotation d'un objet) mais que vous ne savez pas jusqu'où vous voulez aller. C'est donc bon pour la conception visuelle.

Comment vos utilisateurs savent-ils que cela est disponible ?

C'est juste une fonctionnalité dont disposent les outils modernes, par exemple Adobe XD, Framer...

Pouvez-vous m'aider à comprendre pourquoi cela devrait être par défaut (ou au moins disponible) dans toutes les NumberBox par rapport à implémenté localement dans votre solution ?

Je pense que c'est bien d'avoir cela lorsque vous êtes sur un appareil tactile, c'est un moyen pratique, appuyez-glissez, pour modifier une valeur donnée (un peu comme un widget de sélection de l'heure du téléphone où vous appuyez-glissez pour faire défiler les valeurs).

L'un doit être un incrément plus grand, et l'autre doit être plus petit - similaire au décalage des zones/objets sélectionnés dans les applications Adobe

RangeBase a les propriétés SmallChange et LargeChange. Chez BeLight Software, dans notre version de NumericUpDown, nous sommes dérivés de RangeBase et modifions la valeur par SmallChange en utilisant les raccourcis ArrowUp et ArrowDown, et par LargeChange en utilisant les raccourcis PageUp et PageDown

Et nous ne sommes pas seuls ici,
https://help.syncfusion.com/uwp/numeric-updown/gestures
https://docs.telerik.com/devtools/wpf/controls/radnumericupdown/features/navigation

Juste une remarque concernant le pavé numérique du clavier qui m'est venu à l'esprit lors de l'appel communautaire...

Dans la plupart des applications, le "." le bouton du clavier est toujours mappé sur le "." caractère différent du séparateur décimal lors de l'utilisation d'une langue autre que l'anglais (par exemple "," en français). Ainsi, lorsque vous appuyez sur le "." dans le bloc-notes, il écrit un "." caractère.

Certaines applications (Excel est la plus connue à ce sujet) modifient le comportement de cette touche pour réinterpréter toute pression sur une touche du clavier "." comme entrée de séparateur décimal. Il est plus compatible avec la conception "calculatrice" du clavier.

L'application Calculatrice réécrit également le "." appuyez sur pour l'interpréter comme un caractère séparateur décimal.

Étant donné que la boîte numérique sera davantage autorisée à fonctionner comme une "calculatrice", le contrôle pourrait-il permettre d'utiliser le "." taper sur le clavier comme séparateur décimal ? Ou au moins fournir au développeur un moyen d'ajouter cette fonctionnalité sans avoir à se battre avec des filtres et des événements clés ?

Peut-être qu'une propriété pourrait permettre d'activer (si opt-in) ou de désactiver (si opt-out) la fonctionnalité. Comme KeyPadDotAsDecimalSeparator="false" ?

Proposition de NumberBox V2 : https://github.com/microsoft/microsoft-ui-xaml/issues/1736

Bonjour merveilleuse communauté WinUI ! Merci sincèrement de nous avoir aidés à conduire à la maison notre premier contrôle proposé par la communauté pour voir la sortie. Nous savons que c'était une entreprise énorme et que vous avez tous investi beaucoup de temps dans la création de la meilleure collection de fonctionnalités V1 que nous pourrions concevoir ensemble.

Nous savons également que tout n'a pas été intégré à la version V1. Certaines configurations de validation d'entrée hautement souhaitées dépendent du travail des fonctionnalités de WinUI 3.0, certains besoins de fonctionnalités souhaités sont apparus tardivement dans la validation/l'application, et certaines fonctionnalités que nous savions seraient mieux explorées après la version V1.

Nous cherchons à terminer notre travail prévu sur la fonctionnalité NumberBox avec une version WinUI 3. J'ai ouvert un problème pour recueillir des commentaires sur les fonctionnalités nécessaires qui manquent à la V1. Si NumberBox manque quelque chose dont vous avez besoin, assurez-vous de laisser un commentaire ici : https://github.com/microsoft/microsoft-ui-xaml/issues/1736