Como punto de partida, Telerik tiene una https://www.telerik.com/universal-windows-platform-ui/numericbox. También está disponible en código abierto: https://github.com/telerik/UI-For-UWP/blob/master/Controls/Input/Input.UWP/NumericBox/RadNumericBox.cs.

Lo que me gusta de ellos es su enfoque para el formato con la propiedad ValueFormat.

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

Asegúrese también de que esté correctamente localizado. La implementación del Kit de herramientas de la comunidad de Windows tiene algunas deficiencias:

La extensión TextBoxRegex con ValidationType = "Decimal" no es compatible con todas las culturas de IU. En cambio, se fija en InvariantCulture. En inglés, los valores decimales son "10.1234" con un punto. En español o alemán los valores decimales se escriben "10,1234". Analizar el inglés será correcto; sin embargo, la entrada del usuario español o alemán será simplemente "101234" con la parte fraccional perdida.

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

Las flechas hacia arriba y hacia abajo deben incrementar o disminuir el valor en un valor que el desarrollador pueda establecer, pero el valor predeterminado debe ser un int de 1

• Los valores mínimos / máximos envolventes son buenos, por ejemplo, si se selecciona un ángulo
• capacidad de agregar un sufijo
• haga clic en el cuadro de texto y arrastre hacia arriba / abajo para cambiar los valores, Adobe XD tiene esto en las entradas numéricas.

Mi implementación en WinRT XAML Toolkit también admite arrastrar hacia arriba / abajo para cambiar valores y lo hace mucho más útil cuando se usa con el mouse que hacer clic en botones en ciertos escenarios.
https://github.com/xyzzer/WinRTXamlToolkit/tree/master/WinRTXamlToolkit/Controls/NumericUpDown

¡Hola, @sonnemaf , @ArchieCoder , @robloo , @mdtauk , @adrientetar y @xyzzer! Me han asignado esta propuesta.

Primero, gracias, @sonnemaf , por enviar esto. ¡Lo mostré en Microsoft Build 2019 la semana pasada y recibió vítores de la audiencia! La respuesta de la comunidad aquí en los comentarios también refleja la emoción que tenemos de que suceda NumberBox.

He leído los comentarios de todos y he actualizado la sección de alcance para reflejar la información recibida. Le agradecería que todos pudieran tener la oportunidad de revisar esta pequeña actualización y hacerme saber si _no_ he capturado con precisión sus solicitudes , señalando que algunos detalles (como la localización del formato) se manejarán en el nivel de especificación.

Hola @SavoySchuler ,

Esta semana, estoy trabajando en la función de accesibilidad de mi aplicación. Esto sería una ventaja si la accesibilidad se manejara correctamente con el nuevo control, por ejemplo, el incremento se puede decir en voz alta en lugar de "más", "menos". El resto me parece bien.

Es importante asegurarse de que el narrador pueda leer los valores correctamente para que quede claro lo que está sucediendo.

No estoy seguro de si el controlador Xbox necesitará un toque de enfoque para garantizar que los sticks analógicos y el D-Pad funcionarán correctamente

Pequeña corrección: arrastrar para aumentar / disminuir debería funcionar en el campo de texto hasta que se active. IIRC en mi implementación tuve que poner una superposición transparente en la parte superior del campo de texto para habilitarlo y también ocultar el cursor del mouse mientras arrastraba para que los bordes del control o la pantalla no limitaran la distancia de arrastre y eso cuando haya terminado de arrastrar y vuelvo a mostrar el cursor: aparece donde desapareció por primera vez.

@SavoySchuler tienes una buena tarea. Puedo vivir con tu alcance. Es bueno tener la calculadora (WinUI 3.0 o 3.1). Me he desarrollado en muchos entornos de escritorio (VB6, WinForms, WPF y UWP) y siempre me perdí un NumberBox. Finalmente lo conseguiremos.

Tal vez también pueda agregar la rueda de desplazamiento del mouse para arriba / abajo. Blend para Visual Studio es compatible con esto.

También me encanta arrastrar para cambiar, algo que usé mucho en Expression Blend.

No estoy seguro de qué hará y qué no hará la validación de entrada. ¿Solo será mínimo / máximo o también limitará el teclado (letras az, etc.)? ¿Manejará pegar números inválidos?

Me encantaría leer las especificaciones completas.

@ArchieCoder , te escucho alto y claro. La accesibilidad es una prioridad y se maneja mejor desde el principio. Comencé una sección de Accesibilidad e Insumos sobre esta propuesta donde agregué su nota.

@mdtauk , gran pregunta como siempre. He agregado esto a la sección Accesibilidad y entradas como una nota para analizarlo.

@xyzzer , tienes razón. Al reorganizar, la lista de alcance, agrupé los botones Arriba / Abajo y arrastrar para cambiar como funcionalidad relacionada. Al volver a leer, parecía que estaba sugiriendo que arrastrar para cambiar fuera una característica de los botones. He movido arrastrar para cambiar a su propia sección para proporcionar claridad.

@sonnemaf , increíble. Publicaré un enlace a la especificación tan pronto como se abra, que probablemente será hoy o la próxima semana. ¡Anímese a unirse a mí para escribirlo! Hasta entonces, he agregado desplazamiento para cambiar al alcance aquí.

Todo , con una nota sobre el soporte de la calculadora: creo en el valor. Estoy trabajando con mi equipo para averiguar si es algo que deberíamos modularizar en caso de que la funcionalidad pudiera aprovecharse aún más en la plataforma. Además, está la pregunta de hasta dónde llegamos con el soporte de calculadora. ¿Sería suficiente el orden simple de operaciones en + - / *? ¿O algo más completo, como conectarse a algún tipo de servicio alfa de wolframio? Explorar una ruta modular podría permitirnos comenzar con el caso más básico sin bloquear la oportunidad de una forma más completa de soporte de calculadora. Me interesaría conocer las necesidades de todos aquí.

Para la validación de entrada, tengo la misma pregunta. ¿Lo cubre min, max, sin letras y sin pegar inválido?

Encuentro linda la función de la calculadora, pero prácticamente, ¿cómo puede un usuario descubrir esta función? ¿Va a haber una pequeña pista de widget sobre esto?

@ArchieCoder , ¿cree que el texto de marcador de posición personalizado descolorido en el NumberBox podría indicar adecuadamente a un usuario? Si es así, imagino que una cadena como "a + b - c" o "ingresar ecuación" podrían ser formas sucintas de entregar esa información. Excel también ha creado un estándar con "=" que aparece al comienzo de una ecuación. ¿Quizás una vez que el usuario hace clic en NumberBox, aparece un "=" inmutable en el frente que el usuario escribe detrás?

Tenemos ToolTip o TeachingTip más pesado como guía a nivel de la aplicación en la que podríamos pedir a los desarrolladores que confíen, pero mi mayor preferencia sería resolver esto dentro del propio NumberBox.

¡Estoy interesado en escuchar tus pensamientos aquí!

El marcador de posición sería una buena opción siempre que no se requiera otro contexto debido a la limitación de espacio. Creo que el ancho de NumberBox será más pequeño que un cuadro de texto, por ejemplo.

A menos que el control admita números que aceptan valores NULL, siempre mostrará un valor,
por lo que no habrá espacio para una cadena de marcador de posición dentro de él.

El viernes 17 de mayo de 2019 a las 10:14 a. M. ArchieCoder [email protected]
escribió:

El marcador de posición sería de hecho una buena manera siempre que otro contexto no sea
requerido debido a la limitación de espacio. Creo que un ancho de NumberBox
ser más pequeño que un cuadro de texto, por ejemplo.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMAL7LUOVPIM55PYO4LPV3RWPA5CNFSM4HA4PBNKYY3PNVWWWK3TUL52HS4DFVLOXWG43LKM52HS4DFVREXWG43LKMDFZVREXWG43
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AANMBMBKHP7GP5WUHLPWNZLPV3RWPANCNFSM4HA4PBNA
.

@ArchieCoder , como los ejemplos de @sonnemaf (gracias de nuevo por estos), cualquier NumberBox que no sea lo suficientemente ancho como para mostrar el texto del marcador de posición para "a + b - c" tampoco sería lo suficientemente amplio como para crear una experiencia de usuario recomendada para entrar ecuaciones en. En ese sentido, me imagino que esta opción de solución sigue siendo viable para este propósito. Sin embargo, creo que está aprovechando un área que aún no hemos abordado: escenarios en los que queremos un NumberBox compacto / solo se ingrese un número simple. Me imagino que el soporte de Calculadora necesitaría una API para deshabilitarlo, en cuyo caso no debemos preocuparnos por el texto de marcador de posición largo ni por romper las limitaciones de espacio mínimo que la forma de ecuación de NumberBox necesitaría, aunque alguna opción de texto de marcador de posición para el modo compacto aún puede ser agradable , incluso si es solo para algo como "#" o "por ejemplo, 2".

@xyzzer , gracias por mencionar este tema. ¡Asegurémonos primero de que esta sea incluso la experiencia de usuario correcta y podamos descubrir la implementación a partir de ahí! Todavía no es necesario limitar nuestra búsqueda de la experiencia del usuario _derecha_ debido a limitaciones técnicas que podemos mitigar. :relajado:

Tengo una pregunta de mayor prioridad para todos:

¿Preferiría tener un control NumberBox que consolide estas características independientemente de un TextBox estándar o preferiría tener estas características integradas en TextBox como capacidades nativas que podrían activarse a través de API o InputScope?

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

Es un cambio significativo poner todo esto en un control TextBox.

La validación de los caracteres ingresados.

Usar la distribución de teclado correcta con InputScope

Los diferentes comportamientos del mouse.

La capacidad de mostrar botones giratorios como en la versión FabricWeb.

Si todas estas cosas pudieran agregarse, con una enumeración de comportamiento para definir el tipo TextBox, sin tener un impacto en todos los demás que actualmente usan un TextBox en su aplicación, entonces bien.

E incluso podría considerar combinar otros comportamientos de TextBox como un ícono que podría representar una búsqueda o un calendario que actúa como un botón. Máscaras para cosas como direcciones IP o URL que muestran "http: //" en el estilo de texto de marcador de posición a medida que ingresa el texto al lado.

FabricWeb tiene una amplia variedad de TextFields.

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

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

Definitivamente iría con un control NumberBox propio en lugar de integrar todas estas características en un control TextBox (similar a cómo también hay un control PasswordBox y no un TextBox con una "contraseña" en modo de entrada).

El control NumberBox será mucho más que un simple campo de entrada para direcciones IP, por ejemplo. Vendrá con su propia accesibilidad / características únicas de desplazamiento y arrastre, soporte de calculadora, ... todo lo cual lo distinguirá bastante de cómo normalmente he usado un TextBox hasta ahora (casos tan simples como especificar un nombre de representación para un grupo de datos). Y a medida que se propongan aún más características / requisitos especiales para el control NumberBox, podemos mantener una separación agradable y limpia entre NumberBox y TextBox.

Esa expresión también vendría abajo en la documentación y el diseño xaml de la aplicación (NumberBox más fácilmente detectable que, digamos, un TextBox con un montón de propiedades y una de ellas especifica el modo de entrada). En lugar de leer la documentación de TextBox sobre sus capacidades de entrada numérica, esa parte sería agradable y ordenada en una documentación de control de NumberBox específica (al igual que con PasswordBox hoy).

Con respecto a la apariencia del control, creo que la unidad / sufijo podría mostrarse a un lado con un tamaño más pequeño / color desaturado para que se diferencie del valor en sí:

Cuando el mouse se desplaza sobre el control, las flechas arriba / abajo pueden aparecer en lugar de la unidad:

Una alternativa son los controles numéricos de figma.com, cuando se desplaza sobre la unidad, puede hacer clic y arrastrar hacia la izquierda / derecha para cambiar el valor.

Izquierda / derecha es interesante porque es más fácil mover el mouse hacia la izquierda / derecha que hacia arriba / abajo (no es necesario que levante la muñeca).

Otras cosas:

• Al hacer clic en el área de texto desenfocada, debe seleccionar todo el contenido. de modo que hacer clic + escribir un valor + ingresar cambia el valor
• Mayús + clic en una flecha o Mayús + Arriba / Abajo cuando se enfoca aumentar o disminuir en 10 (creo que ese valor también debería ser personalizable).
• No creo que las flechas arriba / abajo sean muy útiles para el usuario. Si el usuario desea un valor preciso, simplemente lo ingresa, si no está seguro del valor que desea, puede visualizar un espectro de cambios de valor haciendo clic + arrastrando. Entonces, las flechas arriba / abajo probablemente deberían ser al menos opcionales.

@adrientetar poner una indicación de la unidad dentro del control crea muchos problemas adicionales:

• localización
• accesibilidad
• seleccionar
• pegado
• conversiones

Todo esto se evitaría colocando esto en el encabezado, la descripción o un TextBlock separado.

Yo optaría por un control NumberBox separado con una propiedad Value y tal vez no una propiedad Text. El valor debe ser un doble para que podamos vincularlo (x: vincular). No estoy seguro de si también deberíamos admitir el tipo de datos Decimal y cómo.

El soporte para números que aceptan valores NULL es un DEBE, creo (gracias @xyzzer). La propiedad Value debe ser anulabletipo de datos. No estoy seguro de si esto causará problemas vinculantes al vincularlo a un valor no anulable.

Si bien la composición tiene beneficios y tiene un comportamiento adjunto para los numerados
El modo podría implementarse y adjuntarse a un TextBox; creo que haría
es innecesariamente complicado y limitado.
Algunos de los mayores problemas que probablemente encontraría con la implementación se relacionan con
accesibilidad. Creo que para respaldar algunos de los patrones de accesibilidad:
necesitaría hornear en la implementación de ciertas interfaces en TextBox
eso lo haría confuso si un TextBox no estuviera en un modo de cuadro numérico.

El lunes 20 de mayo de 2019 a las 2:33 a. M. Fons Sonnemans [email protected]
escribió:

El soporte para números que aceptan valores NULL es un DEBE, creo (gracias @xyzzer
https://github.com/xyzzer ). La propiedad Value debe ser anulable
tipo de datos. No estoy seguro de si esto causará problemas vinculantes al vincularlo a
un valor que no acepta valores NULL.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBGVIQ36CDPQO6CWKLPWJV55A5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVLOXWG43LVAH4DFVREXWG43
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AANMBMBTHT2UXOAGRTEDF7LPWJV55ANCNFSM4HA4PBNA
.

Tengo una pregunta más para todos. ¿Necesita / prefiere validación de entrada o enmascaramiento?

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

La validación es esencial, ya que no puede agregar un número a una cadena. Y los operadores matemáticos deben evaluarse y procesarse.

¿Necesita que se muestre un mensaje de error si no puede calcular, de lo que no estoy muy seguro?

El enmascaramiento sería útil, pero probablemente debería estar integrado en el cuadro de texto mismo, de modo que se pueda manejar la entrada de URL y correo electrónico. NumberBox serían números de teléfono, direcciones IP, etc.

No creo que un NumberBox deba usarse para números de teléfono o IP. Estos parecen más simples extensiones de enmascaramiento / filtrado para un TextBox. Un NumberBox es algo que le gustaría usar para ingresar un solo valor.
Quizás existe la posibilidad de tener un control de caja de divisas, pero también creo que debería ser un control separado diferente de TB o NB.

@xyzzer Me parece una buena idea hacer que NumberBox sea más flexible para cualquier tipo de entrada numérica. Puede derivarse de un control TextBox y ese control podría tener una propiedad Mask, así como otras propiedades de comportamiento.

Algunas de esas propiedades en NumberBox podrían ser:

• Mostrar / Ocultar botones giratorios
• Permitir incremento y decremento de valores
• Permitir el cálculo de valores
• Permitir entrada enmascarada
• Máscaras localizadas como números de teléfono o direcciones IP

Las propiedades que podrían agregarse al TextBox podrían ser:

• Una propiedad de máscara: una cadena XAML para definir un formato personalizado ([email protected]), así como máscaras localizadas, como códigos postales / postales
• Visualización de texto de prefijo / sufijo (_http: // _ como prefijo, por ejemplo)
• Mostrar / ocultar el botón de acción: con un icono y hacer clic en la propiedad del evento
• Ícono (el cuadro de búsqueda de la interfaz de usuario de Fabric muestra su ícono a la izquierda y se anima cuando el cuadro se enfoca)

Estas imágenes son del TextField de la interfaz de usuario de Fabric, y es compatible con todos estos estados diferentes, deberíamos apuntar a llevar los controles de Fluent WinUI 3.0 a la paridad siempre que sea posible

Los botones de Fabric UI Spinner son demasiado pequeños para tocarlos, por lo que los formatearía de manera diferente para que los botones arriba y abajo estén uno al lado del otro, no apilados uno encima del otro.

Para mí, la validación es imprescindible y el enmascaramiento es un placer tener. Nunca me gustó el enmascaramiento; es demasiado rígido.

@rudyhuyn propuso en el repositorio de la Calculadora de Windows una característica interesante . @mdtauk lo comentó .

Puede abrir una ventana emergente de calculadora desde NumberBox similar a un selector de fecha / hora / calendario.

Similar a lo que dijo @xyzzer anteriormente. Existe una diferencia fundamental entre un número y una cadena que contiene una secuencia de dígitos.
La mejor forma en que he escuchado la descripción de la diferencia es que puedes realizar operaciones de multiplicación y división en un número. Puedes pedir la mitad de un número y dividir por dos. No puede pedir la mitad de un código postal o un "número de teléfono" y obtener algo significativo.

La combinación de un NumberBox específico que tiene capacidades matemáticas con la funcionalidad para capturar otros valores que comprenden dígitos también puede generar otros problemas.
Los "números de teléfono" pueden comenzar con ceros a la izquierda (o un signo más) y ahí tienen significado. Por un _número_ no lo hacen y serían despojados.
Los "números de teléfono" a menudo también se formatean con corchetes y guiones. Cuando se procesan como operaciones matemáticas, estas fácilmente podrían terminar siendo interpretadas como que requieren multiplicación y resta.

Permitir el enmascaramiento de la misma manera que TextBox y como una forma de formatear la entrada corre el riesgo de confundir la diferencia entre NumberBox y TextBox y cuándo se debe usar cada uno.

La validación simple cuando la validación llegue a la plataforma , esto no resulte en formas de tener métodos de validación en conflicto o algo que podría fácilmente empujar a los desarrolladores a difundir su validación a múltiples ubicaciones. .

Mantendría la validación para basarme solo en estas propiedades:

• Valor máximo
• Valor mínimo
• AllowDecimalPlaces

Por separado, debe haber una indicación de

• salida no válida de los cálculos
• cómo manejar un valor ingresado / pegado / calculado y qué se usa en una encuadernación. Es necesario mostrar el cálculo o el valor no válido para mostrar que no es válido, pero esto no se puede pasar a ninguna propiedad de respaldo,

Las máscaras necesitarían una capacidad visual para dejar en claro lo que se requiere, mientras que las entradas de cálculo básicas no se utilizarían junto con las entradas enmascaradas.

Los controles de texto de Fabric Web parecen manejar esto muy bien, pero, por supuesto, el alcance del NumberBox está separado de las mejoras generales de ajuste y acabado del control TextBox predeterminado.

Los botones giratorios (y quizás el control flotante opcional de la Calculadora) son las únicas cosas visuales que parecen específicas de un NumberBox.

En cuanto a las propiedades, quizás si los botones arriba y abajo del teclado están habilitados para cambiar el valor, se podría incluir un valor de Paso para que pueda elegir cuánto aumentar o disminuir al presionar una tecla.

@mdtauk , me gusta el valor de Paso , pero no solo al presionar una tecla. También en el botón de desplazamiento y arriba / abajo.

@sonnemaf Seguro, el paso es bueno para algo binario como un tic de la rueda del mouse, presionar una tecla o una tecla hacia abajo. ¿Quizás la distancia arrastrada desde la caja podría aumentar la cantidad de pasos?

Entonces, ¿ StepMinimum y StepMaximum quizás?

Entonces, ¿StepMinimum y StepMaximum quizás?

No tengo idea de con qué podrían relacionarse esos valores o qué esperar de ellos.
Si el propósito de "Paso" es definir incrementos, llámelo "Incremento".

Esto permitiría que Max:100 Min:0 Increment:10 solo permita especificar los valores 0, 10, 20, 30, 40, 50, 60, 70, 80, 90 y 100.

El hecho de que la cantidad de paso / incremento varíe en función de la distancia arrastrada podría provocar cambios de valor impredecibles. Si el propósito de este control es facilitar la especificación de valores numéricos, entonces si el valor comienza a cambiar en cantidades variables, entonces probablemente lo encuentre muy frustrante, lo que frustraría el objetivo subyacente de tener un control dedicado para hacerlo más fácil.

@mrlacey Utilizo Step ya que es la propiedad nombrada para el control deslizante y las barras de progreso, pero el incremento podría usarse si se prefiere. El valor sube y baja, siempre y cuando el incremento no se confunda con solo un incremento en el valor.

Existe una propuesta para hacer clic y arrastrar hacia arriba o hacia abajo para aumentar o disminuir el valor. Si el usuario espera que el valor cambie más rápido, cuanto más hacia arriba o hacia abajo arrastre, entonces tener un valor Stap Min y Max permitiría al desarrollador controlar esto a medida que cambia el delta. Por lo tanto, una pequeña distancia de arrastre podría aumentar en 0,1 o 1 , pero arrastrar más podría cambiar en pasos de 5 o 10, por ejemplo.

No estoy diciendo que la distancia de arrastre tenga que cambiar la velocidad del cambio de valor, solo que es una idea que puede ser útil, si se siente natural y le da al usuario cierta sensación de confianza y control.

¡Comentarios increíbles para todos! Abrí una especificación y relaciones públicas para comenzar a trabajar en los detalles.

@KevinTXY se unirá a mí como desarrollador de este control. Continuaremos la conversación de requisitos aquí y comenzaremos la conversación específica de API / ejemplo sobre las relaciones públicas.

Siéntase animado a unirse a mí para escribir la especificación.

La especificación de TeachingTip es un ejemplo completo de cómo se verá una especificación terminada. El esquema principal será:

• Descripción
• Ejemplos para cada API / función
• Pautas
• API (IDL)

Grandes ideas, me gusta a dónde va todo esto. Añadiendo mis dos centavos:

• Sin lugar a dudas, creo que esto debería ser un NumberBox separado en lugar de estar integrado con TextBox. Además, hay muchas características buenas que se discuten aquí, pero también debemos mantener el peso ligero de NumberBox. Por lo tanto, propongo derivar una CalculatorBox o algo similar de NumberBox y que pueda tener las entradas avanzadas "2 + 3" o un botón para abrir una calculadora.
• La localización debe estar bien pensada en la especificación antes de tiempo. Además, hay casos en los que desearía anular la interfaz de usuario local. Por lo tanto, establecer una propiedad NumberformatInfo o CultureInfo puede resultar muy útil. Por ejemplo, en algunas aplicaciones se realiza un seguimiento de un valor local y extranjero. Cada uno podría tener potencialmente un formato diferente.
• El control debe admitir el movimiento de un lugar decimal. Esto es más complicado que simplemente validar un formato en cada texto modificado. Es necesario realizar un seguimiento de cada entrada de carácter y reemplazar el decimal anterior según sea necesario.
• Cualquier flecha de incremento / decremento debe ser configurable para apagarse y tener un cuadro de entrada simple; nuevamente, necesitamos un control liviano aquí para los casos en que se necesita como parte de otros controles.
• Otra cosa que no se ha discutido es que, idealmente, debemos admitir múltiples tipos: decimal, entero y potencialmente largo, doble, etc. Esto podría cambiar fundamentalmente muchas cosas y aún no lo he pensado completamente. .
• El valor definitivamente debe ser anulable. Un valor no establecido es diferente de cero.
• Otra idea que no es crítica es permitir que se especifique la precisión decimal para los tipos decimal, doble o flotante.

Estoy seguro de que seguirán más ideas. ¡Espero leer las especificaciones!

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

Tengo la especificación / PR completo con API y ejemplos para cada uno. Creo que he abordado el formateo según sus especificaciones con una enumeración para los tipos predefinidos básicos (aún en progreso), así como una propiedad de formato personalizado que anulará los tipos predefinidos si se establece.

Compruébelo y avíseme si no resuelve sus inquietudes o si se puede agregar o mejorar. Aceptaré solicitudes de extracción que contribuyan a las especificaciones solicitadas aquí.

• La validación se considera imprescindible. He prescrito este control para derivar de TextBox para obtener enmascaramiento y otras propiedades de soporte de forma gratuita.

• Para preocupación de @mrlacey , agregué una API para habilitar / deshabilitar la eliminación de ceros iniciales que se pueden usar junto con la cadena de formato personalizado para habilitar escenarios para la entrada de cadenas numéricas personalizadas (teniendo en cuenta que los números de teléfono internacionales y las direcciones IP ya están en la lista de posibles tipos de formatos básicos).

• Esto, junto con la capacidad de habilitar / deshabilitar el soporte de la calculadora, para mí, aterriza en la intersección para un control que puede ser liviano para valores numéricos / cadenas, pero también ofrece suficiente soporte de cálculo y personalización. Creo que la concisión de los ejemplos resalta esto, pero estoy interesado en escuchar a cualquiera que piense que esto haría que el control prospectivo sea más engorroso de usar.

• @sonnemaf Aprecio la novedad y la intuición del ejemplo de icono> calculadora emergente. Para mí, esto se deriva por ejemplo del concepto de CalendarDatePicker y podría ser una excelente consideración para una función de V2 a menos que haya un fuerte impulso de todos aquí para que se considere para V1.

Una calculadora emergente puede tener sentido si hay coordinación con el esfuerzo de código abierto de Calculadora. Tanto por la coherencia en el aspecto de Calculator Flyout, como también en el motor detrás de él.

No estoy seguro de si este es el lugar para publicar esta imagen, pero aquí hay diseños para los distintos estados que se ajustan a las especificaciones.

La imagen está a una escala del 200%

@mdtauk ¿cuál es el propósito de tus maquetas?

¿Qué estado intenta mostrar cada imagen? Sin que usted aclare esto, podemos hacer suposiciones diferentes a las suyas.

¿Están destinados a ser referencias perfectas en píxeles?

¿Puede indicar dónde algo en sus imágenes difiere del valor predeterminado de la plataforma o del control base para que quede claro qué (si es que hay algo) que está agregando o cambiando?

@mrlacey ¿Podría hacer un desglose más completo si eso fuera útil? Solo estaba tratando de ilustrar algunos de los ejemplos mencionados en la especificación.

El propósito de ellos es intentar ilustrar cómo podrían verse estos controles con los distintos elementos de control propuestos como prefijo, sufijo, máscaras, botones arriba y abajo. Se extrapolan de los diseños de control de FabricWeb, pero utilizan elementos XAML como FocusReveal y controlan el tamaño de los botones.

Los ejemplos muestran el estado de reposo - enfoque - deshabilitado

La calculadora emergente sería una buena característica para V2.

No estoy seguro de dónde poner mis comentarios. ¿Debo hacer un PR según las especificaciones o puedo seguir escribiendo mis pensamientos en este número?

Entero

¿Sería útil un valor entero para NumberBoxFormatType?

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

Idioma

¿Utilizaría el idioma para especificar la moneda, los símbolos de agrupación de dígitos decimales?

En el siguiente ejemplo, el idioma se establece en nl-NL. ¿Significa esto que el prefijo es el signo del euro, el símbolo decimal una coma con 2 decimales después y la agrupación de dígitos es un punto? La moneda negativa tiene un signo menos al frente y sin paréntesis como en los EE. UU.

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

¿Es esto suficiente porque hay muchas opciones de formato de número y moneda en Windows?

Valorar propiedad o propiedades

¿Necesitamos una propiedad Value y qué tipo (numérico) sería? Lo usaría para vincularlo a datos. ¿Debe ser doble, decimal o int. ¿Necesitamos compatibilidad con Nullable (doble ?, ¿decimal ?, ¿int?). No quiero usar la propiedad Text del control TextBox heredado para el enlace de datos. También necesitamos soporte para Decimal, el doble no es suficiente.

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

¿Qué pasa si la propiedad Salario del empleado es anulable?(¿decimal?). ¿Necesitamos la propiedad de dependencia ValueNullableDecimal? El control SelectedDate del DatePicker es anulable. Nullable es un problema, especialmente con el enlace de datos.

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

Lo mismo ocurre con MinValue y MaxValue. Ahora son enteros en la especificación, pero ¿no debería ser un doble?

@sonnemaf porque la especificación dice que el control es para cualquier cosa donde se puedan ingresar dígitos, creo que eso tiene que significar que trata el "Valor" como texto y se basa en el código de consumo para convertir según sea necesario. No es ideal, pero incluso si hubiera una propiedad Value que fuera larga o flotante, habría muchas ocasiones en las que serían necesarias conversiones.
Es mejor que las sobrecargas para todos los tipos numéricos.
Luego están las cosas para las que se está diseñando el control para las que no se puede convertir a un tipo "numérico", como el código postal de los EE. UU., El número de teléfono o la dirección IP. Para este tipo de valores, obtener el texto parece ser la mejor (única) opción.
Creo que es más simple (al menos en la versión inicial tener una forma de acceder al valor ingresado y depender de los convertidores cuando sea necesario. Puedo ver un lugar para una colección de ayudantes (o subclases) que vienen al kit de herramientas inicialmente y luego algunos de se incorporan al control principal en función de la retroalimentación.

¿Es necesaria una propiedad Language ? ¿Por qué no sería lo mismo que UILocale? Puede haber buenas razones, pero parece que esto debería ser configurable por el usuario (a nivel de sistema operativo) y dar la capacidad de especificar un formato específico podría generar más problemas para los desarrolladores cuando el formato no coincide en otro lugar o lo que el usuario de la aplicación quiere. Fuera de mi cabeza: ¿qué pasa si alguien pega un valor en un formato diferente?

@mdtauk ¿cuál es el propósito de tus maquetas?

¿Qué estado intenta mostrar cada imagen? Sin que usted aclare esto, podemos hacer suposiciones diferentes a las suyas.

¿Están destinados a ser referencias perfectas en píxeles?

¿Puede indicar dónde algo en sus imágenes difiere del valor predeterminado de la plataforma o del control base para que quede claro qué (si es que hay algo) que está agregando o cambiando?

@mrlacey ¿Es este el tipo de cosas que

@mdtauk eso es un poco mejor, ya que explica algo de lo que intentas mostrar.

Sin embargo, la pregunta subyacente aún permanece: ¿Cuál es su objetivo al mostrar esto? ¿Es solo una idea? ¿Es tu versión preferida después de haber explorado diferentes ideas? Si es así, ¿por qué son estos los mejores / preferidos?

Comparar los controles actuales con cómo le gustaría que se mostraran los nuevos controles en sus nuevos estilos preferidos para todo el sistema significa que no es posible separar lo que es específico del control con lo que está en sus nuevos estilos preferidos para todo el sistema.

Por ejemplo, mencionas cambiar la transparencia en un borde. ¿Este cambio está destinado a todos los controles o solo a este? ¿Y en que estados?

Dar tamaños explícitos (para botones) puede ser problemático en las composiciones de diseño, ya que no siempre se traducen de manera uniforme en función del tamaño de su contenedor. ¿Deberían ser siempre cuadrados? ¿O se fija su ancho en función de la altura de control predeterminada?

¿Cómo propone que se determine el pincel de fondo para prefijos y sufijos? Supongo que hay un cepillo de sistema existente, pero ¿cuál?

El enmascaramiento no está cubierto en esta especificación. ¿Están sus ejemplos "enmascarados" destinados a relacionarse con cadenas de formato?
¿Cómo se corresponde el ejemplo enmascarado con un formato?
Supongo que su ejemplo muestra la entrada de una dirección IP de la versión 4, pero parece que hay muchas suposiciones basadas en lo bien que parece encajar todo. ¿Todos los valores no editables deberían tener un fondo y márgenes? ¿Qué pasa si no siempre se muestran? ¿Debería extenderse el contenido para que se ajuste a todo el espacio disponible, como parece ser el caso en su ejemplo? ¿Cómo se tratará el espacio asignado para los valores no editables al realizar una panorámica de contenido que sea más ancho que el espacio disponible?

@mdtauk eso es un poco mejor, ya que explica algo de lo que intentas mostrar.

Sin embargo, la pregunta subyacente aún permanece: ¿Cuál es su objetivo al mostrar esto? ¿Es solo una idea? ¿Es tu versión preferida después de haber explorado diferentes ideas? Si es así, ¿por qué son estos los mejores / preferidos?

Comparar los controles actuales con cómo le gustaría que se mostraran los nuevos controles en sus nuevos estilos preferidos para todo el sistema significa que no es posible separar lo que es específico del control con lo que está en sus nuevos estilos preferidos para todo el sistema.

Por ejemplo, mencionas cambiar la transparencia en un borde. ¿Este cambio está destinado a todos los controles o solo a este? ¿Y en que estados?

La especificación NumberBox no incluyó ningún ejemplo visual, y las imágenes en la propuesta original son ejemplos aproximados de funcionalidad. Hay otro PR # 524 donde las plantillas de control se actualizan con valores de CornerRadius en 2epx, que también es el mismo redondeo que utiliza Fabric Web.

Entonces, asumiendo que los controles derivados de TextBox también se actualizarán de manera similar, lo usé como una guía para mostrar cómo la funcionalidad propuesta de NumberBox podría encajar en eso. Los campos de texto de Fabric Web ya son compatibles con los valores de prefijo y sufijo, por lo que simplemente tomé ese diseño y usé las métricas XAML.

Dar tamaños explícitos (para botones) puede ser problemático en las composiciones de diseño, ya que no siempre se traducen de manera uniforme en función del tamaño de su contenedor. ¿Deberían ser siempre cuadrados? ¿O se fija su ancho en función de la altura de control predeterminada?

El TextBox actual tiene algunos botones integrados, como el SearchBox, el botón Revelar contraseña y el botón Clear Text. Los objetivos táctiles para XAML sugieren que los botones sean de 32 x 32 epx; simplemente los mantuve cuadrados y utilicé esa guía.

¿Cómo propone que se determine el pincel de fondo para prefijos y sufijos? Supongo que hay un cepillo de sistema existente, pero ¿cuál?

En mi ejemplo utilicé el color de primer plano del tema pero con una opacidad del 15%. Los de FabricWeb usan más cerca del 10% y los botones XAML usan el 20%.
Hay valores de pincel similares como ListLowBrush pero es posible que necesite un nuevo pincel TextBoxAppendixBackground. Text Foreground usaría el mismo pincel PlaceholderTextForeground.

El enmascaramiento no está cubierto en esta especificación. ¿Están sus ejemplos "enmascarados" destinados a relacionarse con cadenas de formato?
¿Cómo se corresponde el ejemplo enmascarado con un formato?
Supongo que su ejemplo muestra la entrada de una dirección IP de la versión 4, pero parece que hay muchas suposiciones basadas en lo bien que parece encajar todo. ¿Todos los valores no editables deberían tener un fondo y márgenes? ¿Qué pasa si no siempre se muestran? ¿Debería extenderse el contenido para que se ajuste a todo el espacio disponible, como parece ser el caso en su ejemplo? ¿Cómo se tratará el espacio asignado para los valores no editables al realizar una panorámica de contenido que sea más ancho que el espacio disponible?

No voy a fingir que tengo todas las respuestas para esto, y cómo se muestra visiblemente en el control se reducirá a cómo se implementa el formato de la máscara en los controles.

Usé la dirección IP v4 ya que es el ejemplo que se presenta en la especificación, y mi intención original era ilustrar lo que se estaba proponiendo (aunque faltaban los ejemplos de prefijo y sufijo, así que elegí otros valores)

Eché un vistazo a cómo otros controles manejan el enmascaramiento, y algunos usan texto en línea que mueve el Caret a medida que se ingresan los valores. Otros ingresarán cosas como corchetes y guiones al ingresar un número de teléfono. Algunos usan tabulaciones o teclas de flecha para moverse entre los segmentos. El ejemplo más cercano de Microsoft que me viene a la mente es ingresar claves de producto durante la instalación de Windows.

Pensé que usar el mismo estilo que los elementos adjuntos se ajustaría a la estética, pero soy consciente de que esto aumenta la longitud del control para encajarlo todo, y en línea puede hacer un mejor uso del espacio.

Solo una nota, ya que estoy trabajando con TextBox ahora, con él no hay un solo evento para señalar un valor cambiado por el usuario (es decir, la unión de enfoque perdido y tecla de retorno presionada), similar a https://doc.qt.io /qt-5/qlineedit.html#textEdited Sería genial tener eso en el NumberBox, ya que está destinado a este tipo de ediciones. Por cierto, si va a manejar todo tipo de valores como direcciones IP, ¿quizás el cuadro "Número" sea un nombre demasiado estrecho? Podría ValueBox o algo así

@adrientetar NumberBox parece estar bien como nombre, porque todas las entradas cuentan como números. La dirección IP tiene 4 números, números de teléfono, moneda, medidas, etc.

DigitBox, NumeralBox, etc.son todas variantes que no se ajustan al estilo de nomenclatura de Microsoft.

Los valores tampoco tienen que ser de naturaleza numérica, por lo que ValueBox también puede ser un poco engañoso.

@sonnemaf y @mdtauk , hablé con mi equipo sobre la idea de la calculadora incorporada y, en resumen, nos ENCANTA, sin exagerar. Estamos más que entusiasmados con la forma en que todos ustedes ya han elevado la calidad y la creatividad de los controles que ofrecemos.

Necesitaré tu ayuda para que esto suceda. La forma en que nos mantenemos al tanto de la letanía de ideas asombrosas que surgen a través de nuestro repositorio es no solo estar impulsadas por las ideas, sino también por los escenarios. (Comparto esto porque hablar este idioma le dará a sus solicitudes de funciones una influencia concreta en todo nuestro repositorio).

¿Alguno de ustedes puede habilitarme con escenarios reales para una calculadora integrada en cualquiera de las aplicaciones que desarrolle? El contexto, las capturas de pantalla, los perfiles de usuario, todo ayuda. (Mi correo electrónico también está en mi perfil de GitHub si prefiere mantener la confidencialidad de los detalles). @Xyzzer , @mrlacey , @robloo , @ Felix-Dev, @adrientetar y @ArchieCoder , siéntase animado a compartir su escenario de uso si esta función es de su interés también.

Más allá de este paso, lo único que podría obstaculizar esta función sería el riesgo de inflar el tamaño de la DLL de WinUI con el motor de la aplicación de la calculadora. Examinaré esto en paralelo para analizar la viabilidad.

Anteriormente mencioné el tema de tratar este control para más que solo tipos numéricos.

Existe una diferencia fundamental entre un número y una cadena que contiene una secuencia de dígitos.

Esto fue antes de que se publicara el primer borrador de la especificación, así que supongo que se consideró y se tomó la decisión de que este control manejara tanto "valores numéricos tradicionales" como también "cadenas que contienen dígitos numéricos".

No creo que nadie realmente intente argumentar que una dirección IPv4 es un "número" por cualquier otra definición que no se suele representar como una secuencia formateada de dígitos. En realidad, es solo un valor de 4 bytes.

@SaboyaSchuler

• Ingresar gastos quizás: ingresar aquellos artículos de un recibo donde algunos artículos son personales y otros parte del trabajo.
• ¿Aplicación de restaurante al dividir una factura, o tal vez calcular la propina?
• Aplicación de edición hexadecimal, para calcular un valor de compensación al que mover la selección?

Tener un control que admita direcciones IP sería una gran adición a la plataforma, pero no creo que NumberBox sea el control adecuado para este escenario.

Como se mencionó anteriormente, el control NumberBox:

• usar el teclado virtual Number cuando se usa en un dispositivo sin teclado físico
• tener 2 botones - / +
• mostrar una ventana emergente con una calculadora o permitir al usuario escribir operaciones aritméticas básicas

Ninguna de estas funciones tiene sentido con la dirección IP. Incluso el diseño del control es muy diferente.

Además, debemos tener en cuenta que si admitimos direcciones IPv4, también debemos admitir direcciones IPv6, no usando dígitos sino hexadecimales.

Creo que tendría más sentido no incluir la compatibilidad con direcciones IP en este control, sino trabajar en un nuevo control MaskedTextBox para UWP (compatible con IPv4, IPv6, número de teléfono, código postal, SSN, etc.) con una interfaz de usuario rica (como lo demostró @mdtauk) para reemplazar / mejorar TextBoxMask del Community Toolkit (https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask)

Tener un control que admita direcciones IP sería una gran adición a la plataforma, pero no creo que NumberBox sea el control adecuado para este escenario.

Como se mencionó anteriormente, el control NumberBox:

• usar el teclado virtual Number cuando se usa en un dispositivo sin teclado físico
• tener 2 botones - / +
• mostrar una ventana emergente con una calculadora o permitir al usuario escribir operaciones aritméticas básicas

Ninguna de estas funciones tiene sentido con la dirección IP. Incluso el diseño del control es muy diferente.

Además, debemos tener en cuenta que si admitimos direcciones IPv4, también debemos admitir direcciones IPv6, no usando dígitos sino hexadecimales.

creo que tendría más sentido no incluir el soporte de direcciones IP en este control, sino trabajar en un nuevo control MaskedTextBox para UWP (compatible con IPv4, IPv6, número de teléfono, código postal, SSN, etc.) con una interfaz de usuario rica (como demostró @mdtauk) y reemplazando / mejorando TextBoxMask del Community Toolkit (https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask)

@rudyhuyn Estoy mayormente de acuerdo con lo que acaba de decir aquí, y mis ilustraciones fueron para la especificación propuesta.

Pero como han mencionado otros, un cuadro de texto enmascarado no necesita limitarse solo a números, y también podría incluir cadenas. El cuadro Clave de producto de Microsoft es un buen ejemplo, donde se aceptan 5 conjuntos de caracteres 0-9 AZ.

Incluso si se separó Masking, sigo pensando que hay buenos casos de uso para incluir las propiedades PrefixText y SuffixText en el control NumberBox. Moneda, Medidas, todas requieren algún tipo de contexto.

Los botones de giro son puramente para incrementar y disminuir valores, por lo que también están dentro del alcance de un control NumberBox.

El prefijo y el sufijo podrían convertirse en propiedades del propio control TextBox y, por lo tanto, heredadas por los otros controles. (Es posible que deba haber una excepción para PasswordBox si abre alguna vulnerabilidad)

Las máscaras para valores comunes podrían ser una enumeración (junto con CustomFormatMask) para este control separado. Algunas de estas máscaras pueden implicar un contexto cultural, como un código postal del Reino Unido que es alfanumérico y los números de la seguridad social del Reino Unido siguen un formato especial, etc.

SW1A 2AA

Ejemplo de código postal del Reino Unido (para el número 10 de Downing Street)

Parece que no logré actualizar la página esta mañana antes de enviar mi respuesta ... ¡Gracias a todos ustedes, estrellas de

@mdtauk : tus maquetas son fantásticas. Todavía no había redactado diseños de prototipos para este control. ¿Puedo dividir su maqueta y agregarlos a la especificación como prototipos para que nuestros diseñadores comiencen su paleta? Me comunicaré con un diseñador hoy mismo y veré si puedo conseguir que responda a tu hilo con @mrlacey aquí. Leeré su hilo y responderé con más detalles en breve.

@sonnemaf , ¡gracias de nuevo! Le animo a que copie su comentario y lo vuelva a publicar aquí, en la pestaña de conversación de Pull Request . Aquí es donde nuestro equipo de ingeniería comenzará a participar a nivel de API y de implementación. En aras de dar una respuesta completa, aquí es también donde comienzo a redactar las pautas y la documentación. Prefacio se compromete con [DEV] para el primero y [PM] para el segundo. De lo contrario, este sigue siendo el foro adecuado para la discusión de requisitos de alto nivel (como la calculadora incorporada y las maquetas de @mdtauk ).

@mdtauk : Estoy de acuerdo contigo, un Prefijo / Sufijo sería una buena adición a TextBox y no se limita a números, algunos ejemplos:

• pedirle a un empleado que ingrese su dirección de correo electrónico cuando el dominio sea siempre el mismo (@ microsoft.com, por ejemplo).
• ingrese el nombre de un formulario cuando siempre comience con W-

etc ...

¡Debería abrir otro boleto para que podamos comenzar una discusión al respecto!

@rudyhuyn, ¿
Mi idea es que si comienza a restringir algunas cosas pero no otras, las reglas para lo que se cubre deben definirse muy claramente.
El simple hecho de admitir valores que pueden aparecer como un número entero, flotante, etc. aclara las cosas y aún crea un control que proporciona mucho valor.

@SavoySchuler Mis diseños están completamente a su disposición, los

@rudyhuyn Si

@mrlacey Los números de teléfono (aparte de los caracteres de formato) son números puros, pero no se incluyen en ningún tipo de caso de uso de cálculo, por lo que ¿se ajusta mejor a un TextBox enmascarado, o hay valor en brindar soporte para estos en un NumberBox?

Al crear el control y la documentación, proporcionar un caso de uso claro y ejemplos para qué control usar en qué contexto es importante.

@mrlacey : No lo sé.

Como dijiste antes, debemos separar los números reales, no solo algo que use 0-9 caracteres sino que esté asociado a un valor aritmético.

Una dirección IP, número de teléfono, SSN, código postal usan 0-9 caracteres pero no tienen valores aritméticos (puede agregar 2 de ellos, si agrega ".00" al final, cambia el significado del valor, etc.) . En estos casos, el valor es una cadena, no un int / double, un MaskedTextBox tendría más sentido.

Además, un código postal solo usa dígitos en los EE. UU., Pero no en Canadá, por ejemplo, una dirección IPv6 puede contener caracteres AF, un número de teléfono puede contener un signo + (555-123-4567 y + 555-123-4567 son 2 diferentes números de teléfono), etc ...

Para resumir mi opinión, NumberBox.Value debe ser un doble, no una cadena.

@mrlacey Los números de teléfono (aparte de los caracteres de formato) son números puros, pero no se incluyen en ningún tipo de caso de uso de cálculo, por lo que ¿se ajusta mejor a un TextBox enmascarado, o hay valor en brindar soporte para estos en un NumberBox?

Los números de teléfono pueden estar compuestos enteramente por dígitos (más formato) pero eso no los convierte en números. No puedes hacer ningún tipo de operación aritmética en ellos y obtener algo significativo.
Además, algunos pueden comenzar con un signo más.
Además, el número de ceros a la izquierda en un número de teléfono es significativo. Para un valor numérico no lo es.
La otra funcionalidad del control, como los cálculos o los botones arriba y abajo, no tiene ningún sentido para un "número de teléfono".

Este control debe limitarse a valores que se puedan convertir a int / uint o decimal sin riesgo de perder información.

Para asegurarme de que estoy sintetizando esta retroalimentación de manera apropiada, por favor, déme un pulgar hacia arriba en este comentario si cree que este es el mejor lugar para todos los tipos de entrada de cadenas numéricas (como números de teléfono e IPv4) a través de tipos de formato y un pulgar- abajo si esa funcionalidad debe ser transferida a otro control o nuevo para que NumberBox se enfoque exclusivamente en la captura de valores matemáticos y matemáticos. (Tenga en cuenta que las funciones que admiten operaciones matemáticas, como el modo de calculadora y los botones Arriba / Abajo, requieren la habilitación a través de las respectivas API).

No puedo garantizar que esto se decida democráticamente, ya que tomaré la decisión que resulte en el mejor retorno de la inversión para nuestros clientes en todo el mundo, pero ayudará a validar lo que creo que veo aquí: nadie que pida esto para respaldar los valores numéricos. cadenas y preferiría un control dedicado para eso.

@SavoySchuler Números sobre los que se puede operar, aumentar y disminuir, así como prefijos y sufijos que agregan contexto y significado al valor.

Acabo de sincronizarme con el equipo aquí y quería compartir actualizaciones sobre algunas de nuestras preguntas abiertas:

• Estamos escuchando sus comentarios y estamos de acuerdo en que NumberBox no es el lugar adecuado para cadenas numéricas. Las propiedades FormatKinds y CustomFormat se han reemplazado con API más específicas para controlar el formato numérico de formas más intuitivas que.
• El prefijo y el sufijo realmente pertenecen al TextBox (del cual NumberBox los heredará). Le daré a @mdtauk , @mrlacey o cualquier otra persona unos días de iniciaré y la vincularé aquí. Por el momento, eso evitará que NumberBox se bloquee en la salida de localización / automatización.
• La alimentación final en un NumberBox (después del cálculo, redondeo, etc.) se conservará como una Cadena en la propiedad Text que proviene de TextBox Y como un Double en una nueva propiedad Value. Tenemos la intención de tener estos comentarios entre nosotros para que la alteración de uno se refleje en el otro. El propósito de esto es quitarle la mayor cantidad de trabajo posible y tener el valor listo para acceder cuando lo necesite.
• StepSize faltaba como propiedad en la especificación.
• Los tipos de enteros se cambiarán a Double.
• Todavía estamos entusiasmados con la idea de una calculadora integrada y estamos buscando más escenarios que nos ayuden a refinar eso. @mdtauk , ¡gracias por responder ya a este punto de retroalimentación!
• Con respecto a la validación de entrada, la idea es enviar primero un tipo de evento ValueChanged que le dará al desarrollador la oportunidad de manipular la entrada o manejarla en su envío de formulario final / bloque según sea necesario. Si no se toma ninguna acción correctiva (como forzarlo dentro de mínimo / máximo, eliminar caracteres no válidos, etc.), NumberBox mostrará una indicación de error al usuario sobre su entrada. Este enfoque doble permite a los desarrolladores responder si lo prefieren, pero también permite que la corrección se difiera al usuario.

Ha habido una gran cantidad de comentarios a los que todavía estoy respondiendo. Gracias por su paciencia, responderé a todos aquí y también en el repositorio de especificaciones.

"Arte conceptual de NumberBox con una calculadora incorporada". Comunidad WinUI, mayo de 2019 (coloreada)

( Elogio de

@SavoySchuler Solicitó algunos ejemplos de escenarios en los que se podrían usar los tipos de control que estamos discutiendo. Tengo dos en mi aplicación que pueden ser buenos ejemplos.

Caso 1: Existe un editor de configuración para gráficos 2D donde puede ajustar el eje.

• Esto solo necesita una entrada numérica simple y básica. Los botones de incremento +/- serían útiles aquí.
• Un valor doble estaría bien, pero las entradas deben validarse al presionar el carácter. El usuario nunca debería poder presionar 'a' y hacer que aparezca en el cuadro de entrada. La validación de entrada no debe hacer que el borde sea rojo y dar una advertencia al usuario, simplemente no debería ser posible ingresar un valor no válido.
• La localización tendría que ser compatible con el control y mover el lugar decimal (ya sea coma, punto, etc.) manejado como un caso especial (sigo mencionando esto porque es fácil pasarlo por alto)

Caso 2: Hay un campo de entrada para un valor de moneda como se muestra a continuación. Este es un control personalizado "CurrencyBox"

• Esto podría usar un botón de calculadora y la capacidad de ingresar ecuaciones 2 + 3 tendría algún valor aquí (aunque todavía siento que esto debería ser un control separado)
• Un valor doble NO es ideal para esto. Sugeriría cambiar la especificación de Valor de doble a decimal para admitir este tipo de caso de uso . De lo contrario, depende del desarrollador analizar el texto de la cadena.
• Aquí hay un caso especial en el que el signo negativo se maneja por separado. Eso hace que sea mucho más fácil para el usuario no cometer un error al firmar. Sin embargo, en realidad no espero que NumberBox lo admita de inmediato.
• Es importante establecer la alineación del texto y un prefijo / sufijo sería extremadamente útil para mostrar un símbolo de moneda (la localización aún podría ser un problema para saber si mostrar el símbolo a la derecha oa la izquierda; sin embargo, la aplicación en sí podría tener esa lógica)
• El usuario puede ingresar un valor local o extranjero. NumberFormatInfo y CultureInfo para ambos valores PUEDEN diferir de la referencia cultural de la interfaz de usuario. Por lo tanto, para la localización, el control debe admitir la sustitución de un NumberFormatInfo personalizado.

En este momento, en la aplicación, Windows Community Toolkit se usa para ambos casos con propiedades adjuntas al TextBox como se muestra a continuación:
TextBoxRegex.ValidationMode = "Dinámico"
TextBoxRegex.ValidationType = "Decimal"

Algunos comentarios finales (¡lo siento, esto es tan largo!)

• Creo que estamos discutiendo potencialmente 3 controles diferentes aquí. Un NumberBox de barras, un CalculatorBox que puede tener ecuaciones y entrada numérica avanzada (¡botón de Calculadora!), Y finalmente un MaskedTextBox para entrada no numérica como números de teléfono y direcciones IP. No debemos confundirlos y acordar cómo dividir estos conceptos es clave para avanzar con la especificación.
• No podemos perder el enfoque del caso de uso más básico y posiblemente más útil: un cuadro de texto de aspecto normal con nada más que filtrado de entrada, por lo que solo se puede ingresar un número válido. Todas las demás opciones deberían poder desactivarse (estoy pensando en los botones de incremento +/-)
• Todavía sugiero cambiar de doble a decimal en la especificación para capturar la precisión decimal con precisión en el valor analizado. Además, probablemente deberíamos considerar la entrada de números enteros diferente de la entrada de números racionales. Esa es probablemente una nueva propiedad en la API "IsInteger = true" para cambiar el valor decimal predeterminado.

Editar: Se eliminó la idea de cambiar de doble a decimal para el tipo NumberBox.Value. Me equivoqué al asumir que esto existe en el mundo de C ++ WinRT. No es así y, en cambio, solo está en .net core / framework.

@robloo , sobre ese comentario final, no hay un tipo decimal en WinRT.

El depurador de árbol visual de XAML Toolkit es una herramienta que se basa en gran medida en el control NumericUpDown del kit de herramientas, donde incrementar / disminuir arrastrando el mouse, los botones y el teclado son todos importantes. La entrada de la calculadora también puede ayudar:

@robloo y @xyzzer , ¡este es exactamente el tipo de información que estoy buscando!

Validación / Enmascaramiento

@robloo , estoy particularmente interesado en el Caso 1: Bullet 2 - validación vs enmascaramiento. Hablemos del escenario de "entrada incorrecta" a partir de ahora:

• Un nuevo usuario escribe "dos" en su NumberBox.
• El NumberBox genera el evento "ValueChanged" que le da la oportunidad de devolver la entrada no numérica a "0" - o de otra manera - si así lo desea. Si no se toma ninguna medida, entonces ...
• La validación se activa en NumberBox se ilumina en rojo y muestra un mensaje de error al usuario que le informa que solo se permite la entrada numérica (esta parte aún no se ha racionalizado por completo, por lo que esto es solo una hipótesis).

¿Esta serie de eventos te da la posibilidad de crear la experiencia que necesitas crear?

Entiendo que el enmascaramiento podría ser un valor predeterminado deseable, pero permítanme compartir lo que mi equipo discutió la semana pasada: aterrizamos en la dirección en la que se prefiere la validación (indicador / mensaje de error) en los controles Fluent como alternativa, el enmascaramiento, puede ser frustrante y confuso para los usuarios finales cuando no experimentan salida de su entrada de teclado. Otra forma de pensarlo es que la validación ofrece un nivel de transparencia e información al usuario que lo hace más consciente de la experiencia en lugar de ser coaccionado silenciosamente. Por lo tanto, nuestro curso de acción actual fue incorporar la validación básica sin bloquear la oportunidad para que el desarrollador agregue validación avanzada (próximamente en TextBox) o enmascaramiento a través del evento ValueChanged según sea necesario. Para comprender, esto es lo suficientemente flexible como para permitir que se satisfagan todas las necesidades y, al mismo tiempo, brindar la experiencia recomendada como predeterminada.

¿Qué piensas aquí? Me interesaría cualquier idea que tenga para comprender mejor estos conceptos o crear una experiencia aún mejor, si podemos.

Formato de valor

A sus otros puntos, @robloo , he agregado una propiedad de precisión DecimalPrecision a Spec . Al establecer esto = "0" se obtendrán números enteros. Además, establecer MinValue = "0" puede ayudar a mantener los números no negativos (o el evento ValueChanged es otra oportunidad para forzar la entrada a valores absolutos).

¿Has revisado las especificaciones todavía? Creo que he incluido todas las propiedades necesarias para permitir sus experiencias por completo (pendiente de la validación frente a la discusión de enmascaramiento) pero estoy ansioso por saber si cree que me he perdido algo.

enmascaramiento, puede ser frustrante y confuso para los usuarios finales cuando no experimentan salida de su entrada de teclado.

100% de acuerdo, sí. Lo mejor que puede hacer es validar en LosingFocus / EnterPressed y restaurar el oldValue si el valor escrito no se valida, por lo que sería perfecto tener una señal que se activa en LosingFocus / EnterPressed y contiene oldValue / newValue.

@adrientetar , gran punto! ¿Es esa una experiencia que necesitas crear? Si es así, veré qué tenemos que hacer para que el evento ValueChanged envíe tanto el valor anterior como el nuevo.

@SavoySchuler Es algo que quiero hacer en mi aplicación, de hecho, construiría ese comportamiento yo mismo a menos que el control lo haga de forma predeterminada.

La otra cosa que me gustaría es Shift + ↑ / ↓ para incrementos de 10 y Ctrl + Shift + ↑ / ↓ para incrementos de 100, aunque creo que los incrementos de 100 no siempre tienen sentido.

¡Gran punto! Debemos asegurarnos de que el control se derive de RangeBase que
define tanto SmallChange como LargeChange y que usamos ambos en
lo mínimo.
¿Existe un ejemplo de combinaciones de teclado estándar para utilizar para invocar
gran cambio en RangeBase de UWP o WinForms / ComCtl (?) NumericUpDown?

El lunes 3 de junio de 2019 a las 3:50 p.m. Adrien Tétar [email protected]
escribió:

@SavoySchuler https://github.com/SavoySchuler Es algo que quiero
hacer en mi aplicación, construiría ese comportamiento yo mismo a menos que el control lo haga
por defecto.

La otra cosa que me gustaría es Shift + ↑ / ↓ para incrementos de 10 y
Ctrl + Shift + ↑ / ↓ para incrementos de 100, aunque calculo incrementos de 100
no siempre tiene sentido tener.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMFZBHJIE4DR2KN46TTPYWN3BA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVODBXWJWKNM492HS4DFVODBXG43V2
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AANMBMG4AWBK44VE4O4GYR3PYWN3BANCNFSM4HA4PBNA
.

Lo comprobaré para verificar, pero estoy bastante seguro de que los atajos de teclado tendrán que dejarse en manos de las aplicaciones para que los implementen. Intenté esto con la justificación de accesibilidad para el n. ° 21 e introducir nuevos atajos de teclado es un juego arriesgado, ya que casi todos los que no fueron reclamados por Windows ahora se han tomado en el nivel de la aplicación (dicho esto, TeachingTip pudo saltar el tren F6), ¡pero comprobaré si el enfoque de control permite alguna excepción aquí!

La compilación 2018 fue cuando se anunciaron los estados de validación para los controles TextBox, utilizando INotifyDataErrorInfo.
Sería bueno usarlo con enmascaramiento para validar o invalidar la cadena de texto actual.

EDITAR: El uso del icono y el color del borde inferior más grueso es para ayudar al reconocimiento en situaciones daltónicas y cuando se mira en blanco y negro. El texto de error inferior se puede hacer como información sobre herramientas en el icono si el espacio es escaso.

@mdtauk , eres fenomenal en estos

@SavoySchuler Fácil extrapolación basada en el ejemplo que se muestra en Build 2018

Y hay muchos ejemplos para ver :)

¡Disculpas, este es otro largo!

@SavoySchuler @adrientetar Definitivamente veo de dónde viene con sus declaraciones a continuación. No voy a argumentar que en la gran mayoría de los casos es la mejor manera de manejar la validación. Sin embargo, tengo que pensar que hay algunos casos especiales en los que es tan obviamente una entrada numérica que en realidad le está haciendo un favor al usuario al no permitirle que se equivoque con el dedo.

enmascaramiento, puede ser frustrante y confuso para los usuarios finales cuando no experimentan salida de su entrada de teclado.

100% de acuerdo, sí. Lo mejor que puede hacer es validar en LosingFocus / EnterPressed y restaurar el oldValue si el valor escrito no se valida, por lo que sería perfecto tener una señal que se activa en LosingFocus / EnterPressed y contiene oldValue / newValue.

Sin embargo, decidí hurgar en otras aplicaciones para ver cómo se maneja. No creo que nadie investigue más que Microsoft sobre la interacción del usuario, así que busqué la versión de escritorio de 64 bits de Word y luego la versión para UWP de OneNote como referencia. Está más o menos completamente de acuerdo con lo que están diciendo. Puedo escribir cualquier texto en los cuadros de entrada de tamaño de fuente o tamaño de forma, que claramente son solo entradas numéricas. Valida en gran medida la pérdida de enfoque y vuelve a la última entrada válida.

| Título | Pic | Comentar |
| ------ | ----- | ------------ |
| Entrada de tamaño de fuente para UWP OneNote | | Cualquier valor se puede ingresar desde el teclado, se valida automáticamente y se restablece al último valor válido en caso de pérdida de foco |
| Entrada de tamaño de fuente de Word de escritorio | | Se puede ingresar cualquier valor desde el teclado, se valida automáticamente en caso de pérdida de enfoque y aparece un mensaje de error si no es válido. Al hacer clic en [Aceptar] se restablece el último valor válido. |
| Gráfico 2D de UWP OneNote | | Cualquier valor se puede ingresar desde el teclado. Los valores no válidos simplemente se ignorarán y la última entrada válida se utilizará en el cálculo (no se valida en caso de pérdida de foco). Al presionar los botones de incremento +/- se incrementará usando la última entrada válida. |
| Entrada de tamaño de forma de palabra de escritorio | | Cualquier valor se puede ingresar desde el teclado, se valida automáticamente en caso de pérdida de enfoque y se restablece al último valor válido en caso de pérdida de enfoque. |

Así que supongo que demostré que estaba equivocado, lo que significa que debería estar de acuerdo contigo.

Comentarios secundarios:

• Como mencionó anteriormente otra persona, cuando NumberBox tiene el enfoque del teclado con un teclado táctil / virtual, solo se debe mostrar el teclado numérico.
• El incremento hacia abajo a la izquierda y el incremento hacia arriba a la derecha es una idea interesante para discutir aquí en términos de estilo. ¡Me gusta esto!
  

• Un nuevo usuario escribe "dos" en su NumberBox.
• El NumberBox genera el evento "ValueChanged" que le da la oportunidad de devolver la entrada no numérica a "0" - o de otra manera - si así lo desea. Si no se toma ninguna medida, entonces ...
• La validación se activa en NumberBox se ilumina en rojo y muestra un mensaje de error al usuario que le informa que solo se permite la entrada numérica (esta parte aún no se ha racionalizado por completo, por lo que esto es solo una hipótesis).
  ¿Esta serie de eventos te da la posibilidad de crear la experiencia que necesitas crear?
  ¿Qué piensas aquí? Me interesaría cualquier idea que tenga para comprender mejor estos conceptos o crear una experiencia aún mejor, si podemos.

Entiendo totalmente y estoy de acuerdo en que agregar validación de entrada es excelente para la plataforma en general. Sin embargo, básicamente solo describió la validación de entrada sin un manejo especial para un número. Por lo tanto, ¿de qué sirve un NumberBox además de analizar automáticamente un valor? Como desarrollador, parece que un TextBox con validación de datos es más o menos lo mismo.

Creo que, según mis ejemplos anteriores, la funcionalidad lista para usar debería ser una combinación de nuestras dos ideas y eso es lo que dice @adrientetar . El usuario puede escribir cualquier valor para obtener la retroalimentación visual. Sin embargo, en el enfoque de pérdida, el valor se valida automáticamente y el número válido anterior (o vacío) se revierte automáticamente. Esto le ahorra al desarrollador la molestia de tener que manejar la validación de entrada nosotros mismos (ya sabemos que debería ser un Número en el NumberBox). También se diferencia claramente de un TextBox con validación de datos.

En términos de eventos, aún me gustaría tener la oportunidad de cancelar los cambios de texto si alguna vez ese caso de uso se vuelve más claro. Por lo tanto, además de ValueChanged, recomendaría un evento ValueChanging y TextChanging para permitir que la entrada se compare y cancele. Definitivamente, se necesitan un OldValue y NewValue independientemente, esto al menos nos permitiría cambiarlo rápidamente a OldValue si es necesario (aunque a UWP le gusta fallar cuando modifica TextValue dentro de un evento).

Con respecto a la especificación: Buenas ideas con DecimalPrecision, necesitaré más tiempo para revisarlo y agregar mis comentarios. Hay muchos pequeños matices, como el valor predeterminado debería ser Cadena = Vacío, Valor = Nulo y cuando se presiona un botón de incremento +/-, el valor debe tratarse como cero en lugar de vacío.

@mdtauk No debería ser humanamente posible hacer tan buenas ilustraciones tan rápido :)

@robloo Gracias por el amable comentario. Solo tengo un comentario rápido que hacer con respecto a su +/−
Puede ser mejor seguir con los símbolos Arriba y Abajo que se usan en los botones de giro actuales, para evitar confusiones con las operaciones matemáticas que este NumberBox puede realizar.

iOS usa un control "paso a paso", pero la entrada de texto es independiente y no hay cálculo en línea.

Aquí hay algunos diseños más que encontré.

El diseño que elegí parece encajar con el estilo típico de Microsoft para este control, pero ¿es la mejor opción o la opción correcta? Me interesaría escuchar lo que otros piensan de él.

EDITAR: Se agregaron algunas maquetas de formas alternativas (pero creo que la primera idea es la mejor ...)

Estoy de acuerdo con @mdtauk en la ubicación +/-, la primera es la mejor.

Existe una ControlTemplate XAML para que el usuario (desarrollador) siempre pueda crear una plantilla personalizada para los otros dos diseños.

@robloo , no es necesario que se disculpe por las respuestas detalladas, ¡especialmente cuando tienen algunas buenas risas! Excelente idea con el teclado táctil / virtual: lo agregué a la sección Preguntas abiertas en la especificación para que lo ejecuten los desarrolladores / equipo y me asegure de que no haya una sobrecarga de rendimiento inaceptable al hacerlo. Creo que sería una gran comodidad para los usuarios si pudiéramos hacerlo realidad.

Mencionas un gran punto sobre la validación ...

[1] Turno de preguntas: ¿Alguien estaría en contra de un sistema de validación que revierte automáticamente la entrada inaceptable al valor anterior mientras expone eventos que permitirían al desarrollador cancelar este comportamiento y en su lugar decidir qué hacer / generar indicadores o mensajes de error?

Visualmente, veo el mérito de los UpDownButtons disjuntos en el ejemplo que publicaste. Creo que @mdtauk y @sonnemaf están en el camino correcto por defecto. La proximidad de los UpDownButtons es su verdadera conveniencia, ya sea que se esté probando el resultado de ida y vuelta de una entrada diferente (pero no distante) o corrigiendo la entrada sobrepasada. La distancia, a menos que se requiera por un diseño o funcionalidad mejorados, parecería agregar trabajo evitable a la experiencia y también podría comprometer la claridad con las propiedades / etiquetado de Prefijos / Sufijos en oposición a agrupar esto claramente como parte funcional del control, por ejemplo: $ [-] 192 [+]

Creo que hay escenarios para los UpDownButtons inconexos. Mi mente se concentra en tareas que esperan una entrada mínima y unidireccional o en aquellas en las que el desarrollador busca hacer que los errores de entrada sean más difíciles de cometer. Creo que esta es la experiencia que ofrecen varias aplicaciones y sitios web cuando, por ejemplo, uno está comprando entradas para una película o un concierto.

Mi pregunta entonces es ...

[2] Tiempo de preguntas: ¿Deberíamos confiar en Xaml ControlTemplate para crear un NumberBox con UpDownButtons disjuntos (es decir, esto no es lo suficientemente común como para justificar el soporte de fábrica) o deberíamos incluir una propiedad para establecer si los UpDownButtons aparecen contiguos vs. disjunto?

Haré ping a @chigy para esta pregunta, ya que las pautas del

Debo incluir consideraciones de accesibilidad para la conversación UpDownButtons: la proximidad de los UpDownButtons entre sí permite la claridad conceptual para los usuarios de Narrador / lector de pantalla al tiempo que mantiene la eficiencia de navegación para los usuarios de navegación con teclado y también es importante no comprometer esto.

Si el control no es muy ancho, querrá que las flechas se apilen verticalmente (sé que lo necesito en mi aplicación). ¿Quizás el control podría responder a su ancho establecido? Eso depende de las pautas de diseño fluidas para especificarlo de esa manera si creen que tiene sentido.

He actualizado la propuesta con nuestras 3 preguntas abiertas.

¡Gracias @mdtauk por los diseños conceptuales!

@adrientetar Me alegra que lo hayas señalado como una necesidad. ¿Parece que tal vez necesitemos una enumeración para estas tres configuraciones?

Si el control no es muy ancho, querrá que las flechas se apilen verticalmente (sé que lo necesito en mi aplicación). ¿Quizás el control podría responder a su ancho establecido? Eso depende de las pautas de diseño fluidas para especificarlo de esa manera si creen que tiene sentido.

Hubo una propuesta para permitir que los controles sean conscientes y respondan a la cantidad de espacio que tienen disponible para ellos. # 677 Esto podría usarse para reposicionar los botones de giro a medida que el control se vuelve más estrecho. Tal vez sea necesario que haya una propiedad para NarrowWidth similar a MinWidth, o tal vez incluso un NumberOfDigits para que actúe como una pista.

Con respecto al ejemplo de texto en gris, me preocupa que esto pueda alentar al usuario a completar los valores que aparecen, en lugar de actuar como una pista sobre cuál será el resultado final. Se parece a PlaceholderText.

¿Qué hay de usar AccentColor y diferentes pesos de fuente para que se destaque?

Gran enlace, @mdtauk. Me imagino que si este es un camino por el que vamos, podríamos manejar esto con una enumeración que tenga valores como [Auto, Vertical, Horizontal, Detached] donde Auto preferirá Horizontal hasta que la compacidad exija Vertical. ¿Pensamientos?

Además, ¡he actualizado la imagen! Creo que tiene razón en que el texto en gris podría verse como un mensaje, que si se sigue, daría como resultado un error debido al "=".

Gran enlace, @mdtauk. Me imagino que si este es un camino por el que vamos, podríamos manejar esto con una enumeración que tenga valores como [Auto, Vertical, Horizontal, Detached] donde Auto preferirá Horizontal hasta que la compacidad exija Vertical. ¿Pensamientos?

Un pensamiento inicial es, ¿será el número en el contenedor lo suficientemente grande como para necesitar una orientación vertical? AutoCompleteBox no mueve su botón de búsqueda y las cadenas suelen ser más largas que los números.

Si se trata de algo que depende exclusivamente del espacio disponible, un comportamiento de respuesta automática (si se da el visto bueno a esa propuesta) sería mejor que una enumeración. Dar a los desarrolladores la opción en el control en sí podría conducir a un uso menos consistente del control, pero creo que esto debería ser algo que la investigación del usuario debería considerar, creo, en lugar de prescrito por nosotros solos en github.

Los desarrolladores siempre tienen la opción de replantear el control si _realmente_ necesitan un diseño diferente para el control, y es posible incluir un Estilo alternativo para eso si desea A) hacer el esfuerzo de hacer tanto el predeterminado como el Estilo vertical y plantillas, y B) garantizan que ambos estilos se prueben correctamente.

@mdtauk Estoy de acuerdo en que los símbolos arriba / abajo son los mejores. Solo quería mostrar un ejemplo con las flechas en lados opuestos de la entrada. Como se mencionó anteriormente, esto ayuda a garantizar que el usuario no presione el incorrecto, lo cual es casi obligatorio en una interfaz de usuario táctil. El ejemplo que di de OneNote tenía +/- símbolos, pero debería haber agregado para ignorar los símbolos en sí.

@SaboyaSchuler

[2] Tiempo de preguntas: ¿Deberíamos confiar en Xaml ControlTemplate para crear un NumberBox con UpDownButtons disjuntos (es decir, esto no es lo suficientemente común como para justificar el soporte de fábrica) o deberíamos incluir una propiedad para establecer si los UpDownButtons aparecen contiguos vs. disjunto?

Sé que cuando se creó UWP por primera vez, fue táctil primero, por lo tanto, UpDownButtons inconexos sería posiblemente mejor. Desde entonces, los requisitos de tocar primero se han relajado y, sin duda, los botones uno al lado del otro son mejores cuando el usuario tiene un método de entrada preciso, como un mouse (menor distancia de recorrido). Dado que esto depende del caso de uso, estoy de acuerdo en que una enumeración es útil para especificar cómo deberían aparecer los UpDownButtons.

Para los valores de enumeración, hemos discutido varios estados y generalizando podemos agregar algunos más:

• SeparatedHorizontal: flecha hacia abajo a la izquierda, flecha hacia arriba a la derecha
• SeparatedVertical: flecha hacia abajo en la parte inferior, flecha hacia arriba en la parte superior
• Izquierda: flechas hacia abajo y hacia arriba una al lado de la otra a la izquierda (en una orientación horizontal)
• Derecha: flechas hacia abajo y hacia arriba una al lado de la otra a la derecha (en una orientación horizontal)
• Arriba: flechas hacia abajo y hacia arriba una al lado de la otra en la parte superior (en una orientación vertical)
• Abajo: flechas hacia abajo y hacia arriba una al lado de la otra en la parte inferior (en una orientación vertical)

Si todo esto se vuelve demasiado complejo (como lo es rápidamente), me complace volver a crear la plantilla del control para mis propios casos de uso en XAML.

Solo para arrojar otra idea: cambiar la orientación del símbolo para UpDownButtons inconexos también podría tener algún sentido [<] 123 [>]. Sin embargo, siéntase libre de ignorar esta complejidad adicional, ya que ciertamente podría rediseñarse por aplicación.

Además, es posible que algunas de las preocupaciones de accesibilidad ya se hayan abordado en OneNote, que es de donde saqué el ejemplo.

@robloo Creo que las ubicaciones izquierda y derecha que mencionas deben mantenerse para la localización RtL y LtR, en lugar de configuraciones discretas.

Abajo están mis opiniones

Tampoco estoy seguro de que colocar los botones encima del campo de texto tenga sentido semánticamente, y mucho menos cuando está poniendo el dedo en el botón, puede dificultar que el número cambie.

Tener todas las combinaciones integradas en el control conducirá a un uso caótico, y todas esas cosas se pueden hacer con una nueva plantilla si hay una necesidad urgente.

Los botones debajo del campo de texto pueden tener algún uso en áreas de espacio reducido y como una opción en el control mismo, ya que hace que los botones sean mucho más grandes para tocar. Ya sea como un estilo incluido con el control o una enumeración entre:

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

Solo una sugerencia posible de una pregunta rápida: En teoría, en un cuadro numérico uno solo debería poder ingresar números en un cuadro numérico. ¿Qué tan difícil sería analizar los números escritos y traducirlos a números reales para estos campos?

Por ejemplo:
uno + dos = 3
traduce
1 + 2 = 3

O
uno más dos es igual a tres
se traduce en
1 + 2 = 3

Es solo una idea.

Solo una sugerencia posible de una pregunta rápida: En teoría, en un cuadro numérico uno solo debería poder ingresar números en un cuadro numérico. ¿Qué tan difícil sería analizar los números escritos y traducirlos a números reales para estos campos?

Por ejemplo:
uno + dos = 3
traduce
1 + 2 = 3

O
uno más dos es igual a tres
se traduce en
1 + 2 = 3

Es solo una idea.

Eso tiene sentido para el inglés. Se convierte en un problema cuando necesita traducir y analizar esas cadenas para otros idiomas. ¿Y qué pasa con un usuario polaco que escribe palabras en inglés?

Tal como está ahora, solo se ha discutido la forma de los números 0-9, decimales, separadores de números y operadores matemáticos. Pero es posible que deban adaptarse otros sistemas numéricos.

Agregar traducciones de idiomas será un gran esfuerzo y no está claro cuál será el beneficio.

Ahora bien, si este control fuera manipulado por la entrada de audio, por lo tanto, decir el número o la operación, eso puede implicar la interpretación del idioma que se está hablando.

NARRADOR:
"Pixels NumberBox sin valor"

USUARIO:
"Ciento veintiocho píxeles"

[128 _________ | px]

USUARIO:
"Agregar sesenta y cuatro píxeles"

[192 _________ | px]

NARRADOR:
"Ciento noventa y dos píxeles"

[1] Turno de preguntas: ¿Alguien estaría en contra de un sistema de validación que revierte automáticamente la entrada inaceptable al valor anterior mientras expone eventos que permitirían al desarrollador cancelar este comportamiento y en su lugar decidir qué hacer / generar indicadores o mensajes de error?

Si el texto ingresado valor a algo más antiguo? No creo que tratar de mantener un "último conocimiento bueno Value " sea algo de lo que el control deba ser responsable. Deje que el control maneje un solo valor actual (o estado de error) y deje que la aplicación se encargue de cualquier procesamiento histórico adicional según sea necesario a través del evento ValueChanged .

Para la versión inicial, creo que estará bien con solo admitir una sola posición de los botones Arriba / Abajo, ya que se pueden volver a crear una plantilla si es necesario.
Si la capacidad de determinar la posición de los botones Arriba / Abajo se considera una necesidad, cualquier enumeración que se agregue debería eliminar la necesidad de tener la propiedad UpDownButtonsEnabled y un valor de enumeración de Hidden podría ser añadido en su lugar.
Tenga en cuenta también que tener soporte integrado para manipular la posición de los botones Arriba / Abajo agregará complejidad para cualquiera que necesite ajustar las plantillas para cualquier otra opción que no sea la provista.

@shaheedmalik , y una idea excelente e intuitiva. ¿Ha revisado las especificaciones? Tenemos un evento ValueChanged que le permitiría interceptar esa entrada y analizar manualmente los números escritos en valores numéricos, por lo que sería una posible experiencia de crear, especialmente si tiene un idioma específico en mente. En cuanto a hornear un analizador de idioma global en la V1 predeterminada del control, @mdtauk tiene razón, agregaría complejidad y gastos generales que necesitarían una justificación significativa. Un beneficio de la fuente abierta de estos controles es que la comunidad podría bifurcarlos. En este caso, usted u otros miembros de la comunidad podrían crear variantes específicas de idioma de este control. Creo que ese sería el camino más realista para democratizar una versión de análisis de idiomas de NumberBox.

@mrlacey, ¿ha tenido la oportunidad de revisar @robloo 's análisis comparativo de NumberBox control similar del utilizado a lo largo de Windows ? El comportamiento de restablecer estos campos a la última entrada válida, solo numérica, en realidad tiene un precedente en todo el sistema, lo que significa que se presionaría el control en sí o las pautas del desarrollador para alinearse con este patrón. Mi inclinación sería alinear este control de manera coherente con la experiencia estándar de Windows y crear una vía para la desviación necesaria en lugar de estandarizar un comportamiento que se desvía del resto del ecosistema y afirmar pautas para crear este comportamiento predeterminado del sistema como lo crearía este último. fácil y eficiente para el caso común. Animo el desacuerdo, así que hágamelo saber si cree que esto agrega una complejidad innecesaria al control o, tal vez, tal vez deberíamos reevaluar este precedente.

| Título | Pic | Comentar |
| ------ | ----- | ------------ |
| Entrada de tamaño de fuente para UWP OneNote | | Cualquier valor se puede ingresar desde el teclado, se valida automáticamente y se restablece al último valor válido en caso de pérdida de foco |
| Entrada de tamaño de fuente de Word de escritorio | | Se puede ingresar cualquier valor desde el teclado, se valida automáticamente en caso de pérdida de enfoque y aparece un mensaje de error si no es válido. Al hacer clic en [Aceptar] se restablece el último valor válido. |
| Gráfico 2D de UWP OneNote | | Cualquier valor se puede ingresar desde el teclado. Los valores no válidos simplemente se ignorarán y la última entrada válida se utilizará en el cálculo (no se valida en caso de pérdida de foco). Al presionar los botones de incremento +/- se incrementará usando la última entrada válida. |
| Entrada de tamaño de forma de palabra de escritorio | | Cualquier valor se puede ingresar desde el teclado, se valida automáticamente en caso de pérdida de enfoque y se restablece al último valor válido en caso de pérdida de enfoque. |

@mdtauk , teniendo en cuenta su comentario sobre los idiomas LTR y RTL y el lado del control en el que aparecen UpDownButtons. Lo ejecutarán expertos en localización para asegurarme de que sea una consideración que se tenga en cuenta.

@mrlacey también tiene razón en que el booleano sería redundante para una enumeración. Intentaré verificar pronto si se necesitan configuraciones alternativas.

@adrientetar , eres nuestro principal cliente de botones verticales. ¿Tiene recortes de pantalla o contexto que podría ayudarme a comprender mejor sus limitaciones de espacio? @mdtauk me hizo pensar con esta respuesta antes:

Un pensamiento inicial es, ¿será el número en el contenedor lo suficientemente grande como para necesitar una orientación vertical? AutoCompleteBox no mueve su botón de búsqueda y las cadenas suelen ser más largas que los números.

@SavoySchuler (con respecto a restablecer al último valor bueno) Como la especificación agregará más capacidad al NumberBox para el manejo y reporte de errores que los controles en la revisión de

Considera esto:

1. NumberBox con AllowsCalculations=True
2. ingrese manualmente 1100 y pase al siguiente control
3. darse cuenta de que esto no es lo que quería entrar
4. vuelve al control e ingresa "99 x 12"
5. tab al siguiente control y el valor vuelve a mostrar "1100" ('x' no es lo mismo que '*', por lo que fallará en el paso de cálculo. O considere cualquier otro cálculo no válido que falle si 'x' no lo haría ' Se mostrará si se presiona.)
6. Ahora muestra un valor que no es el resultado del cálculo, no se muestra ningún mensaje de error y la suma ingresada se pierde, por lo que no hay registro de lo que sucedió.

Lo que me gustaría que sucediera cuando de la pestaña al siguiente control en el paso 5 es

• "99 x 12" sigue siendo el Text
• Se muestra el estado de error.
• ValueChanged evento activado y pasado (Texto = '99 x 12 ', OldValue = 1100, NewValue = Double.NaN)
• El usuario puede ver que algo andaba mal
• El usuario puede corregir el problema sin tener que volver a ingresar la suma completa.
• La lógica de código / aplicación puede hacer algo apropiado si es necesario.

Si va a volver automáticamente al último valor bueno conocido en la entrada:

• ¿Cuándo, aparte de cuando no se ingresa ningún valor en un campo requerido, se indicará el estado de error?
• ¿No se reduce considerablemente el valor de tener el evento ValueChanged ya que nunca informaría sobre un estado no válido?

@SavoySchuler @mrlacey Mirando esos ejemplos en otras aplicaciones de Microsoft ...

Debe descartarse cualquier ventana emergente modal. En su lugar, esto debería ser manejado por un estado de validación en el propio control.

IMAGEN

Si hay un valor que no es válido, entonces quizás el contenido debería permanecer en ese estado no válido, pero solo mientras el control está enfocado. Si se pierde el foco, el valor del campo de texto se revierte, pero el aviso de validación muestra lo que el usuario ingresó.

InputScope: ¿Número o FormulaNumber?

Como se mencionó anteriormente (en un comentario de relaciones públicas), FormulaNumber no incluye el 'espacio' que incluyen todos los ejemplos de cálculo aquí y en la especificación. FormulaNumber también incluye símbolos matemáticos que no son compatibles con este control

Yo voto por 'Número'

Número

FormulaNumber

@SavoySchuler Quiero decir que solo estoy haciendo una aplicación de escritorio (no intento hacer mi propia versión de Excel ni nada). Creo que deshabilitaré las flechas por completo, creo que bastará con arrastrar el mouse. Si se planea arrastrar el mouse, entonces quizás el cambio de valor debería activarse en cada cambio, porque el usuario desea obtener una vista previa de un rango de posibles cambios en ese caso. La barra lateral:

Por cierto, el contenido de TextBox no se centrará verticalmente, y esto es con VerticalContentAlignment = "Center".

Es similar al tipo de barra lateral de propiedades que usa Paint 3D (que también usa su propio estilo de control con bordes más delgados y claros, y lo que parece una propiedad de sufijo)

Si no se va a implementar Arrastrar, siempre puede hacer lo que hizo Paint 3D y tener un control deslizante vinculado al NumberBox.

También es similar a lo que hace Adobe al tener un control deslizante desplegable en su control.

@adrientetar Parece que estás haciendo tu propia versión de un NumberBox allí. El texto en su TextBox tendría una alineación de línea de base, ya que las fuentes tendrán un descendente que debe tenerse en cuenta.

Para el NumberBox podría haber un caso para tener caracteres visualmente centrados, pero estos NumberBoxes no se alinearían cuando se colocaran junto a un control estándar TextBox o TextBox derivado como ComboBoxes.

Al crear las Plantillas y Estilos predeterminados, debe considerar las diversas propiedades de Windows.UI.Xaml.Documents.Typography ...

• Typography.CaseSensitiveForms
• Typography.NumeralAlignment + Typography.NumeralStyle (Tabular puede ser preferible a Proporcional)

@mrlacey , haces un argumento válido. Según la respuesta de @adrientetar , ¿qué pasa con el siguiente escenario?

Los eventos de cambio de valor / texto se activan en _ cada_ cambio (para los casos en que los usuarios de arrastrar / desplazarse están probando el rango) y, por lo tanto, la validación puede ocurrir continuamente donde el mensaje de error y el indicador se muestran hasta que se presiona "Enter" / se pierde el enfoque, en en cuyo caso, la invalidación del valor de validación se activa y sobrescribe el último valor válido (a menos que ese comportamiento esté desactivado por su propiedad respectiva).

Hablaré con el equipo esta tarde para validar si ese evento de activación / validación constante es una idea realista; de lo contrario, podemos construir en el rango delimitando de otra manera.

@mdtauk , pero creo que tiene razón con sus afirmaciones sobre la representación visual de la validación. @LucasHaines , ¿puedes

@jevansaks , ¿puede opinar sobre la consideración de InputScope a continuación?

Como se mencionó anteriormente (en un comentario de relaciones públicas), FormulaNumber no incluye el 'espacio' que incluyen todos los ejemplos de cálculo aquí y en la especificación. FormulaNumber también incluye símbolos matemáticos que no son compatibles con este control

Yo voto por 'Número'

Número

FormulaNumber

@SavoySchuler re esto

Los eventos de cambio de valor / texto se activan en cada cambio (para los casos en que los usuarios de arrastrar / desplazar están probando el rango) y, por lo tanto, la validación puede ocurrir continuamente donde el mensaje de error y el indicador se muestran hasta que se presiona "Enter" / se pierde el foco, en en cuyo caso, la invalidación del valor de validación se activa y sobrescribe el último valor válido (a menos que ese comportamiento esté desactivado por su propiedad respectiva).

ValueChanged evento Value real, no cada vez que cambia el Text .

a menos que ese comportamiento esté deshabilitado por su propiedad respectiva

¿Qué es esta nueva propiedad?

No sé cómo los eventos más frecuentes resuelven el problema de los valores incorrectos y los estados de error que se pierden al revertir al último valor bueno conocido.
Siento que se requiere algo de experimentación aquí para comprender cómo será esto realmente. (Si tan solo pudiera encontrar el tiempo ...)

En una nota relacionada.

Supongo que el evento TextChanged heredado de TextBox no se modificará para el consumidor. Pero, ¿qué pasa con el evento TextChanging ? ¿Será aquí donde se realiza un nuevo procesamiento específico de control? ¿El consumidor del control también podrá manejar este evento?

De acuerdo: vale la pena explorarlo, pero es mejor evitarlo. Revisé la sección sobre Validación y agregué una propiedad IsInvalidInputOverwritten que está deshabilitada de manera predeterminada. ¿Qué piensan todos sobre lo siguiente?

• Una entrada que no es numérica o que excede los valores mínimo / máximo activará una advertencia de Validación de entrada .
• El desarrollador puede interceptar los eventos ValueChanged o TextChanged (que exponen la propiedad modificada y la que se actualizará) y manipular manualmente la entrada no válida antes de que se muestre una advertencia de Validación de entrada .
• Habilitar la propiedad IsInvalidInputOverwritten revertirá la entrada no válida al último estado válido sin mostrar la advertencia de Validación de entrada . Por ejemplo, si IsInvalidInputOverwritten está habilitado, StepSize = 0.2, MaxValue = 3.0 y el valor 2.9 se incrementa, 3.1 se registrará como inválido y se sobrescribirá de nuevo a 2.9.

Mucho de esto podría resumirse con la pregunta de si la validación debería ocurrir durante la entrada o después. Me inclino después por el bien del rendimiento y porque la experiencia de recibir validaciones a medida que escribe puede ser discordante y poco accesible, lo que hace que lo anterior sea mi implementación preferida actualmente.

FWIW, Adobe Photoshop e Illustrator vuelven al valor anterior cuando intenta ingresar un valor no válido. Esto tiene el comportamiento de cálculo, pero el sufijo de la unidad de medida es parte del texto, lo que en sí mismo puede causar problemas de validación :)

Quería incluir una idea sobre la que tenía un conflicto conmigo mismo: puedo recordar en muchas experiencias pasadas en las que tuve algún cuadro de número de clasificación con funcionalidad de incremento / decremento, ir por debajo del valor mínimo me devolvería al valor superior, y viceversa. Quería ver si algo como una propiedad _ValuesWrap_ tiene sentido aquí.

Obviamente, esto no tiene sentido en todos los casos, pero en casos de rango numérico limitado, ha sido intuitivo para mí en el pasado asumir que los números se ajustan en casos como la entrada de Edad o Fecha de nacimiento o para otros casos de rango pequeño. Por otro lado, esto a veces solo ocurre porque en estos casos se está utilizando un cuadro de selección de opción múltiple, y esos generalmente ajustan los valores en lugar de detenerse. Solo quería verificar si hay alguna justificación o necesidad; por supuesto, probablemente también podría implementarse en el extremo del desarrollador a través de cualquier evento onValueChanged con trabajo adicional.

cc @SavoySchuler

Impresionante idea, @KevinTXY. Si alguno de nuestros desarrolladores necesita algo así, ¡podemos agregarlo!

Tiempo de preguntas: ¿alguien tiene alguna escenarios de aplicaciones reales que justifican que necesitan apoyo para hexadecimal o binario? ¿Envolviendo valores máximos / mínimos?

Quería ver si algo como una propiedad ValuesWrap tiene sentido aquí.

sí, si tiene una propiedad de ángulo, quiere ir 359 → 0, básicamente mod 360. Lo divertido es que todavía tuve que subclasificar el control (estaba en Qt) porque MaxValue solo podía ser inclusivo, por lo que podría especificar 359 o 360, pero realmente quería poder escribir 359,99 pero no 360 (es decir, quería <, no ≤).

El QSpinBox tiene una propiedad de envoltura para ese propósito https://doc.qt.io/qt-5/qabstractspinbox.html#wrapping -prop

@SavoySchuler Con respecto a hexadecimal, sospecho que un editor hexadecimal podría querer eso, pero parece un caso de uso realmente especializado, no tiene que admitir todo lo posible, solo asegúrese de que el control sea fácil de subclasificar. En Qt, el control tiene un método que convierte de la cadena del cuadro de texto al valor numérico (ya sea int o double) que se puede anular.

Por ejemplo, si IsInvalidInputOverwritten está habilitado, StepSize = 0.2, MaxValue = 3.0 y el valor 2.9 se incrementa, 3.1 se registrará como inválido y se sobrescribirá de nuevo a 2.9.

Probablemente podría sujetarse a MaxValue en ese caso.

@SavoySchler @xyzzer @mrlacey Vi en Twitter que hay algo en camino en 20H1 que proporciona ingreso de texto predictivo.

Esto puede interferir con la función de finalización de la vista previa de la que hablamos y es posible que deba suprimirse en el control NumberBox. Al llegar a los controles Win32 y XAML, parece ...

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

Asumiría que manejar hexadecimal o binario son escenarios aún más especializados que manejar "cadenas que parecen números" como números de teléfono y códigos postales. (y aportan su propia complejidad)
Como tal, creo que deberían estar fuera del alcance del control NumberBox.

Hablando de la función de cálculos de vista previa, en caso de que se pierda, propondría darle al usuario la opción de activarla o desactivarla. Entonces, tal vez agregue una propiedad como

public bool ShowPreviewResult { get; set; }

¿Por qué mostrarías el resultado de la vista previa? 🤔 No es como si el usuario cambiara su fórmula dependiendo del resultado, si conocen el resultado que quieren, simplemente lo escribirán de inmediato.

¿Por qué mostrarías el resultado de la vista previa? 🤔 No es como si el usuario lo que está escribiendo dependiendo del resultado, si saben lo que quieren, simplemente lo escribirán de inmediato.

Una de las características del control es poder ingresar en un cálculo, como 32 * 4, que se resolvería como 128 ; la función de vista previa mostraría cuál sería el resultado cuando el control pierde el enfoque o se presiona Enter.

@adrientetar La vista previa es una característica provisional a partir de ahora. Creo que el valor estaría en parte en la validación orientada al usuario antes de que se active la validación del control, por ejemplo, solo muestra si lo que se ingresó se puede calcular / está dentro de los límites; por ejemplo, verificar las expectativas ("¿Acerté tiempos en lugar de más?"). El interés y el retorno de la inversión aquí aún no están claros.

¡Gracias a todos por los comentarios nuevamente! Parece que no hay una necesidad urgente o un interés que justifique el soporte binario o hexadecimal por ahora. También puede subclasificarse, proponerse como un nuevo control o proponerse para V2 según sea necesario.

@SavoySchuler con respecto a "¿Alguien tiene algún escenario de aplicación real que justifique la necesidad de soporte para hexadecimal o binario?", Un ejemplo es el propio control ColorPicker de WinUI. Incluye un cuadro de entrada hexadecimal. También incluye una serie de otros TextBoxes de entrada de números. Podría valer la pena considerar la posibilidad de actualizar ColorPicker para usar el nuevo control NumberBox como una forma de validar el nuevo control. Si NumberBox puede simplificar la implementación actual de ColorPicker, sería una victoria.

En caso de que el estilo de borde más delgado para los cuadros de texto no supere a

@kmahone - estuvo de acuerdo. Como mencionó en el enfriador de agua esta mañana, poder eliminar una gran cantidad de código detrás de ColorPicker reemplazando sus instancias de TextBox + lógica de validación local con NumberBox podría ser una victoria por derecho propio.

@mdtauk - ¿te he dicho demasiadas veces que tus maquetas se ven increíbles? ¡Los incluiré en la especificación en breve!

@SavoySchuler Si el equipo de diseño de Windows

¡Seguro, @mdtauk! ¡Espero bloquear los requisitos funcionales para @KevinTXY aquí en un futuro próximo y @chigy (que ha estado ocupado haciendo un trabajo increíble en el n. ° 524) entonces!

Gracias por toda la discusión a todos, ¡estoy encantado de trabajar en esta función este verano como pasante!

Si es relevante para alguien, comencé un prototipo C # del control en el siguiente repositorio.
https://github.com/KevinTXY/NumberBox

Básicamente, esta es la primera vez que aprendo C # / UWP, por lo que irá avanzando lentamente y, si alguien lo mira, ¡me alegra recibir comentarios sobre lo que se podría hacer mejor!

Las siguientes características se implementan de manera aproximada:

• Validación de entrada numérica (aún no sigue las especificaciones de la propuesta de validación , esperará el código para eso)
• Almacenamiento / vinculación de valor
• Recorte cero
• Soporte completo de ingreso de fórmulas / calculadora

Actualmente trabajando en botones giratorios y cosas de aplicaciones de prueba, así como en la validación mínima / máxima.

¡Salud!

Actualización de la línea de tiempo!

He integrado varias actualizaciones, sugerencias y comentarios en la especificación que validaré con el equipo de WinUI hoy (jueves). Espero finalizar más o menos la API y los componentes de comportamiento para V1 al hacerlo.

Ahora, pasaré a Entradas y Accesibilidad, Datos e Inteligencia y Componentes Visuales.

El último paso será ordenar la documentación y crear pautas.

Creo que la opción inconexa y contigua es muy específica sin un caso de uso que la interfaz de usuario de shell / aplicaciones de origen de Microsoft haya tenido que hacer en WPF o Win32.

Si desea incluirlo, prefiero que sea un estilo incluido que pueda aplicar al control, que una opción. ¿Cómo tratarían los controles NumberBox con plantilla nueva con esa propiedad, en sus nuevas plantillas?

Si el consenso es que este modo debería incluirse, entonces podría sugerir que se convierta en un valor de enumeración como parte de SpinButtonPlacementMode . No estoy seguro de cómo se llamaría esta opción. _Straddled_ quizás no sea lo suficientemente profesional jajaja, y no estoy seguro de que _Bookended_ sea mejor.

Estaba mirando la última versión de Canary de Edge y vi el diseño de un <input type="number"/> que es lo más cercano a un control NumberBox.

Solo pensé en compartir esta imagen.

@mdtauk : de acuerdo, SpinButtonPlacementMode sería el lugar correcto para agregar opciones alternativas de ubicación de SpinButton.

Sobre el tema de los nombres, @ Felix-Dev destacó correctamente en la especificación de que SpinButton puede no ser el nombre más intuitivo o conocido. SpinBox y UpDownButtons también tienen prioridad en el ecosistema de Windows. Voy a indagar en esto más pronto, pero por favor avíseme si alguien tiene un caso en contra de alguna de estas opciones.

@mdtauk - ¡Gracias por compartir eso! También estoy ejecutando Canary, así que echaré un vistazo y veré si hay algo que podamos aprender o si hay espacio para sugerir alinear los desarrollos.

@SavoySchuler Estoy usando la Controls habilitada (incluidos los controles experimentales)

Creo que la implementación de WinUI sería un diseño más pensado que Fabric Web y Edge deberían buscar, pero la alineación es algo bueno.

Número de tipo de entrada de w3schools

Además, ese control deslizante está cerca, pero no es exactamente lo mismo que WinUI planea hacer (pulgar circular delineado, en comparación con un pulgar circular relleno)

Todavía no estoy seguro de cómo puedo configurar las funciones de localización. En los EE. UU., El punto se usa para un separador decimal. En los Países Bajos (donde vivo) usamos la coma. El separador de agrupación en los EE. UU. Es la coma, pero en los Países Bajos es el punto.

Ejemplo:

¿Debo usar la propiedad Language del elemento Framework para especificar el separador de dígitos y agrupaciones?

<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>

Estaba mirando la última versión de Canary de Edge y vi el diseño de un <input type="number"/> que es lo más cercano a un control NumberBox.

Solo pensé en compartir esta imagen.

@mdtauk , @SavoySchuler ,
No sé de dónde vino este control. Según mi contacto en el equipo de Edge, estos son los controles que usarían.

Control deslizante: https://explore.fastdna.net/components/slider/
Cuadro de número: https://explore.fastdna.net/components/number-field/

No estoy seguro de si actualizarán la imagen y es posible que el resultado final no se vea exactamente así (supongo que sí, pero esa es mi suposición).

@chigy Esa imagen era de la versión Canary actual de Edge, pero como señalé, es un WIP y es una marca opcional que enciendes.

Supongo que eso explica para qué es ese proyecto fastdna, que mencioné en un número anterior. 🙂

¿Debo usar la propiedad Language del elemento Framework para especificar el separador de dígitos y agrupaciones?

Esas configuraciones generalmente provienen de la "región", por lo que creo que simplemente pasaríamos la HomeGeographicRegion al constructor DecimalFormatter. No veo ningún otro lugar en la API donde permitamos a los usuarios personalizar la región (¿nuestros formateadores de fecha / hora no parecen ser personalizables?), Pero los selectores permiten personalizar la cadena de formato, por lo que tal vez podamos permitir eso aquí también.

No veo una forma de personalizar los caracteres separadores en la API DecimalFormatter, por lo que deben extraerse de la configuración de idioma. 😖

@jevansaks , ¡gracias por la información! Etiquetaré a @sonnemaf para asegurarme de que vea la respuesta.

@jevansaks ¿puedes escribir un ejemplo de xaml sobre cómo DecimalFormatter para NumberBox? Quiero definirlo en XAML y no desde el código subyacente. Tener las propiedades DecimalSymbol y GroupingSymbol también funcionaría para mí. Sin embargo, esto podría ser demasiado fácil.

<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?

Lamento interrumpir. Acabo de descubrir este tema, pero SÍ SÍ SÍ. Ambos faltan a menudo en los controles numéricos y yo y muchos otros desarrolladores en github tenemos que crear soluciones alternativas para ello. Especialmente con el ejemplo de la calculadora, no solo debería formatear un número en hexadecimal, sino que también es totalmente compatible con la entrada.

En este momento, me gustaría sugerirle que haga que el prefijo de hexdecimals sea personalizable. En algún momento es mejor no tener ningún prefijo y en otros puntos no siempre es 0x

¿Puede escribir un ejemplo de xaml cómo DecimalFormatter para NumberBox? Quiero definirlo en XAML y no desde el código subyacente. Tener las propiedades DecimalSymbol y GroupingSymbol también funcionaría para mí. Sin embargo, esto podría ser demasiado fácil.

@sonnemaf todo con lo que tenemos que trabajar en WinRT es DecimalFormatter y, desafortunadamente, no le permite personalizar esa configuración. La única forma de personalizar el símbolo decimal o el símbolo de agrupación es a través de la configuración del usuario en el panel de control de la región del sistema operativo (hasta donde yo sé).

Sin embargo, respetar la región del usuario para esas configuraciones parece correcto: ¿tiene un escenario en el que necesita anularlas?

@sonnemaf

¿Alguien tiene algún escenario de aplicación real que justifique la necesidad de soporte para hexadecimal o binario?

Lo siento, me di cuenta de esto y respondí un poco tarde. Creo que el soporte hexadecimal / binario sería muy útil. Estoy muy involucrado con el proyecto .NET IoT y trabajamos principalmente en el mundo hexadecimal / binario, ya que manipulamos bits / bytes que leen / escriben en registros y pines para controlar las cosas.

Apoyar hexadecimal / binario sería muy agradecido. Gracias 😄

No necesito hexadecimal o binario. Sería bueno tenerlo, especialmente binario.

Actualización para desarrolladores

¡Hola a todos! Nos estamos contentando con la especificación NumberBox, y solo quiero llamar la atención sobre el hecho de que estoy trabajando activamente en el control . Lo ideal sería que se hiciera un primer RP con las funcionalidades más importantes muy pronto, posiblemente esta noche.

Algunas notas:

• Elegimos no subclasificar TextBox particularmente debido a algunas complicaciones de diseño con InputValidation, NumberBox será su propio control que contiene un TextBox.
  
  
  
  • Esto significa que no se expondrán todas las propiedades de TextBox. Tengo curiosidad por saber si alguno de estos es importante para llevar a NumberBox: pude ver el deseo de _Header, PlaceHolderText_, y quizás también _Text_. Definitivamente quería abrir este un poco porque es un cambio muy fácil de hacer por mi parte.
  
  
• He estado haciendo modificaciones muy pequeñas en la especificación, estas son en su mayoría solo correcciones de redacción por ahora, pero todavía hay preguntas abiertas, como la vista previa del valor, y mientras escribo el control, estoy generando algunas de mis propias preguntas de diseño. Este sigue siendo un buen momento para agregar información 😄

@KevinTXY Hubo una sugerencia para derivar de la base de Slider en lugar de TextBox: ¿es esto lo que se ha elegido?

• Texto del marcador
• Encabezamiento
• Texto
• Icono de validación
• Mensaje de validación
• SelecciónForeground
• SelecciónFondo
• Estados de enfoque / recursos, etc.

Estas son algunas de las cosas de TextBox que creo que son necesarias. No estoy seguro del botón "texto sin cifrar", que tiene más sentido con cadenas de texto largas.

Vista previa del valor Pensé que era una función de la V2, pero ¿ha cambiado esto? El control Slider tiene una información sobre herramientas que muestra el valor, a medida que se desliza el pulgar. Sugerí esto como una forma de manejarlo, así como también usar el mensaje de validación para manejar esto, o mostrarlo en línea.

Inline tiene un problema con el hecho de que Windows Insider construye experimentando con la finalización de texto predictivo, ya sea como información sobre herramientas o dentro de los campos de texto. Cualquiera que sea el método de vista previa que se elija, no debería entrar en conflicto con esos o con la función predictiva desactivada para este control.

@KevinTXY Hubo una sugerencia para derivar de la base de Slider en lugar de TextBox: ¿es esto lo que se ha elegido?

NumberBox es actualmente su propio control (extiende Windows.UI.Xaml.Controls.Control) que contiene un TextBox en su marcado en lugar de extender TextBox. Slider suena interesante, pero creo que haría que la implementación fuera un poco complicada, también hay muchas propiedades en estos controles que no nos sentimos pertenecientes a NumberBox. No soy un PM, pero por mi experiencia en el desarrollo de esto, siento que esta es una buena ruta para simplificar el desarrollo y para la extensibilidad futura.

Estas son algunas de las cosas de TextBox que creo que son necesarias. No estoy seguro del botón "texto sin cifrar", que tiene más sentido con cadenas de texto largas.

Esto es increíble, ¡exactamente lo que estaba buscando! Estoy de acuerdo en que hay valor en todos estos. El botón Borrar todo está actualmente allí, ya que es una función predeterminada de TextBox; supongo que tiene valor para entradas grandes o usuarios de pantalla táctil, aunque todavía no he pensado en deshabilitarlo. Definitivamente, al menos intentaré obtener los tres que mencioné (Encabezado, Texto de marcador de posición, Texto) en la vista previa.

En cuanto a la vista previa del valor, no se finaliza nada allí y solo está en la especificación como una pregunta abierta. Supongo que la solución temporal más fácil sería simplemente exponer el valor de vista previa para que los desarrolladores lo muestren como deseen; eso podría estar fácilmente dentro del alcance de la versión de vista previa, pero dejaré que @SavoySchuler & Co. haga las llamadas. Los cálculos probablemente ni siquiera harán el corte en mi PR durante al menos unos días de todos modos mientras estoy investigando motores matemáticos, por lo que no es un detalle urgente. Aprecio la investigación realizada, ¡hay muchas ideas interesantes aquí!

@KevinTXY Idealmente, habría una colaboración con el equipo de Calculator, para crear un motor de cálculo básico que podría integrarse, así como para uso futuro con la idea de CalculatorPicker que se discutió junto con este control. (Un control con un botón de calculadora, que muestra un control flotante con una calculadora estándar)

En realidad, la colaboración con los encargados de mantenimiento de Calculator parece una gran idea. Podría exponer un servicio de aplicación de Calculadora que realizaría los cálculos matemáticos, por lo que ni siquiera necesitaría bload el binario de WinUI; simplemente hable con el servicio de aplicación si la aplicación está instalada y, de lo contrario, simplemente falle silenciosamente.

En cuanto a derivar de Slider, en realidad dije RangeBase y todavía estoy bastante seguro de que es lo correcto, ya que el control básicamente proporciona casi todas las propiedades y características de accesibilidad que necesitará y derivar de él proporcionará una superficie de API consistente entre su control y el control deslizante, lo que los convierte en reemplazos fáciles de cambiar.

Ah, sí, RangeBase, eso fue todo.

Calculator ha trabajado recientemente para admitir un modo CompactOverlay siempre activo, por lo que es más factible colocar un teclado más pequeño en un menú desplegable de tamaño similar al CalendarFlyout. (Si se aprueba la inclusión del control CalculatorBox.

No estoy seguro si es un servicio de aplicación (que vincularía las actualizaciones de WinUI de forma semi-dependiente de las actualizaciones de la tienda Calculator) o si es un servicio binario que se puede agregar a WinUI y derivar del motor de Calculator.

Actualización: ¡Ahora existe un código PR 🎆!

Estoy rastreando algunos problemas allí, aunque la mayoría no están relacionados con el diseño.

¡Gracias, @xyzzer y @mdtauk! Hemos revisado RangeBase y parece llevar tanto equipaje como lo haría la subclasificación de TextBox. A partir de ahora, nos limitaremos a contener un TextBox en el control y agregar solo las propiedades y funciones de accesibilidad necesarias. Esta todavía fue una consideración que valió la pena y ayudó a informar nuestra conversación sobre accesibilidad que está ocurriendo ahora.

@mdtauk , ¡gracias por la lista de inicio! @KevinTXY ha comenzado a exponer las API que enumeró y

Vista previa y calculadora emergente, como mencionó @KevinTXY , en conversaciones (aunque no hay garantía v1 aquí). Estamos conversando activamente con Calculadora sobre la alineación y el trabajo aprovechable. ¡Ustedes son increíbles! Gracias por seguir impulsando la innovación en este control. Es impresionante. @KevinTXY tiene su Código PR publicado arriba. Estaré atando todos los cabos sueltos restantes en la especificación poco antes de pasar a la redacción de Orientación y documentación.

Nombrar

Hubo tantos comentarios que la especificación se me escapó, así que estoy empezando a echar un vistazo después de que las cosas se calmaron. Primero, noté algunos nombres que realmente no siguen la convención de C #; sí, sé que estos controles están escritos en C ++ pero sigo pensando que es inconsistente con otros nombres en la plataforma.

| Tipo | Nombre actual | Nombre propuesto |
| ------- | ---------------- | ------------------- |
| Booleano | Acepta cálculo | IsCalculationAccepted |
| Booleano | HyperDragEnabled | IsHyperDragEnabled |
| Booleano | HyperScrollEnabled | IsHyperScrollEnabled |

Paso Frecuencia

Además, ¿qué es StepFrequency? Esto no está definido en la especificación y no tengo ninguna experiencia con "NumericUpDown de XAML Toolkit". Dependiendo de lo que haga, es posible que agregar la palabra Frecuencia no tenga sentido. ¿Probablemente sea solo un "paso"? En el control deslizante, TickFrequency tiene sentido porque los ticks se muestran en un módulo del rango máximo-mínimo general. Sin embargo, en este control, creo que este es solo el tamaño mínimo de incremento / paso. Básicamente, ¿podrá el usuario ingresar un valor que esté fuera del paso?

Por ejemplo, MinValue = 0, MaxValue = 6, StepFrequency = 2. Usar el valor de la flecha hacia arriba será {2, 4, 6} suficientemente justo. Sin embargo, ¿puede el usuario escribir 0,5 como valor válido? ¿O se redondeará a 0 o 2 según el RoundingMode?

Min / MaxValue

Para las dos propiedades a continuación, creo que deberían ser Mínimo y Máximo como en otros controles (Control deslizante, RangeBase). Las API deben ser coherentes.
Double MinValue;
Double MaxValue;

Botones de repetición UpDown

Otra característica que no se ha discutido hasta donde yo sé es si hacer que los botones arriba / abajo sean realmente RepeatButtons (creo que deberían serlo). Si son botones de repetición, las propiedades de Delay / Interval deben agregarse como el control Slider: Slider.Interval Slider.Delay

Dígitos

¿Puede agregar una descripción de lo que representan IntegerDigits y FractionDigits? Supongo que limitan la cantidad de dígitos para cada parte del número. IntegerDigits = 2 significa que el valor máximo puede ser 99. FractionDigits = 3 significa que MaxValue puede ser 0.999. Además, ¿cómo anula SignificantDigits estas dos propiedades?

¿Cero negativo?

¿Por qué se necesita esta propiedad? ¿Es eso una cuestión de localización en sí misma? Nunca he visto "-0.0" o "-0". Siempre es solo "0".
Boolean IsZeroSigned;

Localización

Estoy convencido de que necesito este control para admitir la anulación de la localización de la interfaz de usuario y el formato de número. Tengo múltiples usos (aplicaciones financieras) donde necesito cantidades locales y extranjeras que deben mostrarse de manera diferente. No veo esto en ninguna parte de la especificación.

La conversión de doble a texto debe ser personalizable a través de ValueConverter, en el espíritu de Slider.ThumbToolTipValueConverter. De esa manera, la parte más compleja podría personalizarse para cualquier necesidad, como en algunos ejemplos del mundo real a continuación:

Tenga en cuenta que el separador decimal para números y dinero podría ser diferente, así como la designación de las sumas negativas, por lo que probablemente el enfoque más seguro para NumericBox sin ValueConverter es operar en modo entero. La calculadora también podría implementarse como ValueConverter, no hay necesidad de sobrecargar el control con este trabajo.

@eugenegff Tiene una muy buena idea para hacer que la conversión de número a cadena sea genérica. Esto me permitiría manejar la localización, pero también permitiría a los desarrolladores hacer cualquier otra cosa que quisieran, como agregar unidades.

La única complejidad que veo es mantener una Culture / NumberFormatInfo relacionada con el control. Supongo que esto podría ser un parámetro de conversión en XAML que va a IValueConverter personalizado, pero probablemente debería haber una forma más limpia de manejar esto en el control mismo.

¿Por qué se necesita esta propiedad? ¿Es eso una cuestión de localización en sí misma? Nunca he visto "-0.0" o "-0". Siempre es solo "0".

Es una propiedad de la clase DecimalFormatter en Windows. Es raro Probablemente. Hay algunas propiedades como IsGrouped y propiedades de localización que dejamos de lado, por lo que quizás esta tampoco sea necesaria. Al mismo tiempo, también ya está implementado, por lo que eliminarlo no tendría otro propósito que desbloquear 3 líneas de código. Curiosamente, existen usos y requisitos previos de IEEE para tener ceros firmados .

Estoy convencido de que necesito este control para admitir la anulación de la localización de la interfaz de usuario y el formato de número. Tengo múltiples usos (aplicaciones financieras) donde necesito cantidades locales y extranjeras que deben mostrarse de manera diferente. No veo esto en ninguna parte de la especificación.

@SavoySchuler, ¿ quizás deberíamos considerar la posibilidad de admitir la configuración de Idiomas en la clase DecimalFormatter? Sin embargo, no estoy familiarizado con cómo se comporta.

Ok, creo que entiendo el problema fundamental aquí. En el mundo C ++ tiene acceso a DecimalFormatter pero en el mundo C # (si consumiera WinUI) normalmente usaría un IFormatProvider (NumberFormatInfo de una Cultura especificada). NumberFormatInfo ya tiene la mayoría de las propiedades (por coincidencia, falta IsZeroSigned), así que estaba pensando en permitir que los desarrolladores especifiquen eso o un IFormatProvider. Bueno, ahí está el problema, C ++ no puede usar un IFormatProvider ya que es del mundo .net.

Entonces, ¿cómo este control admite completamente la localización en C # y C ++ considerando que tienen dos formas diferentes de hacerlo? Bueno, a menos que Microsoft tenga una solución inteligente, solo puedo pensar en dos posibilidades:

1. Agregue por completo todas las propiedades para el formato de números (reimplementando de manera efectiva NumberFormatInfo y DecimalFormatter). Agregar solo IsZeroSigned, IntegerDigits, FractionalDigits, etc.no lo cubrirá. NumberNegativePattern, NumberGroupSeparator, NumberGroupSizes, etc. también son obligatorios.
2. Haga lo que sugirió @eugenegff y permita que los desarrolladores anulen el formato con algún tipo de devolución de llamada. Honestamente, este parece el enfoque más fácil.

Estoy un poco preocupado por cómo se está formando la localización en este control. He estado mencionando la localización desde el principio (¡tercer comentario sobre este tema!). Debe haber alguna forma de personalizar completamente el formato de número cuando el control se convierte en una cadena. Sin eso, este control será bastante limitado en el uso del mundo real.

Entonces, ¿cómo este control admite completamente la localización en C # y C ++ considerando que tienen dos formas diferentes de hacerlo?

¡Te oimos! Es algo que hemos estado investigando sin conexión, pero fundamentalmente .NET hace su propia localización por separado de la plataforma. Creo que una devolución de llamada para anular es una gran escotilla de escape, pero tengo la esperanza de que su opción 1 sea la ruta que podemos seguir. Por el momento, las API de WinRT para formatear y analizar no tienen todas las perillas de personalización que necesitamos. Todavía estamos investigando.

No he comprobado si esto ya se ha discutido, pero quería preguntar rápidamente si alguien ve una gran necesidad o, lo que es más importante, algún precedente de soporte de funciones para cálculos, es decir, cualquiera de los siguientes o más:
cos(), sin(), tan(), asin(), acos(), atan(), sqrt(), log(), abs(), ceil(), floor(), degree equivalents of trig functions, hyperbolic functions, etc

Estoy uniendo analizadores matemáticos para satisfacer nuestras necesidades y las funciones complican el proceso de conversión a RPN (eso decía que ya tengo una versión que admite estos con algunos errores), así que estoy interesado en ver si alguno de estos vale la pena. el problema o si parece hinchazón. Personalmente, no creo que encaje demasiado bien, pero si hay muchos precedentes no es demasiado problemático.

Creo que estos no serían muy detectables en la mayoría de los casos y si alguien necesita soporte para funciones más complicadas, es mejor trabajar para abrir el análisis a un evento de devolución de llamada que permita a los usuarios implementar su propia lógica de análisis o preprocesamiento.

Lo que sería más valioso es permitir comenzar a escribir texto con un operador, por lo que si hace clic en el texto, seleccionaría todo de forma predeterminada y podría escribir un nuevo valor sin tener que presionar eliminar primero para eliminar el anterior o simplemente escriba algo como "* 1.2" o "x1.2" [Enter] y haga que el valor actual se multiplique por 1.2 incluso cuando el texto ingresado ya no contenga el valor ingresado. Lo mismo funcionaría para "+2", "-5", "/ 3", "% 120", etc.

Se utiliza en algunas aplicaciones profesionales.

Nosotros (BeLight Software, proyecto Live Home 3D) necesitamos ValueConverter enchufable para la conversión de texto value <=>; de lo contrario, NumberBox no sería adecuado para nosotros.

Creo que el uso de esas funciones sería bastante raro, tengo una entrada de ángulo en mi aplicación, pero es solo un valor en grados. El uso más importante para mí es poder agregar un valor a lo existente o dividir lo existente por un número, solo para ahorrar tiempo y evitar hacer ese cálculo mentalmente. (Por cierto, creo que eso es lo que tienen las aplicaciones de Adobe, los 4 operadores aritméticos: https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/suggestions/12992463-support-math-operators-in-number -los campos)

También funciona como cos (), probablemente no lo desee donde no tiene sentido, a menos que esté creando algún tipo de aplicación de Excel.

El uso más importante para mí es poder agregar un valor a lo existente o dividir lo existente por un número, solo para ahorrar tiempo y evitar hacer ese cálculo mentalmente.

¡Vale genial! Suena similar a lo que propuso @xyzzer . Echaré un vistazo a implementaciones similares y veré si hay espacio para hacer esto de una manera que se sienta natural e intuitiva.

Nosotros (BeLight Software, proyecto Live Home 3D) necesitamos ValueConverter enchufable para la conversión de texto value <=>; de lo contrario, NumberBox no sería adecuado para nosotros.

Eché un vistazo al ejemplo de Slider que dio y suena muy razonable: pude ver el valor en un IValueConverter para NumBox. Lo investigaré pronto e intentaremos decidir si encaja adecuadamente en la especificación. ¡Sin embargo, todavía no hay promesas de nada!

@KevinTXY Sospecho que agregar las funciones que mencionas anteriormente abriría la puerta a más problemas que el valor que puede proporcionar. Esto se debe a que permitiría escribir una mayor cantidad de caracteres (básicamente cualquier letra) en el control. A su vez, esto facilitaría escribir accidentalmente algo no válido y también agregaría validación y complejidad de análisis.
También rompería la primera línea de la descripción al comienzo de la especificación "El cuadro de número es un control de texto solo numérico ...".

Me sorprende que todavía haya dudas sobre la localización. Como el control heredará (¿debe?) De FrameworkElement , tendrá acceso a la propiedad Language y, por lo tanto, como cualquier otro FrameworkElement, admitirá la configuración de la configuración regional directamente y no dependerá de la configuración de la interfaz de usuario de la configuración regional del sistema.
Esto significa que cosas como decimales y caracteres de agrupación se pueden configurar por instancia.

Me sorprende que todavía haya dudas sobre la localización.

El problema es que el idioma no es lo que controla el formato, es la configuración de la región / cultura. La localización consiste en actualizar las cadenas de la interfaz de usuario para que se muestren en el idioma correcto, mientras que el formato de número / moneda / fecha y hora se controla por región. Más información aquí: https://docs.microsoft.com/en-us/globalization/locale/locale-and-culture. Y para complicar las cosas, Windows le permite personalizar la configuración regional en la interfaz de usuario anulando los valores predeterminados, por lo que puede decir que desea que su separador decimal sea cualquier carácter aleatorio en lugar del predeterminado. Y además de eso, .NET permite que las aplicaciones también lo personalicen, por lo que los desarrolladores esperan ese nivel de personalización aquí.

El problema es que el idioma no es lo que controla el formato, es la configuración de la región / cultura. La localización consiste en actualizar las cadenas de la interfaz de usuario para que se muestren en el idioma correcto, mientras que el formato de número / moneda / fecha y hora se controla por región. Más información aquí: https://docs.microsoft.com/en-us/globalization/locale/locale-and-culture. Y para complicar las cosas, Windows le permite personalizar la configuración regional en la interfaz de usuario anulando los valores predeterminados, por lo que puede decir que desea que su separador decimal sea cualquier carácter aleatorio en lugar del predeterminado. Y además de eso, .NET permite que las aplicaciones también lo personalicen, por lo que los desarrolladores esperan ese nivel de personalización aquí.

Language toma un valor que se traduce en CultureInfo tenga en cuenta que una cultura se denomina configuración regional en el desarrollo de código no administrado. Contiene una propiedad NumberFormat que es un tipo NumberFormatInfo que contiene propiedades para decimales, agrupaciones, signos negativos y más.

Tengo entendido que si desea forzar un formato específico u otras especificaciones de localización en un control, en lugar de depender de la configuración del sistema, la forma de hacerlo es especificar Language .

La descripción de la propiedad establece claramente que "establece la información del idioma de localización / globalización que se aplica a un FrameworkElement".

O tal vez no he entendido bien los documentos a los que me refiero, pero todos parecen respaldar lo que se cubre en la página a la que se vinculó.
Tal vez sea un problema de terminología con C ++ y C # usando términos diferentes.
Lo que sé es que configurar Language en XAML es cómo forzaría una cultura / configuración regional en cualquier otra aplicación y con cualquier otro control.

Las preguntas que he visto sobre la localización han sido acerca de forzar formatos numéricos específicos o separadores decimales y de grupo. ¿O es el problema real, cómo controlarlos sin afectar la localización de las propiedades basadas en texto (Encabezado, Texto de marcador de posición, etc.) del control?

Language toma un valor que se traduce en CultureInfo

No en nativo / WinRT, solo obtenemos una cadena de idiomas BCP-47. Y ese es el problema. En .NET, agrupa CultureInfo, que tiene la configuración de idioma y la configuración de formato. En WinRT está separado y no hay un equivalente al objeto CultureInfo.

Escuché que las API de ICU pueden habilitar lo que estamos buscando, pero aún no hemos tenido la oportunidad de investigar eso.

Creo que Microsoft tendrá que considerar morder la bala en este caso e implementar completamente un mecanismo de conversión entre culturas / localización .net (CultureInfo) y nativo / WinRT. Idealmente, no estaría considerando una nueva forma de hacer las cosas:

Creo que el código administrado es en lo que están escritas la mayoría de las aplicaciones LOB y esto debe hacerse correctamente desde el principio. WinRT necesita obtener los mismos mecanismos / técnicas de localización que .net y las conversiones deben ser automáticas.

¿Sería mucho más trabajo? Corto plazo: sí, largo plazo: no. ¿Eso probablemente retrasaría el lanzamiento del control NumberBox? Probablemente, a menos que se utilicen devoluciones de llamada a corto plazo.

Sin embargo, esto debe hacerse bien o habrá problemas en otros lugares. Ya puedo prever algunos problemas similares con otros escenarios como CalendarDatePicker editable, etc. (# 735)

@SavoySchuler @jevansaks @chigy @mrlacey @KevinTXY
Aparentemente, el equipo de FastDNA también está trabajando en su control Spinner para el diseño de su campo de número de entrada, y se les ocurrió una propuesta que puede valer la pena considerar.

También preguntaron por qué usamos Chevrons, en lugar de Arrows.

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

Incluso si mantenemos los botones uno al lado del otro, con el diseño expandido apilado como un hover, ¿podría ser una idea cuando el ancho del Control es demasiado estrecho? ¿Quizás podría haber algún consenso sobre un diseño que funcione en todos los marcos de interfaz de usuario de Microsoft?

@mdtauk , gracias por hacérnoslo saber.
Verificando con la gente de FastDNA si este es el diseño en el que están probando y validando la usabilidad.

De vuelta en NumberBox

Muy bien equipo,

Disculpas por la inesperada ruptura. ¡Estoy de vuelta en NumberBox a toda velocidad y @teaP se une a mí como nuestro desarrollador de funciones! Todavía estamos apuntando a finales de noviembre para la vista previa de este control, que nos hará ver una versión estable con WinUI 2.4.

Hay mucho equipaje en el flujo de trabajo anterior, por lo que preservaré cualquier pregunta abierta o respondida y la trasladaré a una nueva especificación de relaciones públicas donde @teaP y yo terminaremos de resolver los temas abiertos restantes con respecto a:

• localización
• diseño (particularmente con respecto a los botones Arriba / Abajo)
• hyperscroll / hyperdrag

Tenga en cuenta que el tema de validación se ha resuelto. Con @LucasHaines ' Entrada Validación trabajo que se está programado para WinUI 3.0 y NumberBox liberación de planificación antes de eso, hemos reducido los modos de validación soportados de NumberBox V1 a:

enumeración NumberBoxBasicValidationMode
{
Discapacitado,
InvalidInputOverwritten,
};

Con WinUI 3.0 y el trabajo de validación de entrada co-requisito, buscaremos expandir esa enumeración con los modos de validación IconMessage y TextBlockMessage originalmente planeados en un NumberBox V2.

Ahora voy a terminar con todo nuestro progreso anterior, y publicaré preguntas y solicitaré comentarios según sea relevante. Gracias por seguir con nosotros. 😄

Uf. Se estaba acercando a mí tratando de hacer esto yo mismo.

Jaja Me hubiera gustado seguir trabajando en esto de forma pasiva pero este semestre me ha atropellado. ¡Me alegra ver que se está terminando, lo vigilaré!

¡Confirmación inicial de NumberBox en vivo ahora!

POR FAVOR - Tenga en cuenta que es todavía un trabajo en progreso con el seguimiento de problemas activa tanto en el dev y PM lado de las cosas. Si ve errores o cabos sueltos en general en funciones que aún no se han señalado en ninguno de los enlaces correspondientes, no dude en hacérnoslo saber. 😊

@SavoySchuler , ¿ este comentario, particularmente sobre la visualización de NaN? Gracias.

@SavoySchuler Algunos comentarios sobre el código spec / NumberBox hasta ahora. Con suerte, los comentarios sobre esto también pueden terminar en la especificación / documentación. En general, ¡es genial ver que esto se une!

Paso Frecuencia

Usar la palabra 'Frecuencia' aquí simplemente no me sienta bien. En el control deslizante, TickFrequency tiene sentido porque los ticks se calculan y se muestran en un módulo del rango máximo-mínimo general. Sin embargo, en este control, es solo el tamaño de incremento / paso. Es más un 'StepAmount' o 'StepValue'; mejor aún, solo un 'Paso' similar a 'Mínimo' en lugar de 'Valor mínimo'.

Además, ¿podrá el usuario ingresar un valor que esté fuera del Paso definido?
Por ejemplo, Mínimo = 0, Máximo = 6, Frecuencia de paso = 2. Usar el valor de la flecha hacia arriba será {2, 4, 6} suficientemente justo. Sin embargo, ¿puede el usuario escribir 0,5 como valor válido? ¿O se redondeará a 0 o 2?

Redondeo

¿Cómo se maneja el redondeo matemático? Esto es especialmente importante cuando se ingresan valores de moneda mediante expresiones. Necesitamos poder especificar, o proporcionar, un redondeo personalizado después de calcular una expresión. HalfAwayFromZero es lo que estoy buscando para empezar, pero también se deberían permitir otros modos de redondeo.

Localización

Confirme que NumberBox aceptará cualquier implementación de INumberFormatter / INumberFormatter2 , y continuará haciéndolo en el futuro (así es como se implementa en el código, solo quiero asegurarme de que la especificación también lo indique). Eso debería permitir un control total sobre la localización del texto en comparación con el uso de un CurrencyFormatter / DecimalFormatter existente. ¡Es genial que tengamos una solución para esto!

Ajuste de texto

Editar: Debería leer la especificación completa la próxima vez.

¿Por qué ha creado una nueva propiedad 'IsWrapEnabled'? ¿Es porque cree que el término 'Texto' no se aplica muy bien a un NumberBox?

Además, entiendo que quizás tanto Wrap como WrapWithOverflow se implementan de la misma manera, pero luego solo permiten que ambos valores de enumeración sean equivalentes y describan la funcionalidad en la documentación.

Manejar correctamente los aceleradores de teclado

Asegúrese de que este control admita el uso del acelerador de teclado mejor que el TextBox. Quizás eso no se pueda hacer hasta / si se corrige TextBox, pero # 1435 es realmente un problema para mí que causa muchas soluciones desagradables. El TextBox manejará un pegado 'Ctrl + V' y luego se generará cualquier KeyboardAccelerator. Sin embargo, no hay forma dentro de KeyboardAccelerator para saber que TextBox simplemente hizo lo suyo.

Un pensamiento rápido. ¿Debería haber un modo de ángulo que agregaría el glifo de grados al valor (y cualquier lógica para el giro de 360 ​​°)?

°

¿O este apéndice se manejaría mejor en el futuro con mi propuesta de sufijo para el TextBox # 784?

@mdtauk , Agregar el símbolo de grado sería posible con un INumberFormatter2; esa es otra buena razón por la que esto debe mantenerse genérico. Puede hacer lo que sea necesario para convertir un número en una cadena y devolver la cadena al control.

Para envolver, en realidad para eso es la propiedad IsWrapEnabled ... Necesito leer el final de la documentación la próxima vez.

En pocas palabras, creo que podemos hacer todo lo que desee con la API existente.

@mdtauk , Agregar el símbolo de grado sería posible con un INumberFormatter2; esa es otra buena razón por la que esto debe mantenerse genérico. Puede hacer lo que sea necesario para convertir un número en una cadena y devolver la cadena al control.

Para envolver, en realidad para eso es la propiedad IsWrapEnabled ... Necesito leer el final de la documentación la próxima vez.

En pocas palabras, creo que podemos hacer todo lo que desee con la API existente.

Sé que Min, Max, Wrap lo maneja, pero ¿son los grados lo suficientemente comunes como para tener un modo de ángulo explícito para la caja? Y debería mostrar el símbolo en el TextBox Text, mientras que el valor interno es solo el número.

@teaP Mirando el nuevo Compact SpinButtonMode, ¿sería posible agregar una animación de mostrar y ocultar a los botones de giro superpuestos?

¿También ha considerado agregar Acrylic a esto, para hacer coincidir mejor los ComboBoxes y otros campos de formulario con elementos flotantes?

Editar: solucionaría este problema de visibilidad en el tema oscuro. ¿La intención es hacer coincidir el color enfocado del TextBox o hacer coincidir los colores del tema actual? De todos modos, Acrylic resuelve esto.

@SavoySchuler , ¿ este comentario, particularmente sobre la visualización de NaN? Gracias.

@adrientetar seguro. Cuando NumberBox está vacío, Value se establecerá en NaN (como lo solicitó) y se mostrará PlaceholderText .

@SavoySchuler Algunos comentarios sobre el código spec / NumberBox hasta ahora. Con suerte, los comentarios sobre esto también pueden terminar en la especificación / documentación. En general, ¡es genial ver que esto se une!

Paso Frecuencia

Usar la palabra 'Frecuencia' aquí simplemente no me sienta bien. En el control deslizante, TickFrequency tiene sentido porque los ticks se calculan y se muestran en un módulo del rango máximo-mínimo general. Sin embargo, en este control, es solo el tamaño de incremento / paso. Es más un 'StepAmount' o 'StepValue'; mejor aún, solo un 'Paso' similar a 'Mínimo' en lugar de 'Valor mínimo'.

He compartido estos comentarios con @MikeHillberg y estamos hablando de ello ahora. Para ser autodocumentado entre todas las otras propiedades aquí, estamos considerando algo como "SpinButtonStep" si este razonamiento es suficiente justificación para desviarse. Yo lo haré saber. ¡Gracias por plantear el punto!

Además, ¿podrá el usuario ingresar un valor que esté fuera del Paso definido?
Por ejemplo, Mínimo = 0, Máximo = 6, Frecuencia de paso = 2. Usar el valor de la flecha hacia arriba será {2, 4, 6} suficientemente justo. Sin embargo, ¿puede el usuario escribir 0,5 como valor válido? ¿O se redondeará a 0 o 2?

El usuario puede ingresar cualquier entrada numérica o legalmente formulada que desee. Consulte la sección de formato para ver un ejemplo sobre cómo usar la propiedad NumberFormatter para luego forzar esa entrada a su formato configurado.

SpinButton solo aumentará o disminuirá ese valor por el tamaño de paso definido de SpinButton (el nombre de la API ahora está pendiente). Así que asegúrese de configurar el formato y un tamaño de paso que funcionen bien juntos.

La estrategia de redondeo utilizada se define a través de su formato . Para exponer el ejemplo de DecimalFormatter, aquí hay un ejemplo de una propiedad de redondeo que puede configurar.

Redondeo

¿Cómo se maneja el redondeo matemático? Esto es especialmente importante cuando se ingresan valores de moneda mediante expresiones. Necesitamos poder especificar, o proporcionar, un redondeo personalizado después de calcular una expresión. HalfAwayFromZero es lo que estoy buscando para empezar, pero también se deberían permitir otros modos de redondeo.

El redondeo se gestiona mediante formateo . A continuación, se muestra un ejemplo de una propiedad de redondeo que se puede establecer para DecimalFormatter. Agregaré un ejemplo en las Directrices para ayudar a aclarar esto. Gracias de nuevo. 😊

Localización

Confirme que NumberBox aceptará cualquier implementación de INumberFormatter / INumberFormatter2 , y continuará haciéndolo en el futuro (así es como se implementa en el código, solo quiero asegurarme de que la especificación también lo indique). Eso debería permitir un control total sobre la localización del texto en comparación con el uso de un CurrencyFormatter / DecimalFormatter existente. ¡Es genial que tengamos una solución para esto!

Esa es la intención de la implementación actual. En cuanto a las garantías de preparación para el futuro, NumberBox seguirá teniendo una solución para las necesidades de localización y formato. Por ahora y en el futuro previsible, lo tenemos implementado.

Ajuste de texto

Editar: Debería leer la especificación completa la próxima vez.

~ ¿Por qué ha creado una nueva propiedad 'IsWrapEnabled'? Esto va en contra de la convención TextBox / XAML de usar TextBlock.TextWrapping y TextWrapping Enum. ¿Es porque cree que el término 'Texto' no se aplica muy bien a un NumberBox? ~

~ Además, entiendo que quizás tanto Wrap como WrapWithOverflow se implementan de la misma manera, pero luego solo permiten que ambos valores de enumeración sean equivalentes y describan la funcionalidad en la documentación. Crear una nueva propiedad aquí solo significa que necesitamos nuevos convertidores de valor, etc., creo que no hay razón para romper una convención existente. ~

Manejar correctamente los aceleradores de teclado

Asegúrese de que este control admita el uso del acelerador de teclado mejor que el TextBox. Quizás eso no se pueda hacer hasta / si se corrige TextBox, pero # 1435 es realmente un problema para mí que causa muchas soluciones desagradables. El TextBox manejará un pegado 'Ctrl + V' y luego se generará cualquier KeyboardAccelerator. Sin embargo, no hay forma dentro de KeyboardAccelerator para saber que TextBox simplemente hizo lo suyo.

NumberBox contiene un TextBox y agrega propiedades y configuraciones en la parte superior. Etiquetaré a @jevan, ya que podría tener una comprensión más completa, pero mi intuición es que esto podría necesitar ser corregido en el nivel de TextBox.

Considerándolo todo, ¡comentarios increíbles @robloo! ¡Aprecio el tiempo que se tomó para ayudar a asegurarnos de que seamos tan completos y completos con V1 NumberBox como podamos! Por favor, avíseme si tiene más preguntas. 😊

@mdtauk

Un pensamiento rápido. ¿Debería haber un modo de ángulo que agregaría el glifo de grados al valor (y cualquier lógica para el giro de 360 ​​°)?

°

¿O este apéndice se manejaría mejor en el futuro con mi propuesta de sufijo para el TextBox # 784?

Hasta ahora, NumberBox no admite la visualización de ningún carácter no numérico (ya que incluso los caracteres de fórmula se eliminan al evaluar las expresiones).

Creo que su propuesta para el # 784 es, con mucho, la más completa para nuestra plataforma. Si no se actúa sobre esa propuesta, me parece una característica adecuada de la V2, NumberBox, como alternativa.

Ya estamos planeando lanzar una V2 junto o poco después de WinUI 3.0, ya que dos de los modos de validación de entrada altamente solicitados para NumberBox están bloqueados al necesitar WinUI 3.0. Así que abriré un problema de V2 después de que V1 se active y trataré de asegurarme de tener esto en cuenta allí también.

Para ser autodocumentado entre todas las otras propiedades aquí, estamos considerando algo como "SpinButtonStep" si este razonamiento es suficiente justificación para desviarse

Veo que StepFrequency es lo que usa Slider, así que creo que estábamos tratando de ser consistentes con esa terminología. No olvide que no es solo para los botones giratorios, sino también para los valores de cambio del proveedor de arrastre y UIAutomation.

@robloo y @mdtauk , debería haber leído más en el hilo antes de responder sobre °. No creo que actualmente se admita que este símbolo se muestre dentro de Text ya que NumberBox mantiene Text y Value estrechamente sincronizados con el fin de permitirle a los desarrolladores que puedan captar cualquier tipo que necesite sin la sobrecarga de conversión. No vi una manera de lograr esto a través de las propiedades de formato disponibles, pero si conoce una manera, ¡hágamelo saber!

Ahora nos enfrentamos a la versión V1, pero para la V2 echaremos un vistazo nuevamente a los caracteres prefijos / sufíficos / especiales. Mientras tanto, creo que la propuesta de @mdtauk para el # 784 es la solución más completa que se ha presentado para la plataforma hasta ahora. Por favor, apruebe esa propuesta y comente si esta es una característica que necesita.

@adrientetar , scroll-to-change llegó a V1 pero arrastrar para cambiar se retrasó a V2. Como todavía estamos buscando completar esas funciones, aún no hemos llegado a discutir su solicitud de que Shift + Up / Down paso en unidades de 10 y Ctrl + Shift + Up / Down paso en unidades de 100.

¿Podría darme más contexto sobre los escenarios en los que usaría esta función? ¿Cómo saben sus usuarios que está disponible? ¿Puede ayudarme a comprender por qué esto debería ser predeterminado (o al menos disponible) en todos los NumberBoxes en comparación con la implementación local en su solución?

@SaboyaSchuler

Muchas gracias por sus comentarios.

Para ser autodocumentado entre todas las otras propiedades aquí, estamos considerando algo como "SpinButtonStep" si este razonamiento es suficiente justificación para desviarse

Me gusta mucho esa terminología, sin embargo, me perdí que Slider ya tiene la propiedad StepFrequency. Dado que ese es el caso, no tiene sentido desviarse de la convención como dijo @jevansaks .

El redondeo se gestiona mediante formateo. A continuación, se muestra un ejemplo de una propiedad de redondeo que se puede establecer para DecimalFormatter.

Digamos que el usuario ingresa "1/3" en el NumberBox. ¿Es correcta la siguiente secuencia:

• Al perder el enfoque / ingresar, se evaluará la expresión y se calculará el valor doble de 0.33333333 ... 34
• El 0.33333333 ... 34 se pasará al DecimalFormatter
• El 0.33333333 ... 34, dependiendo de su configuración, podría redondearse a "0.30" (solo para ser difícil)
• Ese valor "0.30" se colocará en el cuadro de texto para mostrarlo al usuario.
• El doble Value ahora es {0.33333333 ... 34} y el Text ahora es "0.30"
• Leer el doble Value NO devolverá el número redondeado que se muestra en Text
  (¿O el valor con formato decimal se vuelve a analizar de alguna manera después de la conversión a una cadena? ¿Y luego se vuelve a evaluar todo?)

También me preocupa que las propiedades Value y Text estén tan estrechamente acopladas internamente. La documentación no define este acoplamiento y si no está altamente estructurado, las dependencias bidireccionales nunca son divertidas.

Todavía no estoy seguro de cómo se implementa esto internamente, pero parece que la forma correcta de hacerlo sería tratar el valor doble como la única propiedad real. El texto es solo una versión formateada de Value. Luego, el desarrollador podrá formatear el valor como quiera que se muestre en el TextBox y la propiedad Text (obtendríamos el símbolo de grado o los símbolos de pies / pulgadas solicitados previamente). Eso no sería difícil de hacer si todo ya está impulsado internamente por la propiedad Value. La entrada textual del usuario no se guarda de todos modos y solo se usaría para recalcular el valor que luego se formatea nuevamente para su visualización.

La secuencia debe ser:

• Entrada textual del usuario -> Analizador -> Valor doble -> Formato -> Texto

Cambiar el valor de Texto del código sería como si el usuario ingresara algún texto. Cambiar el valor directamente solo pasaría por el paso de formato y texto.

Para mantener el redondeo preciso entre la secuencia Valor y Texto sería más como:

• Entrada textual del usuario -> Analizador -> Valor -> Redondeo -> Valor -> Formato -> Texto

Editar: para implementar el redondeo en el analizador de expresión / entrada y el motor de evaluación (como se llame), probablemente deba agregar una nueva propiedad para definir el algoritmo como RoundingAlgorithm . Esa enumeración ya está definida en Windows.Globalization.NumberFormatting como señaló. INumberFormatter2 debe usarse para formatear y nada más; nuevamente, mantenga las etapas desacopladas entre el cálculo y el texto finalmente mostrado.

@adrientetar , scroll-to-change llegó a V1 pero arrastrar para cambiar se retrasó a V2. Como todavía estamos buscando completar esas funciones, aún no hemos llegado a discutir su solicitud de que Shift + Up / Down paso en unidades de 10 y Ctrl + Shift + Up / Down paso en unidades de 100.

¿Podría darme más contexto sobre los escenarios en los que usaría esta función? ¿Cómo saben sus usuarios que está disponible? ¿Puede ayudarme a comprender por qué esto debería ser predeterminado (o al menos disponible) en todos los NumberBoxes en comparación con la implementación local en su solución?

Uno debe ser un incremento mayor y el otro debe ser más pequeño, similar a empujar áreas / objetos seleccionados en aplicaciones de Adobe

¿Podría darme más contexto sobre los escenarios en los que usaría esta función?

Es genial cuando desea cambiar un valor con implicaciones visuales (por ejemplo, la rotación de un objeto) pero no está seguro de qué tan lejos desea llegar. Por eso es bueno para el diseño visual.

¿Cómo saben sus usuarios que está disponible?

Es solo una característica que tienen las herramientas modernas, por ejemplo, Adobe XD, Framer ...

¿Puede ayudarme a comprender por qué esto debería ser predeterminado (o al menos disponible) en todos los NumberBoxes en comparación con la implementación local en su solución?

Creo que es bueno tener esto cuando estás en un dispositivo táctil, es una forma conveniente, tocar y arrastrar, para ajustar un valor dado (algo así como el widget de selección de tiempo del teléfono en el que presionas y arrastra para desplazar los valores).

Uno debe ser un incremento mayor y el otro debe ser más pequeño, similar a empujar áreas / objetos seleccionados en aplicaciones de Adobe

RangeBase tiene propiedades SmallChange y LargeChange. Nosotros en BeLight Software en nuestra versión de NumericUpDown derivamos de RangeBase y cambiamos el valor por SmallChange usando los accesos directos ArrowUp y ArrowDown, y por LargeChange usando los accesos directos PageUp y PageDown

Y no estamos solos aquí
https://help.syncfusion.com/uwp/numeric-updown/gestures
https://docs.telerik.com/devtools/wpf/controls/radnumericupdown/features/navigation

Solo un comentario sobre el teclado numérico del teclado que me vino a la mente durante la llamada comunitaria ...

En la mayoría de las aplicaciones, el "." El botón del teclado todavía está asignado al "." carácter, que es diferente del separador decimal cuando se usa un idioma que no es inglés (por ejemplo, "," en francés). Entonces, cuando presionas el "." en el bloc de notas, escribe un "." personaje.

Algunas aplicaciones (Excel es la más conocida sobre eso) cambian el comportamiento de esta tecla para reinterpretar cualquier pulsación de tecla en el teclado "." como entrada de separador decimal. Es más compatible con el diseño de "calculadora" del teclado.

La aplicación Calculadora también reescribe el "." presione para interpretarlo como un carácter separador decimal.

Debido a que el cuadro numérico podrá funcionar más como una "calculadora", ¿podría el control permitir usar el "." ¿Teclea el teclado como separador decimal? ¿O al menos proporcionar una forma para que el desarrollador agregue esta función sin tener que luchar con filtros y eventos clave?

Quizás una propiedad podría permitir habilitar (si se acepta) o deshabilitar (si se excluye) la función. Como KeyPadDotAsDecimalSeparator="false" ?

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

¡Hola, maravillosa comunidad de WinUI! Gracias sinceramente por ayudarnos a llevar a casa nuestro primer control propuesto por la comunidad para ver el lanzamiento. Sabemos que fue una empresa enorme y que todos ustedes invirtieron una cantidad significativa de tiempo en crear la mejor colección de características V1 que pudimos diseñar juntos.

También sabemos que no todo se incluyó en la versión V1. Algunas configuraciones de validación de entrada muy deseadas dependen del trabajo de las características de WinUI 3.0, algunas necesidades de características deseadas surgieron tarde en la validación / aplicación, y algunas características que sabíamos que se explorarían mejor después del lanzamiento V1.

Estamos buscando terminar nuestro trabajo previsto de la función NumberBox con una versión de WinUI 3. Abrí un problema para recopilar comentarios sobre las funciones necesarias que faltan en V1. Si a NumberBox le falta algo que necesita, asegúrese de dejar un comentario aquí: https://github.com/microsoft/microsoft-ui-xaml/issues/1736