Como ponto de partida, a Telerik tem um https://www.telerik.com/universal-windows-platform-ui/numericbox. Também está disponível em código aberto: https://github.com/telerik/UI-For-UWP/blob/master/Controls/Input/Input.UWP/NumericBox/RadNumericBox.cs.

O que eu gosto deles é a abordagem para a formatação com a propriedade ValueFormat.

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

Verifique também se isso está localizado corretamente. A implementação do Windows Community Toolkit tem algumas deficiências:

A extensão TextBoxRegex com ValidationType = "Decimal" não oferece suporte a todas as culturas de IU. Em vez disso, é corrigido para InvariantCulture. Em inglês, os valores decimais são "10.1234" com um ponto. Em espanhol ou alemão, os valores decimais são escritos "10,1234". A análise do inglês estará correta; no entanto, a entrada do usuário em espanhol ou alemão será apenas "101234" com a parte fracionária perdida.

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

As setas para cima e para baixo devem aumentar ou diminuir o valor em um valor que o dev pode definir, mas o padrão deve ser um int de 1

• os valores min / max envolventes são bons, por exemplo, ao selecionar um ângulo
• capacidade de adicionar um sufixo
• clique na caixa de texto e arraste para cima / para baixo para alterar os valores, Adobe XD tem isso nas entradas de número.

Minha implementação no WinRT XAML Toolkit também oferece suporte para arrastar para cima / para baixo para alterar valores e torna-o muito mais utilizável ao usar o mouse do que clicar em botões em determinados cenários.
https://github.com/xyzzer/WinRTXamlToolkit/tree/master/WinRTXamlToolkit/Controls/NumericUpDown

Olá, @sonnemaf , @ArchieCoder , @robloo , @mdtauk , @adrientetar e @xyzzer! Fui designado para esta proposta.

Em primeiro lugar, obrigado, @sonnemaf , por enviar isso. Eu o mostrei no Microsoft Build 2019 na semana passada e ele recebeu aplausos do público! A resposta da comunidade aqui nos comentários também reflete o entusiasmo que temos de ver o NumberBox acontecer.

Eu li os comentários de todos e atualizei a seção de escopo para refletir as contribuições recebidas. Eu agradeceria se todos pudessem dar uma olhada nesta pequena atualização e me avisar se eu _não_ capturei suas solicitações com precisão , observando que alguns detalhes (como localização de formatação) serão tratados no nível de especificação.

Olá @SavoySchuler ,

Esta semana, estou trabalhando no recurso de acessibilidade em meu aplicativo. Isso seria uma vantagem se a acessibilidade fosse tratada corretamente com o novo controle, por exemplo, o incremento pode ser dito em voz alta em vez de "mais", "menos". O resto parece bom para mim.

Garantir que o narrador seja capaz de ler os valores corretamente para que fique claro o que está acontecendo é importante.

Não tenho certeza se o controlador do Xbox precisará de qualquer toque de foco para garantir que as alavancas analógicas e o D-Pad funcionem corretamente

Correção pequena - arraste para aumentar / diminuir deve funcionar no próprio campo de texto até que seja ativado. IIRC em minha implementação eu tive que colocar alguma sobreposição transparente no topo do campo de texto para habilitá-lo e também esconder o cursor do mouse enquanto arrasto para que as bordas do controle ou tela não limitem a distância de arrasto e que quando você terminar de arrastar e mostro o cursor novamente - ele aparece onde desapareceu pela primeira vez.

@SavoySchuler, você fez uma boa tarefa. Eu posso viver com seu escopo. É bom ter uma calculadora (WinUI 3.0 ou 3.1). Já desenvolvi em vários ambientes desktop (VB6, WinForms, WPF e UWP) e sempre perdi um NumberBox. Finalmente vamos conseguir.

Talvez você também possa adicionar a roda de rolagem do mouse para cima / baixo. O Blend for Visual Studio oferece suporte para isso.

Também adoro Drag-to-change, algo que usei muito no Expression Blend.

Não tenho certeza do que a validação de entrada fará ou não. Será apenas mín. / Máx. Ou também limitará o teclado (letras az, etc)? Ele vai lidar com a colagem de números inválidos?

Eu adoraria ler as especificações completas.

@ArchieCoder , eu ouço você bem alto e claro. A acessibilidade é uma prioridade e é melhor administrada desde o início. Eu comecei uma seção Acessibilidade e contribuições nesta proposta, onde adicionei sua observação.

@mdtauk , ótima pergunta como sempre. Eu adicionei isso à seção Acessibilidade e entradas como uma observação para examiná-lo.

@xyzzer , você está certo. Ao reorganizar a lista de escopos, agrupei os botões Para cima / Para baixo e arrastei para alterar conforme a funcionalidade relacionada. Ao reler, parecia que eu estava sugerindo que arrastar para alterar fosse um recurso dos botões. Mudei arrastar para alterar para sua própria seção para fornecer clareza.

@sonnemaf , incrível. Vou postar um link para a especificação assim que for aberto, o que provavelmente será hoje ou na próxima semana. Por favor, sinta-se encorajado a se juntar a mim para escrevê-lo! Até então, adicionei scroll-to-change ao osciloscópio aqui.

Todos , com uma nota sobre o suporte da calculadora - acredito no valor. Estou trabalhando com minha equipe para descobrir se é algo que devemos modularizar, caso a funcionalidade possa ser aproveitada ainda mais na plataforma. Além disso, há a questão de até onde podemos ir com o suporte à calculadora? A ordem simples de operações em + - / * serviria? Ou algo mais abrangente, como conectar-se a algum tipo de serviço wolfram alpha? Explorar uma rota modular talvez nos permita começar com o caso mais básico, sem bloquear a oportunidade de uma forma mais abrangente de suporte à calculadora. Eu estaria interessado em saber as necessidades de todos aqui.

Para validação de entrada, tenho a mesma pergunta. Min, max, sem letras e sem colagem inválida cobrem isso?

Acho o recurso da calculadora fofo, mas, na prática, como esse recurso pode ser descoberto por um usuário? Haverá uma pequena dica sobre o widget sobre isso?

@ArchieCoder , você acha que um texto de espaço reservado personalizado esmaecido no NumberBox pode alertar o usuário de forma adequada? Nesse caso, imagino que uma string como "a + b - c" ou "digite a equação" possa ser uma forma sucinta de fornecer essas informações. O Excel também criou um padrão com "=" aparecendo no início de uma equação. Talvez quando o usuário clica em NumberBox, um "=" imutável aparece na frente que o usuário digita atrás?

Temos o ToolTip ou o TeachingTip mais pesado para orientação no nível do aplicativo em que poderíamos pedir aos desenvolvedores que confiem, mas minha forte preferência seria resolver isso dentro do próprio NumberBox.

Estou interessado em ouvir sua opinião aqui!

O marcador de posição seria de fato uma boa maneira, desde que outro contexto não seja necessário devido à limitação de espaço. Eu acho que a largura de uma NumberBox será menor do que uma caixa de texto, por exemplo.

A menos que o controle suporte números anuláveis ​​- ele sempre mostrará um valor,
portanto, não haverá espaço para uma string de espaço reservado dentro dele.

Na sexta-feira, 17 de maio de 2019 às 10:14 ArchieCoder [email protected]
escreveu:

O marcador de posição seria de fato uma boa maneira, desde que outro contexto não seja
necessário devido à limitação de espaço. Eu acho que a largura de uma NumberBox
ser menor do que uma caixa de texto, por exemplo.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMAL7LUOVPIM55PYO4LPV3RWPA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVVKWTI#issuecomment-493529933 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AANMBMBKHP7GP5WUHLPWNZLPV3RWPANCNFSM4HA4PBNA
.

@ArchieCoder , olhando como os exemplos de @sonnemaf (obrigado novamente por eles), qualquer NumberBox que não seja largo o suficiente para exibir o texto de espaço reservado para "a + b - c" também não seria largo o suficiente para criar uma experiência de usuário recomendada para inserir equações em. Nesse sentido, imagino que essa opção de solução ainda seja viável para esse fim. No entanto, acho que você está entrando em uma área que ainda não abordamos - cenários em que queremos um NumberBox compacto / apenas um número simples a ser inserido. Eu imagino que o suporte da Calculadora precisaria de uma API para desativá-lo, caso em que não precisamos nos preocupar com texto de espaço reservado longo nem quebrar as restrições de espaço mínimo que a forma de equação de NumberBox precisaria de outra forma - embora alguma opção de texto de espaço reservado para o modo compacto ainda possa ser boa , mesmo que seja apenas para algo como "#" ou "eg 2".

@xyzzer , obrigado por trazer isso à tona. Vamos nos certificar de que essa seja a experiência certa para o usuário primeiro e podemos descobrir a implementação a partir daí! Ainda não há necessidade de limitar nossa busca pela experiência do usuário _reta_ devido a limitações técnicas que podemos mitigar. : relaxado:

Tenho uma pergunta de alta prioridade para todos:

Você prefere ter um controle NumberBox que consolida esses recursos independentemente de um TextBox padrão ou prefere ter esses recursos integrados em TextBox como recursos nativos que podem ser ativados por meio de APIs ou InputScope?

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

É uma mudança significativa colocar tudo isso em um controle TextBox.

A validação dos caracteres inseridos.

Usando o layout de teclado correto com o InputScope

Os diferentes comportamentos do mouse.

A capacidade de exibir botões giratórios como na versão FabricWeb.

Se todas essas coisas pudessem ser adicionadas, com um enum de comportamento para definir o tipo de TextBox, sem causar um impacto em todos os outros que usam um TextBox em seus aplicativos, então, ótimo.

E você pode até considerar a combinação de outros comportamentos de TextBox, como um ícone que pode representar uma pesquisa ou um calendário que atua como um botão. Máscaras para coisas como endereços IP ou URLs que exibem "http: //" no estilo de texto de espaço reservado conforme você insere o texto ao lado dele.

FabricWeb tem uma grande variedade com seus TextFields.

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

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

Eu definitivamente iria com um próprio controle NumberBox em vez de assar todos esses recursos em um controle TextBox (semelhante a como também existe um controle PasswordBox e não um TextBox com uma "senha" de modo de entrada).

O controle NumberBox será muito mais do que um simples campo de entrada para endereços IP, por exemplo. Ele virá com sua própria acessibilidade / recursos exclusivos de rolar e arrastar, suporte para calculadora, ... tudo o que o distinguirá bastante de como eu normalmente usei um TextBox até agora (casos tão simples quanto especificar um nome de representação para um grupo De dados). E como ainda mais recursos / requisitos especiais serão propostos para o controle NumberBox, podemos manter uma separação bonita e limpa entre NumberBox e TextBox.

Esse spearation também apareceria na documentação e no layout xaml do aplicativo (NumberBox mais facilmente detectável do que, digamos, um TextBox com um monte de propriedades com uma delas especificando o modo de entrada). Em vez de ler a documentação do TextBox sobre seus recursos de entrada numérica, essa parte seria boa e organizada em uma documentação de controle específica da NumberBox (assim como a PasswordBox hoje).

Com relação à aparência do controle, acho que a unidade / sufixo poderia ser exibida à parte com um tamanho menor / cor dessaturada para que se diferencie do próprio valor:

Quando o mouse passa sobre o controle, as setas para cima / para baixo podem desaparecer no lugar da unidade:

Uma alternativa são os controles numéricos da figma.com, ao passar o mouse sobre a unidade, você pode clicar e arrastar para a esquerda / direita para alterar o valor.

Esquerda / direita é interessante porque é mais fácil mover o mouse para a esquerda / direita do que para cima / para baixo (você não precisa levantar o pulso).

Outras coisas:

• Ao clicar na área de texto desfocada, deve-se selecionar todo o conteúdo. para que clique em + digite um valor + insira altere o valor
• Shift + Clique em uma seta ou Shift + Para cima / Para baixo quando o foco aumenta ou diminui em 10 (acho que esse valor também deve ser personalizável).
• Não acho que as setas para cima / para baixo sejam muito úteis para o usuário. Se o usuário deseja um valor preciso, ele apenas o digitará; se não tiver certeza do valor que deseja, pode visualizar um espectro de alterações de valor clicando e arrastando. Portanto, as setas para cima / para baixo provavelmente devem ser pelo menos opcionais.

@adrientetar colocar uma indicação da unidade dentro do controle cria muitos problemas extras:

• localização
• acessibilidade
• selecionando
• colando
• conversões

Tudo isso seria evitado colocando-o no cabeçalho, na descrição ou em um TextBlock separado.

Eu iria para um controle NumberBox separado com uma propriedade Value e talvez não uma propriedade de texto. O valor deve ser um duplo para que possamos vinculá-lo aos dados (x: vincular). Não tenho certeza se também devemos oferecer suporte ao tipo de dados Decimal e como.

O suporte para números anuláveis ​​é uma OBRIGAÇÃO, eu acho (obrigado @xyzzer). A propriedade Value deve ser Nullabletipo de dados. Não tenho certeza se isso causará problemas de vinculação ao vinculá-lo a um valor não anulável.

Embora a composição tenha benefícios e tenha um comportamento vinculado para os numerados
modo poderia ser implementado e anexado a um TextBox - acho que faria
é desnecessariamente complicado e limitado.
Alguns dos maiores problemas que você provavelmente enfrentaria com a implementação estão relacionados a
acessibilidade. Acredito que suporte alguns dos padrões de acessibilidade -
você precisa assar na implementação de certas interfaces em TextBox
isso tornaria confuso se um TextBox não estivesse em um modo de caixa numérica.

Na segunda-feira, 20 de maio de 2019 às 2h33 Fons Sonnemans [email protected]
escreveu:

O suporte para números anuláveis ​​é OBRIGATÓRIO (obrigado @xyzzer
https://github.com/xyzzer ). A propriedade Value deve ser Nullable
tipo de dados. Não tenho certeza se isso causará problemas de vinculação ao vinculá-lo a
um valor não anulável.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMBGVIQ36CDPQO6CWKLPWJV55A5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVYHVVA#issuecomment-493910740 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AANMBMBTHT2UXOAGRTEDF7LPWJV55ANCNFSM4HA4PBNA
.

Tenho mais uma pergunta para todos. Você precisa / prefere validação de entrada ou mascaramento?

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

A validação é essencial, pois você não pode adicionar um número a uma string. E os operadores matemáticos precisam ser avaliados e processados.

Ele precisa de uma mensagem de erro exibida se não puder calcular, sobre a qual não tenho muita certeza.

O mascaramento seria útil, mas provavelmente deve ser integrado à própria caixa de texto, para que a entrada de URL e e-mail possa ser tratada. NumberBox seria números de telefone, IPs, etc.

Não acho que um NumberBox deva ser usado para números de telefone ou IPs. Parecem mais extensões simples de mascaramento / filtragem para um TextBox. Um NumberBox é algo que você deseja usar para inserir um único valor.
Talvez haja um potencial para ter um controle de caixa de moeda, mas também acho que deveria ser um controle separado diferente de TB ou NB.

@xyzzer Tornar a NumberBox mais flexível para qualquer tipo de entrada numérica parece uma boa ideia para mim. Ele pode ser derivado de um controle TextBox e esse controle pode ter uma propriedade Mask, bem como outras propriedades comportamentais.

Algumas dessas propriedades no NumberBox podem ser:

• Mostrar / ocultar botões giratórios
• Permitir incremento e decremento de valores
• Permitir cálculo de valores
• Permitir entrada mascarada
• Máscaras localizadas, como números de telefone ou endereços IP

As propriedades que podem ser adicionadas ao TextBox podem ser:

• Uma propriedade Mask - uma string XAML para definir um formato personalizado ([email protected]), bem como máscaras localizadas, como códigos postais / CEP
• Exibição de texto de prefixo / sufixo (_http: // _ como um prefixo, por exemplo)
• Botão de ação mostrar / ocultar - com um ícone e uma propriedade de evento de clique
• Ícone (a caixa de pesquisa da IU do Fabric exibe seu ícone à esquerda e se anima quando a caixa recebe o foco)

Essas imagens são do Fabric UI TextField - e ele suporta todos esses diferentes estados - devemos ter como objetivo trazer os controles do Fluent WinUI 3.0 para a paridade sempre que possível

Os botões do Fabric UI Spinner são muito pequenos para o toque, então eu os formataria de forma diferente para que os botões para cima e para baixo fiquem lado a lado, não empilhados uns sobre os outros

Para mim, a validação é OBRIGATÓRIA e o mascaramento é uma boa opção. Nunca gostei de mascarar; é muito rígido.

@rudyhuyn propôs no repositório da Calculadora do @mdtauk comentou sobre isso.

Você pode abrir um pop-up da calculadora na caixa de números semelhante a um selecionador de data / hora / calendário.

Semelhante ao que @xyzzer disse acima. Existe uma diferença fundamental entre um número e uma string que contém uma sequência de dígitos.
A melhor maneira que ouvi sobre a diferença descrita é que você pode realizar operações de multiplicação e divisão em um número. Você pode pedir a metade de um número e dividir por dois. Você não pode pedir meio CEP ou um "número de telefone" e obter algo significativo.

Misturar um NumberBox que tenha recursos matemáticos com funcionalidade para capturar outros valores compostos por dígitos também pode levar a outros problemas.
"Números de telefone" podem começar com zeros à esquerda (ou um sinal de mais) e aí eles têm um significado. Por um _número_ eles não querem e seriam despojados.
"números de telefone" geralmente também são formatados com colchetes e hifens. Quando processados ​​como operações matemáticas, podem facilmente acabar sendo interpretados como requerendo multiplicação e subtração.

Permitir o mascaramento da mesma forma que TextBox e como forma de formatação de entrada corre o risco de confundir a diferença entre NumberBox e TextBox e quando cada um deve ser usado.

A validação simples quando a validação vier para a plataforma , isso não resulte em maneiras de ter métodos de validação conflitantes ou algo que poderia facilmente acabar levando os desenvolvedores a espalharem sua validação para vários locais .

Eu manteria a validação apenas com base nestas propriedades:

• Valor máximo
• MinimumValue
• AllowDecimalPlaces

Separadamente, deve haver indicação de

• saída inválida de cálculos
• como lidar com um valor inserido / colado / calculado e o que é usado em uma ligação. É necessário exibir o cálculo ou valor inválido para mostrar que é inválido, mas isso não pode ser passado para nenhuma propriedade de apoio,

As máscaras precisariam de um recurso visual para deixar claro o que é necessário, ao passo que as entradas de cálculo básicas não seriam usadas junto com as entradas mascaradas.

Os controles de texto do Fabric Web parecem lidar com isso muito bem - mas é claro que o escopo para o NumberBox é separado para ajuste geral e melhorias finais no controle TextBox padrão.

Os botões giratórios (e o menu desdobrável Calculadora opcional, talvez) são as únicas coisas visuais que parecem específicas de um NumberBox.

Quanto às propriedades, talvez se os botões para cima e para baixo do teclado estiverem habilitados para alterar o valor - um valor de Etapa pode ser incluído para que você possa escolher quanto aumentar ou diminuir ao pressionar a tecla.

@mdtauk , gosto do valor Step , mas não apenas ao pressionar a tecla. Também em rolagem e botão para cima / para baixo.

@sonnemaf Claro, o Step é bom para algo binário como o tique da roda do mouse, pressionamento de tecla ou tecla pressionada. Talvez a distância arrastada para longe da caixa pudesse aumentar a quantidade de passos?

Então, StepMinimum e um StepMaximum, talvez?

Então, StepMinimum e um StepMaximum, talvez?

Não tenho ideia do que esses valores podem se relacionar ou o que esperar deles.
Se o objetivo de "Etapa" é definir incrementos, chame-o de "Incremento".

Isso permitiria que Max:100 Min:0 Increment:10 permitisse que apenas os valores 0, 10, 20, 30, 40, 50, 60, 70, 80, 90 e 100 fossem especificados.

Fazer com que a quantidade de passo / incremento varie com base na distância arrastada pode levar a alterações de valor imprevisíveis. Se o objetivo desse controle é facilitar a especificação de valores numéricos, então, se o valor começar a mudar em quantidades variáveis, eu provavelmente acharia isso muito frustrante, o que anularia o objetivo subjacente de ter um controle dedicado para torná-lo mais fácil.

@mrlacey Eu uso Step porque é a propriedade nomeada para o controle deslizante e as barras de progresso, mas o incremento pode ser usado se preferir. O valor aumenta e diminui, desde que o incremento não seja confundido com apenas um aumento no valor.

Existe uma proposta de clicar e arrastar para cima ou para baixo para aumentar ou diminuir o valor. Se o usuário espera que o valor mude mais rápido, quanto mais para cima ou para baixo você arrasta, ter um valor Stap Min e Max permitiria ao desenvolvedor controlar isso conforme o delta muda. Portanto, uma pequena distância de arrasto pode ser de 0,1 ou 1 - mas arrastar ainda mais pode mudar em passos de 5 ou 10, por exemplo.

Não estou dizendo que a distância de arrasto tem que mudar a velocidade da mudança de valor - apenas que é uma ideia que pode ser útil, se parecer natural e der ao usuário algum senso de confiança e controle.

Feedback incrível, pessoal! Abri uma especificação e RP para começar a trabalhar os detalhes.

@KevinTXY se juntará a mim como desenvolvedor para este controle. Manteremos a conversa de requisitos em andamento aqui e iniciaremos a conversa específica de API / exemplo no PR.

Sinta-se encorajado a se juntar a mim para escrever as especificações.

A especificação do TeachingTip é um exemplo completo de como será uma especificação finalizada. O esboço principal será:

• Descrição
• Exemplos para cada API / recurso
• Diretrizes
• API (IDL)

Ótimas ideias, gosto de para onde tudo isso está indo. Adicionando meus dois centavos:

• Sem dúvida, acho que este deve ser um NumberBox separado em vez de integrado com TextBox. Além disso, há muitos recursos bons discutidos aqui, mas também devemos manter o NumberBox leve. Portanto, proponho derivar uma CalculatorBox ou algo semelhante de NumberBox e que pode ter as entradas avançadas "2 + 3" ou um botão para abrir uma calculadora.
• A localização precisa ser bem pensada nas especificações com antecedência. Além disso, há casos em que você deseja substituir o local da IU. Portanto, definir uma propriedade NumberformatInfo ou CultureInfo pode ser muito útil. Por exemplo, em alguns aplicativos, tanto um valor estrangeiro quanto um valor local são rastreados. Cada um pode potencialmente ter um formato diferente.
• O controle precisa suportar a movimentação de uma casa decimal. Isso é mais complicado do que simplesmente validar um formato em cada texto alterado. Cada entrada de caractere precisa ser rastreada e a casa decimal anterior substituída conforme necessário.
• Quaisquer setas de incremento / decremento devem ser configuráveis ​​para desligar para apenas ter uma caixa de entrada simples - novamente, precisamos de um controle leve aqui para os casos em que é necessário como parte de outros controles.
• Outra coisa que não foi discutida é que precisamos idealmente oferecer suporte a vários tipos - Decimal, Inteiro e potencialmente Longo, Duplo, etc ... Isso pode mudar fundamentalmente muitas coisas e eu ainda não pensei muito sobre isso .
• O valor definitivamente precisa ser anulável. Um valor não definido é diferente de zero.
• Outra ideia que não é crítica é permitir que a precisão decimal seja especificada para os tipos decimal, double ou float.

Tenho certeza que mais ideias virão. Estou ansioso para ler as especificações!

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

Eu tenho a especificação / PR preenchida com APIs e exemplos para cada um. Acho que abordei a formatação de acordo com suas especificações com um enum para tipos básicos predefinidos (ainda em andamento), bem como uma propriedade de formatação personalizada que substituirá os tipos predefinidos, se configurada.

Por favor, verifique-o e deixe-me saber se não resolver suas preocupações ou se pode ser adicionado ou melhorado. Aceitarei solicitações de pull que contribuam com as especificações solicitadas aqui.

• A validação é considerada uma obrigação. Eu prescrevi esse controle para derivar de TextBox para obter o mascaramento e outras propriedades de suporte gratuitamente.

• Para preocupação de @mrlacey , adicionei uma API para habilitar / desabilitar a remoção de zeros à esquerda que pode ser usada em conjunto com a string de formato personalizado para habilitar cenários para entrada de string numérica personalizada (observando que os números de telefone internacionais e endereços IP já estão na lista de possíveis tipos de formato básico).

• Isso combinado com a capacidade de habilitar / desabilitar o suporte à calculadora, para mim, acerta a interseção de um controle que pode ser leve para valores / strings numéricos, mas também oferece suporte suficiente para cálculo e personalização. Acredito que a sucinta dos exemplos destaca isso, mas estou interessado em ouvir de quem pensa que isso tornaria o controle em potencial mais complicado de usar.

• @sonnemaf Agradeço a novidade e a intuitividade do ícone> exemplo da calculadora pop-up. Para mim, isso deriva, por exemplo, do conceito de CalendarDatePicker e poderia ser uma excelente consideração para um recurso V2, a menos que haja um forte incentivo de todos aqui para que ele seja considerado para V1?

Uma calculadora pop-up pode fazer sentido se houver coordenação com o esforço de código aberto da Calculadora. Tanto para consistência na aparência do Flyout da Calculadora, mas também no mecanismo por trás dele.

Não tenho certeza se este é o lugar para postar esta imagem, mas aqui estão os designs para os vários estados que estão de acordo com as especificações.

A imagem está na escala de 200%

@mdtauk qual é o propósito de suas maquetes?

Qual estado cada imagem tenta mostrar? Sem que você esclareça isso, podemos fazer suposições que são diferentes das suas.

Pretende-se que sejam referências perfeitas em pixels?

Você pode apontar onde algo em suas imagens difere do padrão da plataforma ou do controle de base para que fique claro o que (se houver alguma coisa) você está adicionando ou alterando.

@mrlacey Eu poderia fazer uma análise mais completa se isso fosse útil? Eu estava apenas tentando ilustrar alguns dos exemplos mencionados nas especificações.

O objetivo deles é tentar ilustrar como esses controles poderiam ficar com os vários elementos de controle propostos, como prefixo, sufixo, máscaras, botões para cima e para baixo. Eles são extrapolados dos designs de controle FabricWeb, mas usando elementos XAML como o FocusReveal e controle de dimensionamento para os botões.

Os exemplos mostram Resto - Foco - estado Desabilitado

A calculadora popup seria um ótimo recurso para V2.

Não tenho certeza de onde colocar minhas observações. Devo fazer um RP de acordo com as especificações ou posso continuar escrevendo minhas ideias sobre esta edição?

Inteiro

Um valor Integer para NumberBoxFormatType seria útil?

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

Língua

Você usaria o idioma para especificar a moeda, símbolos de agrupamento de dígitos decimais?

No próximo exemplo, o idioma é definido como nl-NL. Isso significa que o Prefixo é o símbolo do Euro, o símbolo decimal é uma vírgula com 2 decimais depois e o agrupamento de dígitos é um ponto? A moeda negativa tem um sinal de menos na frente e nenhum parêntese como nos EUA.

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

Isso é suficiente porque há muitas opções de formato de número e moeda no Windows.

Propriedade ou propriedades de valor

Precisamos de uma propriedade Value e qual seria o tipo (numérico). Eu o usaria para vinculá-lo aos dados. Deve ser duplo, decimal ou int. Precisamos de suporte anulável (duplo ?, decimal ?, int?). Não quero usar a propriedade Text do controle TextBox herdado para ligação de dados. Precisamos de suporte para Decimal também, o dobro não é suficiente.

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

E se a propriedade Salário do Funcionário for Anulável(decimal?). Precisamos da propriedade de dependência ValueNullableDecimal. O SelectedDate do controle DatePicker é um valor anulável. Anulável é um problema, especialmente com vinculação de dados.

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

Mesma coisa com MinValue e MaxValue. Eles agora são inteiros na especificação, mas não deveria ser um duplo ?.

@sonnemaf porque a especificação diz que o controle é para qualquer coisa onde dígitos podem ser inseridos, eu acho que isso significa que trata o "Valor" como texto e depende do código de consumo para converter conforme necessário. Não é o ideal, mas mesmo que houvesse uma propriedade Value longa ou flutuante, ainda haveria muitas ocasiões em que seriam necessárias conversões.
É melhor do que sobrecargas para cada tipo numérico.
Depois, há coisas para as quais o controle está sendo projetado e que não podem ser convertidos em um tipo "numérico", como código postal dos EUA, número de telefone ou endereço IP. Para esses tipos de valores, obter o texto parece ser a melhor (única) opção.
Acho que é mais simples (pelo menos na versão inicial ter uma maneira de acessar o valor inserido e depender de conversores quando necessário. Posso ver um lugar para uma coleção de auxiliares (ou subclasses) chegando ao kit de ferramentas inicialmente e, em seguida, alguns dos sendo incorporados ao controle principal com base no feedback.

É necessária uma propriedade Language ? Por que não seria o mesmo que UILocale? Pode haver boas razões, mas parece que isso deve ser configurável pelo usuário (no nível do sistema operacional) e dar a capacidade de especificar um formato específico pode levar a mais problemas para os desenvolvedores quando o formato não corresponde a outro lugar ou ao que o usuário o aplicativo deseja. Pensando bem: e se alguém colar um valor em um formato diferente?

@mdtauk qual é o propósito de suas maquetes?

Qual estado cada imagem tenta mostrar? Sem que você esclareça isso, podemos fazer suposições que são diferentes das suas.

Pretende-se que sejam referências perfeitas em pixels?

Você pode apontar onde algo em suas imagens difere do padrão da plataforma ou do controle de base para que fique claro o que (se houver alguma coisa) você está adicionando ou alterando.

@mrlacey É esse o tipo de coisa que você queria?

@mdtauk é um pouco melhor, pois explica um pouco do que você está tentando mostrar.

A questão subjacente ainda permanece: qual é o seu objetivo em mostrar isso? É apenas uma ideia? É a sua versão preferida depois de explorar diferentes ideias? Em caso afirmativo, por que esses são os melhores / preferidos?

Comparar os controles atuais com a forma como você gostaria que os novos controles fossem exibidos em seus novos estilos preferidos para todo o sistema significa que não é possível separar o que é específico do controle com o que está em seus novos estilos preferidos para todo o sistema.

Por exemplo, você mencionou a alteração da transparência em uma borda. Esta alteração é destinada a todos os controles ou apenas a este? E em quais estados?

Dar tamanhos explícitos (para botões) pode ser problemático em composições de design, pois nem sempre se traduzem em uniformes com base no redimensionamento do contêiner. Eles devem ser sempre quadrados? ou sua largura é fixa com base na altura de controle padrão?

Como você está propondo que o pincel de fundo para prefixos e sufixos seja determinado? Estou presumindo um pincel de sistema existente, mas qual?

O mascaramento não é abordado nesta especificação. Seus exemplos "Mascarados" têm a intenção de se relacionar com strings de formato?
Como seu exemplo mascarado corresponde a um formato?
Suponho que seu exemplo esteja mostrando a entrada de um endereço IP da versão 4, mas parece que há muitas suposições baseadas em como tudo parece se encaixar perfeitamente. Todos os valores não editáveis ​​devem ter um fundo e margens? E se eles nem sempre forem exibidos? O conteúdo deve ser ampliado para caber em todo o espaço disponível, como parece ser o caso em seu exemplo? Como o espaço alocado para valores não editáveis ​​será tratado ao deslocar o conteúdo que é mais largo do que o espaço disponível?

@mdtauk é um pouco melhor, pois explica um pouco do que você está tentando mostrar.

A questão subjacente ainda permanece: qual é o seu objetivo em mostrar isso? É apenas uma ideia? É a sua versão preferida depois de explorar diferentes ideias? Em caso afirmativo, por que esses são os melhores / preferidos?

Comparar os controles atuais com a forma como você gostaria que os novos controles fossem exibidos em seus novos estilos preferidos para todo o sistema significa que não é possível separar o que é específico do controle com o que está em seus novos estilos preferidos para todo o sistema.

Por exemplo, você mencionou a alteração da transparência em uma borda. Esta alteração é destinada a todos os controles ou apenas a este? E em quais estados?

A Especificação da NumberBox não incluiu nenhum exemplo visual, e as imagens na Proposta Original são exemplos aproximados de funcionalidade. Há outro PR # 524 em que os modelos de controle estão sendo atualizados com os valores de CornerRadius em 2epx, que também é o mesmo arredondamento usado pelo Fabric Web.

Portanto, supondo que os controles derivados de TextBox também serão atualizados de forma semelhante, usei isso como um guia para mostrar como a funcionalidade proposta de NumberBox poderia se encaixar nisso. Os campos de texto da Web do Fabric já têm suporte para valores de prefixo e sufixo, então peguei esse design e usei as métricas XAML.

Dar tamanhos explícitos (para botões) pode ser problemático em composições de design, pois nem sempre se traduzem em uniformes com base no redimensionamento do contêiner. Eles devem ser sempre quadrados? ou sua largura é fixa com base na altura de controle padrão?

O TextBox atual tem alguns botões integrados, como o SearchBox, o botão Password Reveal e o botão Clear Text. Os alvos de toque para botões de sugestão de XAML são de 32 x 32 epx - apenas os mantive em ordem e usei essa orientação.

Como você está propondo que o pincel de fundo para prefixos e sufixos seja determinado? Estou presumindo um pincel de sistema existente, mas qual?

No meu exemplo, usei o Theme Foreground Color, mas usando uma opacidade de 15%. Os FabricWeb usam cerca de 10% e os botões XAML usam 20%.
Existem valores de pincel semelhantes, como ListLowBrush, mas pode ser necessário um novo pincel TextBoxApeciationBackground. O Text Foreground usaria o mesmo pincel PlaceholderTextForeground.

O mascaramento não é abordado nesta especificação. Seus exemplos "Mascarados" têm a intenção de se relacionar com strings de formato?
Como seu exemplo mascarado corresponde a um formato?
Suponho que seu exemplo esteja mostrando a entrada de um endereço IP da versão 4, mas parece que há muitas suposições baseadas em como tudo parece se encaixar perfeitamente. Todos os valores não editáveis ​​devem ter um fundo e margens? E se eles nem sempre forem exibidos? O conteúdo deve ser ampliado para caber em todo o espaço disponível, como parece ser o caso em seu exemplo? Como o espaço alocado para valores não editáveis ​​será tratado ao deslocar o conteúdo que é mais largo do que o espaço disponível?

Não vou fingir que tenho todas as respostas para isso, e como isso é exibido visivelmente no controle se resumirá em como a formatação da máscara é implementada nos controles.

Usei o endereço IP v4, pois é o exemplo apresentado na especificação, e minha intenção original era ilustrar o que estava sendo proposto (embora os exemplos de prefixo e sufixo estivessem faltando, então escolhi outros valores)

Dei uma olhada em como outros controles lidam com o mascaramento e alguns usam texto embutido que move o cursor conforme os valores são inseridos. Outros inserirão itens como colchetes e hifens ao inserir um número de telefone. Alguns usam as teclas tab ou setas para mover entre os segmentos. O exemplo mais próximo da Microsoft que vem à mente é inserir as Chaves de Produto durante a Instalação do Windows.

Achei que usar o mesmo estilo dos elementos anexados se encaixaria na estética, mas estou ciente de que isso aumenta o comprimento do controle para encaixá-lo todo, e em linha pode fazer melhor uso do espaço.

Só uma observação, pois estou trabalhando com TextBox agora, com ele não há um único evento para sinalizar um valor alterado pelo usuário (ou seja, a união de foco perdido e tecla de retorno pressionada), semelhante a https://doc.qt.io /qt-5/qlineedit.html#textEdited seria ótimo ter isso no NumberBox, pois ele se destina a esse tipo de edição. A propósito, se ele vai lidar com todos os tipos de valores, como endereços IP, talvez a caixa "Número" seja um nome muito estreito? Pode ser ValueBox ou algo assim

@adrientetar NumberBox parece bom como um nome, porque todas as entradas contam como números. O endereço IP tem 4 números, números de telefone, moeda, medidas, etc.

DigitBox, NumeralBox, etc. são todas variantes que não se enquadram no estilo de nomenclatura da Microsoft.

Os valores também não precisam ser numéricos por natureza, então ValueBox também pode ser um pouco enganador.

@sonnemaf e @mdtauk , conversei com minha equipe sobre a ideia da calculadora embutida e, em resumo, nós AMAMOS - sem exagero. Estamos muito entusiasmados com a forma como todos vocês já elevaram a qualidade e a criatividade dos controles que oferecemos.

Vou precisar da sua ajuda para fazer isso acontecer. A maneira como permanecemos no topo da ladainha de ideias incríveis que surgem por meio de nosso repo é não ser apenas orientados por ideias, mas também por cenários. (Compartilho isso porque falar esse idioma dará às suas solicitações de recursos uma influência concreta em nosso repo.)

Algum de vocês pode me habilitar com cenários reais para uma calculadora embutida em qualquer um dos aplicativos que você desenvolve? Contexto, capturas de tela, perfis de usuário, tudo ajuda. (Meu e-mail também está no meu perfil do GitHub se você preferir manter os detalhes confidenciais.) @Xyzzer , @mrlacey , @robloo , @ Felix-Dev, @adrientetar e @ArchieCoder , sinta-se encorajado a compartilhar seu cenário de uso deste recurso é do seu interesse também.

Além dessa etapa, a única coisa que poderia prejudicar esse recurso seria o risco de aumentar o tamanho da DLL do WinUI com o mecanismo do aplicativo de calculadora. Analisarei isso em paralelo para verificar a viabilidade.

Eu já abordei a questão de tratar esse controle para mais do que apenas tipos numéricos.

Existe uma diferença fundamental entre um número e uma string que contém uma sequência de dígitos.

Isso foi antes da publicação do primeiro rascunho das especificações, então presumo que isso tenha sido considerado e a decisão tomada para que esse controle manipule tanto "valores numéricos tradicionais" quanto "strings que contêm dígitos numéricos".

Não acho que alguém realmente tentaria argumentar que um endereço IPv4 era um "número" por qualquer outra definição que não seja geralmente representado como uma sequência formatada de dígitos. Na realidade, é apenas um valor de 4 bytes.

@SavoySchuler

• Entrando Despesas talvez - entrando os itens de um recibo onde alguns itens são pessoais e outros parte do trabalho.
• App de restaurante ao dividir uma conta, ou talvez cálculo de gorjeta?
• Aplicativo de edição hexadecimal, para calcular um valor de deslocamento para o qual mover a seleção?

Ter um controle com suporte para endereços IP seria um ótimo complemento para a plataforma, mas não acho que NumberBox seja o controle certo para este cenário.

Conforme mencionado antes, o controle NumberBox:

• use o teclado virtual Number quando usado em um dispositivo sem teclado físico
• tem 2 botões - / +
• exibir um pop-up com uma calculadora ou permitir que o usuário digite operações aritméticas básicas

Nenhum desses recursos faz sentido com o endereço IP. Até o design do controle é muito diferente.

Além disso, devemos ter em mente que se oferecemos suporte a endereços IPv4, devemos também oferecer suporte a endereços IPv6, não usando dígitos, mas hexadecimais.

Acho que faria mais sentido não incluir o suporte de endereço IP neste controle, mas em vez disso trabalhar em um novo controle MaskedTextBox para UWP (compatível com IPv4, IPv6, número de telefone, código postal, SSN, etc ...) com uma interface de usuário avançada (conforme demonstrado por @mdtauk) para substituir / melhorar TextBoxMask do Community Toolkit (https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask)

Ter um controle com suporte para endereços IP seria um ótimo complemento para a plataforma, mas não acho que NumberBox seja o controle certo para este cenário.

Conforme mencionado antes, o controle NumberBox:

• use o teclado virtual Number quando usado em um dispositivo sem teclado físico
• tem 2 botões - / +
• exibir um pop-up com uma calculadora ou permitir que o usuário digite operações aritméticas básicas

Nenhum desses recursos faz sentido com o endereço IP. Até o design do controle é muito diferente.

Além disso, devemos ter em mente que se oferecemos suporte a endereços IPv4, devemos também oferecer suporte a endereços IPv6, não usando dígitos, mas hexadecimais.

acho que faria mais sentido não incluir o suporte de endereço IP neste controle, mas em vez disso trabalhar em um novo controle MaskedTextBox para UWP (compatível com IPv4, IPv6, número de telefone, código postal, SSN, etc ...) com uma interface de usuário avançada (conforme demonstrado por @mdtauk) e substituindo / melhorando TextBoxMask do Community Toolkit (https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask)

@rudyhuyn Eu concordo principalmente com o que você acabou de dizer aqui, e minhas ilustrações foram para a especificação proposta.

Mas, como foi mencionado por outros, uma caixa de texto mascarada não precisa se limitar apenas a numerais e também pode incluir strings. A caixa Microsoft Product Key é um bom exemplo, onde são aceitos 5 conjuntos de 0-9 caracteres AZ.

Mesmo que o Masking fosse separado, ainda acho que há bons casos de uso para incluir as propriedades PrefixText e SuffixText no controle NumberBox. Moeda, medidas, tudo requer algum tipo de contexto.

Botões de rotação são puramente para aumentar e diminuir valores, portanto, eles também estão dentro do escopo de um controle NumberBox.

Prefixo e sufixo podem se tornar propriedades do próprio controle TextBox e, portanto, herdadas pelos outros controles. (Pode ser necessário haver uma exceção para a PasswordBox se ela abrir alguma vulnerabilidade)

As máscaras para valores comuns podem ser um enum (junto com um CustomFormatMask) para esse controle separado. Algumas dessas máscaras podem envolver um contexto cultural, como um código postal do Reino Unido alfanumérico e números de seguro nacional do Reino Unido seguindo formatação especial, etc.

SW1A 2AA

Exemplo de código postal do Reino Unido (para No. 10 Downing Street)

Parece que não consegui atualizar a página esta manhã antes de enviar minha resposta ... Obrigado a todos vocês rockstars por levar esta proposta a um novo nível! Eu sei que as palavras são usadas demais no GitHub, mas é sério!

@mdtauk - suas maquetes são fantásticas. Eu ainda não havia esboçado projetos de protótipo para este controle. Posso dividir seu mock up e adicioná-los às especificações como protótipos para nossos designers começarem sua paleta? Vou entrar em contato e solicitar um designer hoje e ver se consigo fazer com que ele responda ao seu tópico com @mrlacey aqui. Lerei seu tópico e responderei em detalhes mais refinados em breve.

@sonnemaf , obrigado novamente! Eu encorajaria você a copiar seu comentário e publicá-lo novamente aqui na guia de conversa do maquetes de

@mdtauk : Concordo com você, um prefixo / sufixo seria uma boa adição a TextBox e não se limita a números, alguns exemplos:

• peça a um funcionário para inserir seu endereço de e-mail quando o domínio for sempre o mesmo (@ microsoft.com por exemplo).
• insira o nome de um formulário quando ele sempre começar com W-

etc ...

Você deve abrir outro tíquete para que possamos iniciar uma discussão sobre isso!

@rudyhuyn você vê a capacidade de não suportar algo como um endereço IP, mas a capacidade de suportar um número de telefone ou código postal como viável?
Meu pensamento é que se você começar a restringir algumas coisas, mas não outras, as regras para o que está coberto precisam ser definidas de forma muito clara.
Apenas o suporte a valores que podem ser apresentados como inteiros, flutuantes etc. torna as coisas muito claras e ainda cria um controle que fornece muitos valores.

@SavoySchuler Meus designs estão inteiramente à sua disposição, eu os postei para tentar ajudar a visualizar o controle para todos que contribuem.

@rudyhuyn Se você postar uma proposta de MaskedTextBox ou FormattedTextBox, ela pode ter mais peso! Tal como acontece com a NumberBox, fico feliz que qualquer um dos meus designs seja incluído em tal proposta e posso dar mais exemplos conforme necessário.

@mrlacey Números de telefone (exceto os caracteres de formatação) são números puros - mas eles não se enquadram em nenhum tipo de caso de uso de cálculo, então cabe melhor em uma TextBox mascarada ou há valor em fornecer suporte para eles em uma NumberBox?

Ao criar o controle e a documentação, fornece um caso de uso claro e exemplos de qual controle usar e em que contexto é importante.

@mrlacey : Eu não.

Como você disse antes, devemos separar os números reais, não apenas algo usando 0-9 caracteres, mas associados a um valor aritmético.

Um endereço IP, número de telefone, SSN, código postal usam 0-9 caracteres, mas não têm valores aritméticos (você pode adicionar 2 deles, se adicionar ".00" ao final, você altera o significado do valor, etc.) . Nesses casos, o valor é uma string, não um int / double, um MaskedTextBox faria mais sentido.

Além disso, um código postal usa apenas dígitos nos EUA, mas não no Canadá, por exemplo, um endereço IPv6 pode conter caracteres AF, um número de telefone pode conter um sinal + (555-123-4567 e + 555-123-4567 são 2 diferentes números de telefone), etc ...

Para resumir minha opinião, NumberBox.Value deve ser um double, não uma string.

@mrlacey Números de telefone (exceto os caracteres de formatação) são números puros - mas eles não se enquadram em nenhum tipo de caso de uso de cálculo, então cabe melhor em uma TextBox mascarada ou há valor em fornecer suporte para eles em uma NumberBox?

Os números de telefone podem ser compostos inteiramente de dígitos (mais formatação), mas isso não os torna números. Você não pode fazer qualquer tipo de operação aritmética com eles e obter algo significativo.
Além disso, alguns podem começar com um sinal de adição.
Além disso, o número de zeros à esquerda em um número de telefone é significativo. Para um valor numérico, não é.
A outra funcionalidade do controle, como cálculos ou botões para cima e para baixo, não faz sentido para um "número de telefone".

Esse controle deve ser limitado a valores que podem ser convertidos em int / uint ou decimal sem o risco de perda de informações.

Para ter certeza de que estou sintetizando este feedback de forma adequada, por favor, dê-me um polegar para cima neste comentário se você acredita que este é o melhor lugar para todos os tipos de entrada de strings numéricas (como números de telefone e IPv4) por meio de tipos de formato e um polegar- para baixo se essa funcionalidade deve ser adiada para outro ou novo controle para que NumberBox se concentre exclusivamente em matemática e captura de valor matemático. (Observe os recursos que suportam a operação matemática, como modo de calculadora e botões para cima / para baixo, exigem ativação por meio das respectivas APIs.)

Não posso garantir que isso será decidido democraticamente, pois tomarei a decisão que resulta no melhor retorno do investimento para nossos clientes globalmente - mas ajudará a validar o que acho que vejo aqui: ninguém pedindo isso para suporte numérico strings e prefere um controle dedicado para isso.

@SavoySchuler Números que podem ser operados, incrementados e decrementados, bem como prefixos e sufixos que adicionam contexto e significado ao valor.

Acabei de sincronizar com a equipe aqui e gostaria de compartilhar atualizações sobre algumas de nossas questões em aberto:

• Estamos ouvindo seus comentários e concordamos que a NumberBox não é o lugar certo para sequências numéricas. As propriedades FormatKinds e CustomFormat foram substituídas por APIs mais específicas para controlar o formato do número de maneiras mais intuitivas.
• Prefixo e sufixo realmente pertencem ao TextBox (do qual NumberBox os herdará). Darei a @mdtauk , @mrlacey ou a qualquer outra pessoa alguns dias de vantagem para propor a solicitação de recurso, caso contrário, vou iniciá-la e vinculá-la aqui. Por enquanto, isso evitará que a NumberBox seja bloqueada na saída de localização / automação.
• O feed final em um NumberBox (após cálculo, arredondamento, etc.) será preservado como uma String na propriedade Text que sai de TextBox E como um Double em uma nova propriedade Value. Pretendemos ter esse feedback um para o outro, de modo que a alteração de um se reflita no outro. O objetivo disso é tirar o máximo de trabalho possível de suas mãos e ter o valor pronto para ser acessado conforme necessário.
• StepSize estava faltando como uma propriedade na especificação.
• Os tipos inteiros serão alterados para Double.
• Ainda estamos entusiasmados com a ideia de uma calculadora incorporada e estamos procurando mais cenários para nos ajudar a refinar isso. @mdtauk , obrigado por já responder a este ponto de feedback!
• Com relação à validação de entrada, a ideia é primeiro enviar um tipo de evento ValueChanged que dará ao desenvolvedor a oportunidade de manipular a entrada ou tratá-la em seu envio de formulário de final / bloqueio conforme necessário. Se nenhuma ação corretiva for tomada (como forçá-la dentro de min / max, remover caracteres inválidos, etc.), NumberBox exibirá uma indicação de erro para o usuário sobre sua entrada. Essa abordagem dupla permite que os desenvolvedores respondam se preferirem, mas também permite que a correção seja adiada para o usuário.

Tenho recebido uma quantidade incrível de feedback aos quais ainda estou respondendo. Obrigado pela sua paciência, responderei a todos aqui e no repositório de especificações também!

"Arte conceitual de NumberBox com calculadora embutida." Comunidade WinUI, maio de 2019. (colorido)

(Elogio de @ryandemopoulos )

@SavoySchuler Você pediu alguns exemplos de cenários onde o (s) tipo (s) de controle (s) que estamos discutindo poderiam ser usados. Tenho dois em meu aplicativo que podem ser bons exemplos.

Caso 1: Existe um editor de configurações para gráficos 2D onde você pode ajustar o eixo.

• Isso só precisa de uma entrada numérica simples e básica. Os botões de incremento +/- seriam úteis aqui.
• Um valor duplo seria adequado, mas as entradas precisam ser validadas ao pressionar o caractere. O usuário nunca deve ser capaz de pressionar 'a' e fazê-lo aparecer na caixa de entrada. A validação de entrada não deve deixar a borda vermelha e dar ao usuário um aviso - simplesmente não deve ser possível inserir um valor inválido.
• A localização teria que ser suportada pelo controle e mover a casa decimal (seja vírgula, ponto, etc.) tratada como um caso especial (eu continuo trazendo isso porque é fácil perder)

Caso 2: há um campo de entrada para um valor de moeda conforme mostrado abaixo. Este é um controle personalizado "CurrencyBox"

• Isso poderia usar um botão de calculadora e a capacidade de inserir as equações 2 + 3 teria algum valor aqui (ainda acho que este deve ser um controle separado)
• Um valor duplo NÃO é ideal para isso. Eu sugeriria alterar a especificação de Value de double para decimal para oferecer suporte a esse tipo de caso de uso . Caso contrário, cabe ao desenvolvedor analisar o texto da string.
• Há um caso especial aqui em que o sinal negativo é tratado separadamente. Isso torna muito mais fácil para o usuário não cometer um erro ao assinar. Na verdade, não espero que o NumberBox suporte isso fora da caixa.
• É importante definir o alinhamento do texto e um prefixo / sufixo seria extremamente útil para mostrar um símbolo de moeda (a localização ainda seria um problema para saber se deve mostrar o símbolo à direita ou à esquerda; no entanto, o próprio aplicativo pode ter essa lógica)
• O usuário pode inserir um valor estrangeiro ou local. O NumberFormatInfo e CultureInfo para ambos os valores PODEM ser diferentes da cultura da IU. Portanto, para localização, o controle deve oferecer suporte à substituição para um NumberFormatInfo personalizado.

Agora, no aplicativo, o Windows Community Toolkit é usado para ambos os casos com propriedades anexadas ao TextBox conforme abaixo:
TextBoxRegex.ValidationMode = "Dinâmico"
TextBoxRegex.ValidationType = "Decimal"

Alguns comentários finais (desculpe, isso é tão longo!)

• Acho que estamos discutindo potencialmente 3 controles diferentes aqui. Um NumberBox bar-bones, um CalculatorBox que pode ter equações e entrada numérica avançada (botão Calculator!) E, finalmente, um MaskedTextBox para entrada não numérica, como números de telefone e endereços IP. Não devemos confundi-los e concordar em como separar esses conceitos é a chave para avançar com a especificação.
• Não podemos perder o foco do caso de uso mais básico e indiscutivelmente mais útil: uma caixa de texto de aparência normal com nada mais do que filtragem de entrada para que apenas um número válido possa ser inserido. Todas as outras opções devem ser desligadas (estou pensando nos botões +/- de incremento)
• Ainda sugiro mudar de duplo para decimal na especificação para capturar a precisão decimal com precisão no valor analisado. Além disso, provavelmente devemos considerar a entrada de número inteiro diferente da entrada de número racional. Essa é provavelmente uma nova propriedade na API "IsInteger = true" para alterar o padrão decimal.

Editar: ideia removida para mudar de duplo para decimal para o tipo NumberBox.Value. Eu estava incorreto ao presumir que isso existia no mundo C ++ WinRT. Isso não acontece e, em vez disso, está apenas em .net core / framework.

@robloo , sobre esse comentário final, não há tipo decimal no WinRT.

O depurador Visual Tree do XAML Toolkit é uma ferramenta que depende muito do controle NumericUpDown do kit de ferramentas, onde incrementar / diminuir arrastando o mouse, botões e teclado são importantes. A entrada da calculadora também pode ajudar:

@robloo e @xyzzer , este é exatamente o tipo de informação que estou procurando!

Validação / Mascaramento

@robloo , estou particularmente interessado no Caso 1: Ponto 2 - validação vs mascaramento. Vamos falar sobre o cenário de "entrada ruim" a partir de agora:

• Um novo usuário digita "dois" em sua NumberBox.
• O NumberBox gera o evento "ValueChanged" que lhe dá a oportunidade de retornar a entrada não numérica para "0" - ou de outra forma - se você escolher. Se nenhuma ação for realizada, então ...
• A validação é ativada em NumberBox e brilha em vermelho e exibe uma mensagem de erro para o usuário informando que apenas a entrada numérica é permitida (esta parte não foi totalmente racionalizada ainda, então esta é apenas uma hipótese).

Essa série de eventos dá a você a capacidade de criar a experiência de que você precisa?

Eu entendo que o mascaramento pode ser um padrão desejável, mas deixe-me compartilhar o que minha equipe discutiu na semana passada - nós descobrimos que a validação (indicador / mensagem de erro) é preferida nos controles Fluent, pois a alternativa, mascaramento, pode ser frustrante e confuso para os usuários finais quando eles não experimentam nenhuma saída de sua entrada de teclado. Outra maneira de pensar sobre isso é que a validação oferece um nível de transparência e informação ao usuário que o torna mais consciente da experiência em vez de ser silenciosamente coagido. Portanto, nosso curso de ação atual foi criar uma validação básica, sem bloquear a oportunidade para o desenvolvedor adicionar validação avançada (em breve no TextBox) ou mascarar por meio do evento ValueChanged, conforme necessário. Para entender, isso é flexível o suficiente para permitir que todas as necessidades sejam atendidas enquanto fornece a experiência recomendada como padrão.

Quais são seus pensamentos aqui? Eu estaria interessado em quaisquer idéias que você tenha para compreender ainda mais esses conceitos ou construir uma experiência ainda melhor, se possível.

Formatação de Valor

Aos seus outros pontos, @robloo , adicionei uma propriedade de precisão DecimalPrecision à especificação . Definir isso = "0" resultará em números inteiros. Além disso, definir MinValue = "0" pode ajudar a manter os números não negativos (ou o evento ValueChanged é outra oportunidade de forçar a entrada a valores absolutos).

Você já olhou as especificações ? Acredito ter incluído todas as propriedades necessárias para habilitar totalmente suas experiências (enquanto se aguarda a discussão de validação versus mascaramento), mas estou ansioso para saber se você acha que perdi alguma coisa.

mascaramento, pode ser frustrante e confuso para os usuários finais quando eles não experimentam nenhuma saída de sua entrada de teclado.

100% concordam sim. A melhor coisa a fazer é validar em LosingFocus / EnterPressed e restaurar o oldValue se o valor digitado não validar, razão pela qual um sinal que dispara em LosingFocus / EnterPressed e contém oldValue / newValue seria perfeito.

@adrientetar , ótimo ponto! É uma experiência que você precisa criar? Nesse caso, verei o que precisamos fazer para que o evento ValueChanged envie o valor antigo e o novo.

@SavoySchuler É algo que eu quero fazer no meu aplicativo. Eu mesmo construiria esse comportamento, a menos que o controle o faça por padrão.

A outra coisa que eu quero é Shift + ↑ / ↓ para incrementos de 10 e Ctrl + Shift + ↑ / ↓ para incrementos de 100, embora eu reconheça que incrementos de 100 nem sempre façam sentido ter.

Ótimo ponto! Devemos ter certeza de que o controle deriva de RangeBase, que
define SmallChange e LargeChange e que usamos ambos em
o mínimo.
Existe um exemplo de combinações de teclado padrão para usar para invocar
grande alteração no RangeBase do UWP ou WinForms / ComCtl (?) NumericUpDown?

Na segunda-feira, 3 de junho de 2019 às 15:50 Adrien Tétar [email protected]
escreveu:

@SavoySchuler https://github.com/SavoySchuler É algo que eu quero
fazer em meu aplicativo, eu mesmo construiria esse comportamento, a menos que o controle
por padrão.

A outra coisa que eu quero é Shift + ↑ / ↓ para incrementos de 10 e
Ctrl + Shift + ↑ / ↓ para incrementos de 100, embora eu reconheça incrementos de 100
nem sempre faz sentido ter.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMFZBHJIE4DR2KN46TTPYWN3BA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW25B2Y#issuecomment-498454763 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AANMBMG4AWBK44VE4O4GYR3PYWN3BANCNFSM4HA4PBNA
.

Vou verificar para verificar, mas estou bastante confiante de que os atalhos de teclado terão que ser deixados para os aplicativos implementarem. Eu tentei isso com a justificativa de acessibilidade para o nº 21 e a introdução de novos atalhos de teclado é um jogo arriscado de jogar, já que quase todos eles que não foram reivindicados pelo Windows agora foram usados ​​no nível do aplicativo (sendo dito que o TeachingTip foi capaz de avançar o movimento F6) - mas vou verificar se o foco do controle permite alguma exceção aqui!

A versão 2018 foi quando os estados de validação para controles TextBox foram anunciados, usando INotifyDataErrorInfo.
Isso seria bom para usar com mascaramento para validar ou invalidar a string de texto atual.

EDITAR: O uso do ícone e da cor da borda inferior mais espessa, é para ajudar no reconhecimento em situações daltônicas, e quando olhado em Preto e Branco. O texto de erro inferior pode ser feito como uma dica de ferramenta no ícone se o espaço for escasso.

@mdtauk, você é fenomenal nessas

@SavoySchuler Extrapolação fácil com base no exemplo mostrado no Build 2018

E existem muitos exemplos para ver :)

Desculpas, este é outro longo!

@SavoySchuler @adrientetar Com certeza vejo de onde você vem com suas declarações abaixo. Não vou argumentar que, na grande maioria dos casos, é a melhor maneira de lidar com a validação. No entanto, tenho que pensar que há alguns casos especiais em que é tão obviamente uma entrada apenas numérica que você está, na verdade, fazendo um favor ao usuário ao não permitir que ele indique o caractere errado.

mascaramento, pode ser frustrante e confuso para os usuários finais quando eles não experimentam nenhuma saída de sua entrada de teclado.

100% concordam sim. A melhor coisa a fazer é validar em LosingFocus / EnterPressed e restaurar o oldValue se o valor digitado não validar, razão pela qual um sinal que dispara em LosingFocus / EnterPressed e contém oldValue / newValue seria perfeito.

No entanto, decidi dar uma olhada em outros aplicativos para ver como isso é tratado. Acho que ninguém faz mais pesquisas do que a Microsoft sobre a interação do usuário, então peguei a versão Desktop de 64 bits do Word e, em seguida, a versão UWP do OneNote para referência. Concorda mais ou menos completamente com o que vocês estão dizendo. Posso digitar qualquer texto nas caixas de entrada de tamanho de fonte ou forma que são claramente apenas entradas numéricas. Ele valida amplamente na perda de foco e reverte para a última entrada válida.

| Título | Pic | Comentário |
| ------ | ----- | ------------ |
| Entrada de tamanho de fonte UWP OneNote | | Qualquer valor pode ser inserido no teclado, ele é validado automaticamente e redefinido para o último valor válido em foco perdido |
| Entrada de tamanho de fonte do Desktop Word | | Qualquer valor pode ser inserido no teclado, ele é validado automaticamente em caso de perda de foco e uma mensagem de erro aparece se inválido. Ao clicar em [OK] redefine para o último valor válido. |
| Gráfico UWP OneNote 2D | | Qualquer valor pode ser inserido no teclado. Valores inválidos serão simplesmente ignorados e a última entrada válida usada no cálculo (não valida em foco perdido). Pressionar os botões de incremento +/- aumentará usando a última entrada válida. |
| Entrada de tamanho de formato de palavra da área de trabalho | | Qualquer valor pode ser inserido no teclado, ele é validado automaticamente em foco perdido e redefinido para o último valor válido em foco perdido. |

Então acho que provei que estava errado, o que significa que deveria concordar com você!

Comentários laterais:

• Conforme mencionado anteriormente por outra pessoa, quando a NumberBox tem o foco do teclado com um teclado virtual / de toque, apenas o teclado numérico deve ser mostrado.
• O incremento para baixo à esquerda e incremento para cima à direita é uma ideia interessante para discutir aqui em termos de estilo. Eu gosto disso!
  

• Um novo usuário digita "dois" em sua NumberBox.
• O NumberBox gera o evento "ValueChanged" que lhe dá a oportunidade de retornar a entrada não numérica para "0" - ou de outra forma - se você escolher. Se nenhuma ação for realizada, então ...
• A validação é ativada em NumberBox e brilha em vermelho e exibe uma mensagem de erro para o usuário informando que apenas a entrada numérica é permitida (esta parte não foi totalmente racionalizada ainda, então esta é apenas uma hipótese).
  Essa série de eventos dá a você a capacidade de criar a experiência de que você precisa?
  Quais são seus pensamentos aqui? Eu estaria interessado em quaisquer idéias que você tenha para compreender ainda mais esses conceitos ou construir uma experiência ainda melhor, se possível.

Eu entendo totalmente e concordo que adicionar validação de entrada é ótimo para a plataforma geral. No entanto, você basicamente descreveu a validação de entrada sem nenhum tratamento especial para um número. Portanto, para que serve um NumberBox além de analisar automaticamente um valor? Como desenvolvedor, parece que um TextBox com validação de dados é mais ou menos o mesmo.

Acho que, com base nos exemplos acima, a funcionalidade pronta para uso deve ser uma mistura de nossas ideias e é o que

Em termos de eventos, eu ainda gostaria de ter a oportunidade de cancelar as alterações de texto se esse caso de uso se tornar mais claro. Portanto, além de ValueChanged, eu recomendaria um evento ValueChanging e TextChanging para permitir que a entrada seja comparada e cancelada. Definitivamente, um OldValue e NewValue são necessários independentemente, pelo menos nos permitiria alterá-lo rapidamente de volta para OldValue se necessário (embora o UWP goste de travar quando você modifica o TextValue em um evento).

Com relação à especificação: Boas ideias com DecimalPrecision, precisarei de mais tempo para analisá-la e adicionar meus comentários. Existem muitas pequenas nuances, como o valor padrão deve ser String = Vazio, Valor = Nulo e quando um botão de incremento +/- é pressionado, o valor deve ser tratado como zero em vez de vazio.

@mdtauk Não deveria ser humanamente possível fazer boas ilustrações tão rapidamente :)

@robloo Obrigado pelo comentário gentil. Eu só tenho um comentário rápido a fazer sobre o seu +/−
Pode ser melhor ficar com os símbolos para cima e para baixo usados ​​nos botões de rotação atuais, para evitar confusão com as operações matemáticas que este NumberBox pode realizar.

O iOS usa um controle "passo a passo", mas a entrada de texto é separada e não há cálculo embutido.

Aqui estão mais alguns designs que encontrei

O design que escolhi parece se adequar ao estilo típico da Microsoft para este controle, mas é a melhor escolha ou a escolha certa. Eu estaria interessado em ouvir o que os outros pensam disso.

EDIT: Adicionadas algumas maquetes de formas alternativas (mas acho que a primeira ideia é a melhor ...)

Concordo com @mdtauk sobre a localização +/-, a primeira é a melhor.

Há um ControlTemplate XAML para que o usuário (desenvolvedor) sempre possa criar um modelo personalizado para os outros dois layouts.

@robloo , você não precisa se desculpar por respostas detalhadas - especialmente quando eles Perguntas abertas sobre as especificações para serem executadas pelos desenvolvedores / equipe e garanti que não haja sobrecarga de desempenho inaceitável ao fazê-lo. Eu acho que seria uma conveniência maravilhosa para os usuários se pudéssemos fazer isso acontecer.

Você trouxe um ótimo ponto sobre validação ...

[1] Tempo de perguntas: Alguém seria contra um sistema de validação que reverte automaticamente a entrada inaceitável de volta ao valor anterior, enquanto expõe eventos que permitiriam ao desenvolvedor cancelar este comportamento e, em vez disso, decidir o que fazer / aumentar indicadores ou mensagens de erro?

Visualmente, vejo o mérito dos UpDownButtons disjuntos no exemplo que você postou. Eu acredito que @mdtauk e @sonnemaf estão no caminho certo para o padrão. A proximidade dos UpDownButtons é sua verdadeira conveniência, quer se esteja testando o resultado de ida e volta de entradas diferentes (mas não distantes) ou corrigindo entradas ultrapassadas. Distância, a menos que seja merecida por design ou funcionalidade aprimorada, pareceria adicionar trabalho evitável à experiência e também poderia comprometer a clareza com propriedades / rotulagem de Prefixo / Sufixo em oposição ao agrupamento distinto como parte funcional do controle, por exemplo: $ [-] 192 [+]

Acredito que existam cenários para os UpDownButtons separados. Minha mente vai para tarefas que esperam uma entrada mínima e unidirecional ou aquelas em que o desenvolvedor procura tornar os erros de entrada mais difíceis de cometer. Acredito que seja essa a experiência que diversos aplicativos e sites proporcionam quando, por exemplo, se compra ingressos de cinema ou shows.

Minha pergunta então é ...

[2] Tempo de perguntas: devemos confiar no Xaml ControlTemplate para criar um NumberBox com UpDownButtons disjuntos (ou seja, isso não é comum o suficiente para justificar o suporte pronto para uso) ou devemos incluir uma propriedade para definir se os UpDownButtons aparecem contíguos vs. disjunto?

Vou enviar um ping para

Devo incluir considerações de acessibilidade para a conversa dos UpDownButtons: a proximidade dos UpDownButtons entre si permite clareza conceitual para usuários do Narrador / leitor de tela, ao mesmo tempo que mantém a eficiência da navegação para usuários de navegação do teclado e também é importante não comprometer isso.

Se o controle não for muito largo, convém que as setas sejam empilhadas verticalmente (sei que preciso disso no meu aplicativo). Talvez o controle pudesse ser responsivo à sua largura definida? Depende das diretrizes de design fluentes especificá-lo dessa forma, se acharem que faz sentido.

Eu atualizei a proposta com nossas 3 questões abertas.

Obrigado @mdtauk pelos designs de conceito!

@adrientetar Fico feliz que você tenha apontado isso como uma necessidade. Parece que talvez precisemos de um enum para essas três configurações?

Se o controle não for muito largo, convém que as setas sejam empilhadas verticalmente (sei que preciso disso no meu aplicativo). Talvez o controle pudesse ser responsivo à sua largura definida? Depende das diretrizes de design fluentes especificá-lo dessa forma, se acharem que faz sentido.

Houve uma proposta para permitir que os controles fiquem cientes e respondam à quantidade de espaço que têm à sua disposição # 677 Isso pode ser usado para reposicionar os botões giratórios à medida que o controle se torna mais estreito. Talvez seja necessário haver uma propriedade para NarrowWidth semelhante a MinWidth, ou talvez até um NumberOfDigits para atuar como uma dica?

Em relação ao exemplo de texto acinzentado - temo que isso possa encorajar o usuário a preencher os valores que aparecem, em vez de agir como uma dica sobre qual será o resultado final. Ele se parece com o PlaceholderText.

Que tal usar o AccentColor e diferentes espessuras de fonte para destacá-lo

Ótimo link, @mdtauk. Eu imagino que se esta é uma estrada que percorremos, poderíamos lidar com isso com um enum que tenha valores como [Auto, Vertical, Horizontal, Detached] onde Auto irá preferir Horizontal até que a compactação ordene Vertical. Pensamentos?

Além disso, eu atualizei a imagem! Acho que você está certo que o texto esmaecido pode parecer um prompt, que se seguido, resultaria em um erro devido ao "=".

Ótimo link, @mdtauk. Eu imagino que se esta é uma estrada que percorremos, poderíamos lidar com isso com um enum que tenha valores como [Auto, Vertical, Horizontal, Detached] onde Auto irá preferir Horizontal até que a compactação ordene Vertical. Pensamentos?

Um pensamento inicial é: será que o número no contêiner será grande o suficiente onde uma orientação vertical seria necessária? O AutoCompleteBox não move o botão Pesquisar e as strings são geralmente mais longas do que números.

Se for algo puramente relacionado ao espaço disponível, um comportamento responsivo automático (se essa proposta tiver permissão para ir em frente) seria melhor do que um enum. Dar aos desenvolvedores a opção no controle em si pode levar a um uso menos consistente do controle, mas acho que isso precisaria ser algo que a pesquisa do usuário teria que olhar, eu acho, ao invés de apenas prescrito por nós no github.

Os desenvolvedores sempre têm a opção de refazer o modelo do controle se eles _realmente_ precisarem de um layout diferente para o controle, e é possível incluir um estilo alternativo para isso se você quiser A) fazer o esforço de tornar o padrão e Estilo vertical e modelos - e B) garantem que ambos os estilos sejam testados corretamente

@mdtauk Concordo que os símbolos para cima / para baixo são os melhores. Eu só queria mostrar um exemplo com as setas em lados opostos da entrada. Como mencionado anteriormente, isso ajuda a garantir que o usuário não pressione o botão errado, o que é quase obrigatório em uma IU baseada em toque. Acontece que o exemplo que dei do OneNote tinha símbolos +/-, mas eu deveria ter adicionado para ignorar os próprios símbolos.

@SavoySchuler

[2] Tempo de perguntas: devemos confiar no Xaml ControlTemplate para criar um NumberBox com UpDownButtons disjuntos (ou seja, isso não é comum o suficiente para justificar o suporte pronto para uso) ou devemos incluir uma propriedade para definir se os UpDownButtons aparecem contíguos vs. disjunto?

Eu sei que quando o UWP foi criado pela primeira vez, era o toque primeiro - portanto, UpDownButtons desarticulados seriam indiscutivelmente melhores. Desde então, os requisitos de toque primeiro foram relaxados e com certeza os botões próximos um do outro são melhores quando o usuário tem um método de entrada preciso, como um mouse (menor distância de deslocamento). Como isso depende do caso de uso, concordo que um enum é útil para especificar como os UpDownButtons devem aparecer.

Para valores enum, discutimos vários estados e, generalizando, podemos adicionar mais alguns:

• SeparatedHorizontal: seta para baixo à esquerda, seta para cima à direita
• SeparatedVertical: seta para baixo na parte inferior, seta para cima na parte superior
• Esquerda: as setas para baixo e para cima uma ao lado da outra à esquerda (em uma orientação horizontal)
• Direita: as setas para baixo e para cima uma ao lado da outra à direita (em uma orientação horizontal)
• Superior: setas para baixo e para cima, lado a lado na parte superior (em uma orientação vertical)
• Inferior: setas para baixo e para cima próximas uma da outra na parte inferior (em uma orientação vertical)

Se tudo isso se tornar muito complexo (como é rapidamente), ficarei feliz em reformular o controle para meus próprios casos de uso em XAML.

Só para jogar outra ideia: mudar a orientação do símbolo para UpDownButtons desarticulados também pode fazer algum sentido [<] 123 [>]. Sinta-se à vontade para ignorar essa complexidade adicional, pois ela certamente poderia ser reestilizada por aplicativo.

Além disso, algumas das questões de acessibilidade podem já ter sido tratadas no OneNote, de onde extraí o exemplo.

@robloo Acho que os posicionamentos esquerdo e direito que você mencionou devem ser mantidos para localização RtL e LtR - ao invés de configurações discretas.

Abaixo estão minhas opiniões

Também não tenho certeza se colocar os botões acima do campo de texto faz sentido semanticamente, muito menos quando você está colocando o dedo no botão, pode dificultar a visualização da alteração do número.

Ter todas as combinações incorporadas ao controle levará ao uso caótico e todas essas coisas podem ser feitas com reformulação do modelo se houver uma necessidade urgente.

Os botões abaixo do campo de texto podem ter alguma utilidade em áreas confinadas de espaço e como uma opção no próprio controle, pois torna os botões muito maiores para serem tocados. Seja como um estilo agrupado com o controle ou um enum entre:

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

Apenas uma sugestão de pergunta rápida possível: Em teoria, em uma caixa de número, deve-se ser capaz de inserir apenas números em uma caixa de número. Quão difícil seria analisar números escritos e traduzi-los em números reais para esses campos?

Por exemplo:
um + dois = 3
traduz
1 + 2 = 3

Ou
um mais dois é igual a três
traduz para
1 + 2 = 3

É apenas uma ideia.

Apenas uma sugestão de pergunta rápida possível: Em teoria, em uma caixa de número, deve-se ser capaz de inserir apenas números em uma caixa de número. Quão difícil seria analisar números escritos e traduzi-los em números reais para esses campos?

Por exemplo:
um + dois = 3
traduz
1 + 2 = 3

Ou
um mais dois é igual a três
traduz para
1 + 2 = 3

É apenas uma ideia.

Isso faz sentido, para inglês. Isso se torna um problema quando você precisa traduzir e analisar essas strings para outros idiomas. E que tal um usuário polonês, digitando palavras em inglês?

Como está agora, apenas a forma dos numerais 0-9, decimais, separadores de números e operadores matemáticos - foram discutidos. Mas outros sistemas numéricos podem precisar ser atendidos.

Adicionar traduções de idiomas será um grande esforço, e não está claro qual será o benefício.

Agora, se esse controle fosse manipulado por entrada de áudio, falando o número ou a operação - isso pode envolver a interpretação do idioma falado.

NARRADOR:
"Pixels NumberBox sem um valor"

DO UTILIZADOR:
"Cento e vinte e oito pixels"

[128 _________ | px]

DO UTILIZADOR:
"Adicionar Sessenta e Quatro pixels"

[192 _________ | px]

NARRADOR:
"Cento e noventa e dois pixels"

[1] Tempo de perguntas: Alguém seria contra um sistema de validação que reverte automaticamente a entrada inaceitável de volta ao valor anterior, enquanto expõe eventos que permitiriam ao desenvolvedor cancelar este comportamento e, em vez disso, decidir o que fazer / aumentar indicadores ou mensagens de erro?

Se o texto inserido se tornar inválido, por que o valor seria alterado para algo mais antigo? Não acho que tentar manter um "último conhecimento bom Value " seja algo pelo qual o controle precise ser responsável. Deixe o controle lidar com um único valor atual (ou estado de erro) e deixe o aplicativo cuidar de qualquer processamento histórico extra, conforme necessário, por meio do evento ValueChanged .

Para a versão inicial, acho que será adequado apenas apoiar uma única posição dos botões Para cima / Para baixo, pois eles podem ser refeitos, se necessário.
Se a capacidade de determinar a posição dos botões Para cima / Para baixo for considerada uma necessidade, qualquer enum adicionado deve remover a necessidade de ter a propriedade UpDownButtonsEnabled e um valor de enum de Hidden pode ser adicionado em vez disso.
Observe também que ter suporte embutido para manipular a posição dos botões para cima / para baixo aumentará a complexidade para qualquer pessoa que precise ajustar os modelos para algo diferente de uma opção fornecida.

@shaheedmalik , e uma ideia excelente e intuitiva. Você verificou as especificações? Temos um evento ValueChanged que permitiria a você interceptar essa entrada e analisar manualmente os números digitados em valores numéricos - de modo que seria uma experiência possível de criar, especialmente se você tiver um idioma específico em mente. Quanto a preparar um analisador de linguagem global no V1 padrão do controle - @mdtauk está certo, isso adicionaria complexidade e sobrecarga que precisariam de justificativa significativa. Um benefício de disponibilizar esses controles de código aberto é que eles podem ser bifurcados pela comunidade. Neste caso, você ou outros membros da comunidade podem criar variantes específicas de idioma desse controle. Acredito que esse seria o caminho mais realista para democratizar uma versão de análise de linguagem do NumberBox.

@mrlacey, você tem a chance de 's revisão @robloo análise comparativa dos NumberBox controle semelhante do utilizado em todo o Windows ? O comportamento de redefinir esses campos para a última entrada válida, apenas numérica, na verdade tem um precedente amplo do sistema - o que significa que o próprio controle ou as diretrizes do desenvolvedor seriam pressionados para se alinhar a esse padrão. Minha inclinação seria alinhar este controle em consistência com a experiência padrão do Windows e criar uma avenida para o desvio necessário, em oposição a padronizar um comportamento que se desvia do resto do ecossistema e afirmar diretrizes para criar este comportamento padrão do sistema como o último criaria fácil e eficiente para o caso comum. Eu encorajo a discordância, então, por favor, deixe-me saber se você acha que isso adiciona complexidade desnecessária ao controle ou, talvez, devemos reavaliar esse precedente.

| Título | Pic | Comentário |
| ------ | ----- | ------------ |
| Entrada de tamanho de fonte UWP OneNote | | Qualquer valor pode ser inserido no teclado, ele é validado automaticamente e redefinido para o último valor válido em foco perdido |
| Entrada de tamanho de fonte do Desktop Word | | Qualquer valor pode ser inserido no teclado, ele é validado automaticamente em caso de perda de foco e uma mensagem de erro aparece se inválido. Ao clicar em [OK] redefine para o último valor válido. |
| Gráfico UWP OneNote 2D | | Qualquer valor pode ser inserido no teclado. Valores inválidos serão simplesmente ignorados e a última entrada válida usada no cálculo (não valida em foco perdido). Pressionar os botões de incremento +/- aumentará usando a última entrada válida. |
| Entrada de tamanho de formato de palavra da área de trabalho | | Qualquer valor pode ser inserido no teclado, ele é validado automaticamente em foco perdido e redefinido para o último valor válido em foco perdido. |

@mdtauk , observando seu comentário sobre os idiomas LTR e RTL e o lado do controle em que os botões UpDown aparecem. Vou fazer isso por especialistas em localização para garantir que seja uma consideração que precisa ser levada em consideração.

@mrlacey você também está certo ao dizer que o booleano seria redundante para um enum. Tentarei verificar em breve se alguma configuração alternativa é necessária.

@adrientetar , você é nosso principal cliente de botões verticais. Você tem recortes de tela ou contexto que possam me ajudar a entender melhor suas limitações de espaço? @mdtauk me fez pensar com esta resposta anterior:

Um pensamento inicial é: será que o número no contêiner será grande o suficiente onde uma orientação vertical seria necessária? O AutoCompleteBox não move o botão Pesquisar e as strings são geralmente mais longas do que números.

@SavoySchuler (em relação à redefinição para o último valor revisão do

Considere isto:

1. NumberBox com AllowsCalculations=True
2. insira manualmente 1100 e vá para o próximo controle
3. perceber que não era isso que eu queria entrar
4. volte para o controle e digite "99 x 12"
5. guia para o próximo controle e o valor volta a exibir "1100" ('x' não é o mesmo que '*', portanto, falhará na etapa de cálculo. Ou considere qualquer outro cálculo inválido que falhe se 'x' não ' t ser exibido se pressionado.)
6. Agora mostra um valor que não é o resultado do cálculo, nenhuma mensagem de erro é exibida e a soma inserida é perdida, portanto, não há registro do que aconteceu.

O que eu gostaria que acontecesse quando a guia para o próximo controle na etapa 5 fosse

• "99 x 12" permanece o Text
• O estado de erro é mostrado.
• Evento ValueChanged acionado e aprovado (Texto = '99 x 12 ', OldValue = 1100, NewValue = Double.NaN)
• O usuário pode então ver que algo estava errado
• O usuário pode corrigir o problema sem precisar inserir novamente a soma inteira.
• A lógica do código / aplicativo é capaz de fazer algo apropriado, se necessário.

Se for reverter automaticamente para o último valor válido conhecido na entrada:

• Além de quando nenhum valor for inserido em um campo obrigatório, o estado de erro será indicado?
• Não é o valor de ter o evento ValueChanged grandemente diminuído, já que nunca relataria um estado inválido?

@SavoySchuler @mrlacey Olhando esses exemplos em outros aplicativos da Microsoft ...

Quaisquer pop-ups modais devem ser descartados. Em vez disso, isso deve ser tratado por um estado de validação no próprio controle.

IMAGEM

Se houver um valor inválido, talvez o conteúdo deva permanecer nesse estado inválido, mas apenas enquanto o controle estiver em foco. Se o foco for perdido, o valor do Campo de texto será revertido, mas o aviso de validação exibe o que o usuário inseriu?

InputScope: Number or FormulaNumber?

Como mencionado anteriormente (em um comentário de RP), FormulaNumber não inclui 'espaço' que todos os exemplos de cálculo aqui e nas especificações incluem. FormulaNumber também inclui símbolos matemáticos que não são suportados por este controle

Eu voto em 'Número'

Número

FormulaNumber

@SavoySchuler Quero dizer, estou apenas fazendo um aplicativo de desktop (não estou tentando fazer minha própria versão do Excel ou algo assim). Acho que vou apenas desativar as setas por completo, o arrastar do mouse será suficiente, eu acho. Se o arrastar do mouse for planejado, talvez a mudança de valor deva ser acionada em cada mudança, porque o usuário deseja visualizar uma série de mudanças possíveis nesse caso. A barra lateral:

Aliás, o conteúdo de TextBox não centralizará verticalmente, e isso ocorre com VerticalContentAlignment = "Center".

É semelhante ao tipo de barra lateral de propriedade que o Paint 3D usa (que também usa seu próprio estilo de controle com bordas mais finas e claras e o que parece ser uma propriedade de sufixo)

Se arrastar não deve ser implementado, então você sempre pode fazer o que o Paint 3D fez, e ter um controle deslizante vinculado ao NumberBox.

Também é semelhante ao que a Adobe faz por ter um controle deslizante suspenso em seu controle.

@adrientetar Você parece estar fazendo sua própria versão de uma NumberBox lá. O texto em seu TextBox teria um alinhamento de linha de base, já que as fontes terão descendentes que precisam ser contabilizados.

Para o NumberBox, pode haver o caso de ter caracteres visualmente centralizados, mas esses NumberBoxes não se alinham quando colocados ao lado de um TextBox padrão ou controle derivado de TextBox como ComboBoxes.

Ao criar os modelos e estilos padrão, você deve considerar as várias propriedades Windows.UI.Xaml.Documents.Typography ...

• Typography.CaseSensitiveForms
• Typography.NumeralAlignment + Typography.NumeralStyle (Tabular pode ser preferível a Proporcional)

@mrlacey , você apresenta um argumento válido. Com base na resposta de @adrientetar , que tal o seguinte cenário:

Os eventos de alteração de valor / texto são acionados em _cada_ alteração (para casos em que os usuários de arrastar / rolar estão testando o intervalo) e, portanto, a validação pode ocorrer continuamente onde a mensagem de erro e o indicador são exibidos até que "Enter" seja pressionado / o foco seja perdido, em Nesse caso, a substituição do valor de validação entra em ação e substitui o último valor válido (a menos que esse comportamento seja desabilitado por sua respectiva propriedade).

Vou conversar com a equipe esta tarde para validar se esse evento constante de disparo / validação é uma ideia realista - caso contrário, podemos construir o limite de alcance de outra maneira.

@mdtauk , mas acredito que você está correto com suas afirmações sobre a representação visual de validação. @LucasHaines , você pode me checar?

@jevansaks , você pode opinar sobre a consideração do InputScope a seguir?

Como mencionado anteriormente (em um comentário de RP), FormulaNumber não inclui 'espaço' que todos os exemplos de cálculo aqui e nas especificações incluem. FormulaNumber também inclui símbolos matemáticos que não são suportados por este controle

Eu voto em 'Número'

Número

FormulaNumber

@SavoySchuler é isso

Os eventos de alteração de valor / texto são acionados em cada alteração (para casos em que os usuários de arrastar / rolar estão testando o intervalo) e, portanto, a validação pode ocorrer continuamente onde a mensagem de erro e o indicador são exibidos até que "Enter" seja pressionado / o foco seja perdido, em Nesse caso, a substituição do valor de validação entra em ação e substitui o último valor válido (a menos que esse comportamento seja desabilitado por sua respectiva propriedade).

ValueChanged evento Value real mudar, e não sempre que o Text mudar.

a menos que esse comportamento seja desativado por sua respectiva propriedade

O que é essa nova propriedade?

Não sei como eventos mais frequentes resolvem o problema de valores incorretos e estados de erro sendo perdidos ao reverter para um último valor válido conhecido.
Eu sinto que alguma experimentação é necessária aqui para entender como isso realmente será. (Se eu pudesse encontrar tempo ...)

Em uma nota relacionada.

Estou assumindo que o evento TextChanged herdado de TextBox não será modificado para o consumidor. Mas e o evento TextChanging ? Será aqui que o novo processamento específico de controle é feito? O consumidor do controle será capaz de lidar com este evento também?

Concordo - vale a pena explorar, mas é melhor evitá-lo. Revisei a seção sobre Validação e adicionei uma propriedade IsInvalidInputOverwritten que é desabilitada por padrão. O que todos pensam sobre o seguinte:

• A entrada que não é numérica forumática ou excede os valores mín. / Máx. Acionará um aviso de validação de entrada .
• O desenvolvedor pode interceptar os eventos ValueChanged ou TextChanged (o que expõe a propriedade alterada e aquela a ser atualizada) e manipular manualmente a entrada inválida antes que um aviso de validação de entrada seja exibido.
• Habilitar a propriedade IsInvalidInputOverwritten reverterá a entrada inválida para o último estado válido sem exibir o aviso de validação de entrada . Por exemplo, se IsInvalidInputOverwritten estiver habilitado, StepSize = 0.2, MaxValue = 3.0, e o valor 2.9 for incrementado, 3.1 será registrado como inválido e será sobrescrito de volta para 2.9.

Muito disso poderia ser resumido com a questão de se a validação deve acontecer durante a entrada ou depois. Eu inclino depois por uma questão de desempenho e porque a experiência de receber validações enquanto você digita pode ser chocante e pouco acessível - o que leva o que precede a ser minha implementação preferida atualmente.

FWIW, Adobe Photoshop e Illustrator voltam ao valor anterior quando você tenta inserir um valor inválido. Este possui o comportamento de cálculo, mas o sufixo da unidade de medida faz parte do texto, o que por si só pode causar problemas de validação :)

Queria lançar uma ideia sobre a qual eu estava em conflito - lembro-me de muitas experiências anteriores em que tive alguma caixa de número de classificação com funcionalidade de incremento / decremento, ir abaixo do valor mínimo me levaria de volta ao valor superior, e vice versa. Eu queria ver se algo como uma propriedade _ValuesWrap_ faz sentido aqui.

Obviamente, isso não faz sentido em todos os casos, mas em casos de intervalo numérico limitado, foi intuitivo para mim no passado assumir que os números são agrupados em casos como a entrada de Idade ou Data de nascimento ou para outros casos de intervalo pequeno. Por outro lado, às vezes isso ocorre apenas porque, nesses casos, uma caixa de seleção de múltipla escolha está sendo usada e, normalmente, agrupa os valores em vez de parar. Só queria verificar se há alguma justificativa ou necessidade para isso - é claro que provavelmente também poderia ser implementado no lado do desenvolvedor por meio de qualquer evento onValueChanged com trabalho extra.

cc @SavoySchuler

Ótima ideia, @KevinTXY. Se algum de nossos desenvolvedores precisar de algo assim, podemos adicionar!

Tempo de perguntas: alguém tem algum cenário real de aplicativo que justifique a necessidade de suporte para hexadecimal ou binário? Envolvendo valores máx. / Mín.?

Eu queria ver se algo como uma propriedade ValuesWrap faz sentido aqui.

sim, se você tem uma propriedade de ângulo, você deseja ir 359 → 0, basicamente mod 360. O engraçado é que eu ainda tive que criar uma subclasse do controle (estava no Qt) porque MaxValue só poderia ser inclusivo, então eu poderia especificar 359 ou 360, mas eu realmente queria ser capaz de escrever 359,99, mas não 360 (ou seja, eu queria <, não ≤).

O QSpinBox tem uma propriedade de empacotamento para esse fim https://doc.qt.io/qt-5/qabstractspinbox.html#wrapping -prop

@SavoySchuler Com relação ao hexadecimal, eu suspeito que um editor hexadecimal poderia querer isso, mas parece um caso de uso de nicho, você não tem que oferecer suporte a todas as coisas possíveis, apenas certifique-se de que o controle seja fácil de subclassificar. No Qt, o controle tem um método que converte a string da caixa de texto em um valor numérico (int ou double) que pode ser sobrescrito.

Por exemplo, se IsInvalidInputOverwritten estiver habilitado, StepSize = 0.2, MaxValue = 3.0, e o valor 2.9 for incrementado, 3.1 será registrado como inválido e será sobrescrito de volta para 2.9.

Você provavelmente poderia fixar em MaxValue nesse caso.

@SavoySchler @xyzzer @mrlacey Eu vi no twitter que algo está chegando em 20H1 que fornece entrada de texto preditivo.

Isso pode interferir no recurso de conclusão de visualização de que falamos e pode precisar ser suprimido no controle NumberBox. Chegando aos controles Win32 e XAML, parece ...

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

Eu presumiria que lidar com hexadecimais ou binários são cenários ainda mais especializados do que lidar com "strings que se parecem com números", como números de telefone e códigos postais. (e trazem sua própria complexidade)
Como tal, acho que eles deveriam estar fora do escopo do controle NumberBox.

Falando sobre o recurso de cálculos de visualização, caso ele tenha sido perdido, eu proporia dar ao usuário a opção de ligá-lo / desligá-lo. Então, talvez adicionando uma propriedade como

public bool ShowPreviewResult { get; set; }

Por que você mostraria o resultado da visualização? 🤔 Não que o usuário altere sua fórmula dependendo do resultado, se souber o resultado que deseja, basta digitá-lo imediatamente

Por que você mostraria o resultado da visualização? 🤔 Diferentemente do que o usuário faria, dependendo do resultado, se souber o que quer, basta digitar imediatamente

Um dos recursos do controle é ser capaz de entrar em um cálculo, como 32 * 4, que resolveria como 128 - o recurso de visualização mostraria qual seria o resultado quando o controle perder o foco ou Enter for pressionado.

@adrientetar A pré-visualização é um recurso provisório a partir de agora. Acredito que o valor estaria parcialmente na validação orientada ao usuário antes que a validação do controle seja iniciada, por exemplo, ele só mostra se o que foi inserido pode ser calculado / está dentro dos limites; por exemplo, verificar as expectativas ("Eu acertei vezes em vez de mais?"). O interesse e o retorno do investimento aqui ainda não estão claros.

Obrigado pelo feedback novamente, todos! Parece que não há necessidade urgente ou justificativa de interesse no suporte binário ou hexadecimal por enquanto. Ele também pode ser subclassificado, proposto como um novo controle ou proposto para V2, conforme necessário.

@SavoySchuler com relação a "Alguém tem algum cenário de aplicativo real que justifique a necessidade de suporte para hexadecimal ou binário?", Um exemplo é o próprio controle ColorPicker do WinUI. Inclui uma caixa de entrada hexadecimal. Ele também inclui uma série de outras TextBoxes de entrada de número. Pode valer a pena examinar a possibilidade de atualizar o ColorPicker para usar o novo controle NumberBox como uma forma de validar o novo controle. Se a NumberBox puder simplificar a implementação atual do ColorPicker, isso será uma vitória.

Caso o estilo de borda mais fina para as caixas de texto não ultrapasse a tomada de decisão do @chigy e da equipe de design do WinUI - achei que deveria preparar um mock up de design que correspondesse às propostas atuais para o design da caixa de texto.

@kmahone - concordou. Como você mencionou no refrigerador de água esta manhã, ser capaz de remover muitos códigos do ColorPicker substituindo suas instâncias de TextBox + lógica de validação local por NumberBox pode ser uma vitória por si só.

@mdtauk - eu já disse muitas vezes que suas maquetes parecem incríveis? Vou colocá-los nas especificações em breve!

@SavoySchuler Se a equipe de Design do Windows

Com certeza, @mdtauk! Espero bloquear os requisitos funcionais para @KevinTXY aqui no futuro em breve e irei passar para aquela conversa sobre convergência de design com @chigy (que tem estado ocupado fazendo um trabalho incrível no # 524) então!

Obrigado por toda a discussão a todos, estou muito feliz em trabalhar nesse recurso neste verão como estagiário!

Se for relevante para alguém, comecei um protótipo C # do controle no repositório a seguir.
https://github.com/KevinTXY/NumberBox

Esta é essencialmente minha primeira vez aprendendo C # / UWP, então vai acontecer lentamente e se alguém olhar para ele, fico feliz em receber feedback sobre o que poderia ser feito melhor!

Os seguintes recursos são implementados de forma aproximada:

• Validação de entrada numérica (ainda não segue as especificações da proposta de validação , irá aguardar o código para isso)
• Armazenamento / ligação de valor
• Corte zero
• Calculadora completa / suporte para entrada de fórmula

Atualmente trabalhando em botões giratórios e coisas de aplicativos de teste, bem como Validação Mín / Máx.

Saúde!

Atualização da linha do tempo!

Eu integrei várias atualizações, sugestões e comentários na especificação que irei validar com a equipe WinUI hoje (quinta-feira). Espero finalizar mais ou menos a API e os componentes comportamentais para V1 ao fazer isso.

Agora, irei para Entradas e Acessibilidade, Dados e Inteligência e Componentes Visuais.

A última etapa será organizar a documentação e formar as diretrizes.

Acho que a opção desarticulada e contígua é um nicho muito específico, sem um caso de uso que os aplicativos / interface de usuário de shell primários da Microsoft precisaram fazer no WPF ou no Win32.

Se você quiser incluí-lo, prefiro que seja um estilo incluído que você possa aplicar ao controle, do que uma opção. Como os controles NumberBox reformulados lidariam com essa propriedade, em seus novos modelos?

Se houver consenso de que esse modo deve ser incluído, posso sugerir que ele se torne um valor enum como parte de SpinButtonPlacementMode . Não tenho certeza de como essa opção seria chamada. _Straddled_ talvez não seja profissional o suficiente lol, e eu não tenho certeza se _Bookended_ é melhor.

Eu estava apenas olhando para a versão mais recente do Canary do Edge e vi o design de um <input type="number"/> que é o mais próximo de um controle NumberBox.

Só pensei em compartilhar essa imagem dele.

@mdtauk - concordado, SpinButtonPlacementMode seria o lugar certo para adicionar opções alternativas de posicionamento de SpinButton.

Sobre o assunto de nomes, @Felix-Dev corretamente veio à tona na especificação de que SpinButton pode não ser o nome mais intuitivo ou conhecido. SpinBox e UpDownButtons também têm precedência no ecossistema do Windows. Eu vou investigar isso mais em breve, mas por favor, deixe-me saber se alguém tem um caso contra qualquer uma dessas opções.

@mdtauk - Obrigado por compartilhar isso! Também estou administrando o Canary, então vou dar uma olhada e ver se há algo que possamos aprender ou se há espaço para sugerir o alinhamento dos desenvolvimentos!

@SavoySchuler Estou usando o sinalizador Fluent Controls Ativado (incluindo controles experimentais)

Acho que a implementação do WinUI seria um design mais elaborado que o Fabric Web e o Edge deveriam considerar, mas o alinhamento é uma boa coisa a se fazer.

Número do tipo de entrada w3schools

Além disso, esse controle deslizante está próximo, mas não é exatamente o mesmo que o WinUI planeja fazer (polegar de círculo delineado, em comparação com um polegar de círculo preenchido)

Ainda não tenho certeza de como posso definir os recursos de localização. Nos Estados Unidos, o ponto é usado como separador decimal. Na Holanda (onde moro) usamos a Vírgula. O separador de agrupamento nos EUA é a vírgula, mas na Holanda é o ponto.

Exemplo:

Devo usar a propriedade Language do elemento Framework para especificar o separador Digit and Grouping?

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

Eu estava apenas olhando para a versão mais recente do Canary do Edge e vi o design de um <input type="number"/> que é o mais próximo de um controle NumberBox.

Só pensei em compartilhar essa imagem dele.

@mdtauk , @SavoySchuler ,
Não sei de onde veio esse controle. De acordo com meu contato na equipe do Edge, aqui estão os controles que eles estariam usando.

Controle deslizante: https://explore.fastdna.net/components/slider/
Caixa numérica: https://explore.fastdna.net/components/number-field/

Não tenho certeza se eles vão atualizar o visual e a saída final pode não ser exatamente assim (suponho que sim, mas esse é o meu palpite).

@chigy Essa imagem era da versão Canary atual do Edge, mas, como observei, é um WIP e é um sinalizador opcional que você ativa.

Acho que isso explica para que serve esse projeto fastdna, que mencionei em uma edição anterior. 🙂

Devo usar a propriedade Language do elemento Framework para especificar o separador Digit and Grouping?

Essas configurações geralmente vêm da "região", então acho que passaríamos apenas de

Não vejo uma maneira de personalizar os caracteres separadores na API DecimalFormatter, portanto, eles devem ser extraídos das configurações de idioma. 😖

@jevansaks , obrigado pelo insight! Vou marcar @sonnemaf para garantir que ele veja a resposta.

@jevansaks você pode escrever um exemplo de xaml como DecimalFormatter para o NumberBox? Quero defini-lo em XAML e não de codebehind. Ter as propriedades DecimalSymbol e GroupingSymbol também funcionaria para mim. No entanto, isso pode ser muito 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?

Desculpe interromper. Acabei de descobrir este tópico, mas SIM SIM SIM. Ambos estão faltando frequentemente em controles numéricos e eu e muitos outros desenvolvedores no github temos que ter soluções alternativas para isso. Especialmente com o exemplo da calculadora, ela não deve apenas formatar um número em hexadecimal, mas suporta totalmente a entrada.

Neste momento, gostaria de sugerir que você torne o prefixo de hexdecimais personalizável. Em algum ponto é melhor não ter nenhum prefixo e em outros pontos nem sempre é 0x

você pode escrever um exemplo xaml de como DecimalFormatter para o NumberBox? Quero defini-lo em XAML e não de codebehind. Ter as propriedades DecimalSymbol e GroupingSymbol também funcionaria para mim. No entanto, isso pode ser muito fácil.

@sonnemaf tudo o que temos para trabalhar no WinRT é DecimalFormatter e, infelizmente, não permite que você personalize essas configurações. A única maneira de personalizar o símbolo decimal ou símbolo de agrupamento é através das configurações do usuário no painel de controle da região do sistema operacional (até onde eu posso dizer).

Respeitar a região do usuário para essas configurações parece correto - você tem um cenário em que precisa substituí-las?

@sonnemaf

Alguém tem algum cenário real de aplicativo que justifique a necessidade de suporte para hexadecimal ou binário?

Desculpe eu percebi isso e respondi um pouco tarde. Acredito que o suporte hex / binário seria muito útil. Estou fortemente envolvido com o projeto .NET IoT e trabalhamos principalmente no mundo hex / binário, pois estamos manipulando bits / bytes que lêem / gravam em registradores e pinos para controlar as coisas.

Apoiar hex / binário seria muito grato. Thx 😄

Eu não preciso de hex ou binário. Seria 'bom ter', especialmente binário.

Dev Update

Olá a todos! Estamos ficando satisfeitos com a especificação da NumberBox e só quero chamar a atenção de que estou trabalhando ativamente no controle . Idealmente, um primeiro PR com as funcionalidades mais importantes será feito muito em breve, possivelmente esta noite.

Algumas notas:

• Optamos por não criar uma subclasse de TextBox principalmente devido a algumas complicações de design com InputValidation, NumberBox será seu próprio controle contendo um TextBox.
  
  
  
  • Isso significa que todas as propriedades TextBox não serão expostas. Estou curioso para saber se algum desses é importante trazer para NumberBox - posso ver o desejo de _Header, PlaceHolderText_ e talvez também _Text_? Definitivamente, queria abri-lo um pouco, porque é uma mudança muito fácil de fazer do meu lado.
  
  
• Tenho feito edições muito pequenas nas especificações; a maioria delas são apenas correções de redação por enquanto, mas ainda há questões em aberto, como visualização de valor, e conforme escrevo o controle, estou gerando algumas de minhas próprias questões de design. Este ainda é um bom momento para adicionar informações 😄

@KevinTXY Houve uma sugestão para derivar da base do Slider em vez de TextBox - foi isso que foi escolhido?

• PlaceHolderText
• Cabeçalho
• Texto
• Ícone de Validação
• Mensagem de Validação
• SelectionForeground
• SelectionBackground
• Estados / recursos focais, etc.

Estas são algumas das coisas do TextBox que eu acho que são necessárias. Não tenho certeza sobre o botão "limpar texto", que faz mais sentido com longas sequências de texto.

Visualização de valor Eu pensei que fosse um recurso V2, mas isso mudou? O controle Slider tem uma dica de ferramenta que mostra o valor, como slides de miniaturas. Eu sugeri isso como uma maneira de lidar com isso, bem como usar a mensagem de validação para lidar com isso, ou exibi-la embutida.

Inline tem um problema com o fato de que o Windows Insider cria experiências com preenchimento preditivo de texto, seja aparecendo como uma dica de ferramenta ou dentro dos campos de texto. Qualquer que seja o método de visualização escolhido, ele não deve entrar em conflito com aqueles ou com aquele recurso preditivo desativado para este controle.

@KevinTXY Houve uma sugestão para derivar da base do Slider em vez de TextBox - foi isso que foi escolhido?

NumberBox é atualmente seu próprio controle (estende Windows.UI.Xaml.Controls.Control) que contém um TextBox em sua marcação em vez de estender TextBox. O controle deslizante parece interessante, mas acho que faria com que a implementação fosse um pouco "hackeada". Também há muitas propriedades nesses controles que achamos que não pertenciam a NumberBox. Não sou um gerente de projetos, mas com base na minha experiência em desenvolver isso, acho que esse é um bom caminho para simplificar o desenvolvimento e para futura extensibilidade.

Estas são algumas das coisas do TextBox que eu acho que são necessárias. Não tenho certeza sobre o botão "limpar texto", que faz mais sentido com longas sequências de texto.

Isso é incrível - exatamente o que eu estava procurando! Eu concordo que há valor em tudo isso. O botão Limpar tudo está lá atualmente, pois é um recurso padrão do TextBox - suponho que tenha valor para entradas grandes ou usuários de tela de toque, embora eu realmente não tenha pensado em desativá-lo ainda. Definitivamente, vou pelo menos tentar colocar os três que mencionei (Header, PlaceholderText, Text) na visualização.

Quanto à visualização do valor, nada é finalizado lá e está apenas na especificação como uma questão em aberto. Suponho que a solução temporária mais fácil seria simplesmente expor o valor de visualização para os desenvolvedores exibirem como desejarem - isso poderia estar facilmente no escopo da versão de visualização, mas vou deixar para @SavoySchuler & Co. fazer chamadas. Provavelmente, os cálculos nem chegarão ao meu relatório por pelo menos alguns dias enquanto estou pesquisando mecanismos matemáticos, então não é um detalhe urgente. Agradeço a pesquisa feita, há muitas ideias interessantes aqui!

@KevinTXY Idealmente, deveria haver uma colaboração com a equipe da Calculadora, para criar um mecanismo de cálculo básico que pudesse ser incorporado - bem como para uso futuro com a ideia CalculatorPicker que foi discutida junto com este controle. (Um controle com um botão Calculadora, que exibe um menu desdobrável com uma calculadora padrão)

Na verdade, a colaboração com os mantenedores da Calculadora parece uma ótima ideia. Você poderia expor um serviço de aplicativo da Calculadora que realizaria os cálculos matemáticos, então você não precisaria nem mesmo carregar o binário WinUI - apenas fale com o serviço de aplicativo se o aplicativo estiver instalado e caso contrário - apenas falhe silenciosamente.

Quanto a derivar de Slider - eu disse RangeBase e ainda estou bastante confiante de que é a coisa certa a fazer, pois o controle basicamente fornece quase todas as propriedades e recursos de acessibilidade de que você precisa e derivando dele fornecerá superfície de API consistente entre seu controle e o Slider tornando-os substituições fáceis de trocar.

Ah sim, RangeBase, era isso.

A Calculadora acabou de trabalhar para oferecer suporte a um modo CompactOverlay sempre ativo - portanto, colocar um teclado menor em um menu desdobrável semelhante em tamanho ao CalendarFlyout - é mais alcançável. (Se o controle CalculatorBox for aprovado para inclusão.

Não tenho certeza se é um serviço de aplicativo (que vincularia atualizações do WinUI semi-dependentes das atualizações da loja da Calculadora - ou se é um binário de serviço que pode ser adicionado ao WinUI e derivado do mecanismo da Calculadora.

Atualização: Agora existe um Código de RP 🎆!

Estou rastreando alguns problemas, embora a maioria não esteja relacionada ao design.

Obrigado, @xyzzer e @mdtauk! Verificamos o RangeBase e ele parece carregar tanta bagagem quanto uma subclasse de TextBox carregaria. A partir de agora, vamos nos limitar a conter um TextBox no controle e adicionar apenas as propriedades e recursos de acessibilidade necessários. Isso ainda foi uma consideração que valeu a pena e ajudou a informar nossa conversa sobre acessibilidade que está ocorrendo agora.

@mdtauk , obrigado pela lista inicial! @KevinTXY começou a expor as APIs que você listou e irei revisar o resto em breve.

Pré-visualização e calculadora pop-up, como @KevinTXY mencionado, nas conversas (embora não haja garantia v1 aqui). Estamos conversando ativamente com a Calculadora sobre alinhamento e trabalho potencializável. Caras, vocês são incríveis! Obrigado por continuar a impulsionar a inovação neste controle. É incrivel. @KevinTXY tem seu Código de RP publicado acima. Vou amarrar todas as pontas soltas restantes na especificação antes de passar para o rascunho de Orientação e Documentação.

Nomeação

Houve tantos comentários que as especificações escaparam de mim, então estou apenas começando a dar uma olhada depois que as coisas se acalmaram. Primeiro, notei alguns nomes que realmente não seguem a convenção C # - sim, eu sei que esses controles são escritos em C ++, mas ainda acho que são inconsistentes com outros nomes na plataforma.

| Tipo | Nome atual | Nome proposto |
| ------- | ---------------- | ------------------- |
| Boolean | AcceptsCalculation | IsCalculationAccepted |
| Boolean | HyperDragEnabled | IsHyperDragEnabled |
| Boolean | HyperScrollEnabled | IsHyperScrollEnabled |

StepFrequency

Além disso, o que é StepFrequency? Isso não está definido na especificação e não tenho nenhuma experiência com "NumericUpDown do XAML Toolkit". Dependendo do que isso faz, adicionar a palavra Frequência pode não fazer sentido. Provavelmente é apenas um "passo"? No controle Slider, TickFrequency faz sentido porque os ticks são mostrados em um módulo do intervalo máximo-mínimo geral. No entanto, neste controle, acho que este é apenas o tamanho mínimo de incremento / passo. Fundamentalmente, o usuário será capaz de inserir um valor que está fora da etapa?

Por exemplo MinValue = 0, MaxValue = 6, StepFrequency = 2. Usar o valor da seta para cima será {2, 4, 6} justo. O usuário pode digitar 0,5 como um valor válido? Ou será arredondado para 0 ou 2 dependendo do RoundingMode?

Min / MaxValue

Para as duas propriedades abaixo, acho que devem ser apenas Mínimo e Máximo como em outros controles (Slider, RangeBase). APIs devem ser consistentes.
Double MinValue;
Double MaxValue;

Botões de repetição para cima e para baixo

Outro recurso que não foi discutido até onde eu sei é se os botões para cima / para baixo devem ser realmente RepeatButtons (acho que deveriam ser). Se forem botões de repetição, as propriedades de Atraso / Intervalo devem ser adicionadas como o controle Slider: Slider.Interval Slider.Delay

Dígitos

Você pode adicionar uma descrição para o que IntegerDigits e FractionDigits representam? Meu palpite é que eles limitam o número de dígitos para cada parte do número. IntegerDigits = 2 significa que o valor máximo pode ser 99. FractionDigits = 3 significa que MaxValue pode ser 0,999. Além disso, como SignificantDigits substitui essas duas propriedades?

Zero negativo?

Por que essa propriedade é necessária? Isso é uma coisa de localização em si? Nunca vi "-0,0" ou "-0". É sempre apenas "0".
Boolean IsZeroSigned;

Localização

Estou inflexível de que preciso desse controle para dar suporte à substituição da localização da IU e do formato de número. Tenho vários usos (aplicativos financeiros) onde preciso de valores locais e estrangeiros que devem ser exibidos de forma diferente. Não vejo isso em nenhuma parte das especificações.

A conversão de duplo em texto deve ser personalizável via ValueConverter, no espírito de Slider.ThumbToolTipValueConverter. Dessa forma, a parte mais complexa pode ser personalizada para qualquer necessidade, como em alguns exemplos do mundo real abaixo:

Observe que o separador decimal para números e dinheiro pode ser diferente, assim como a designação das somas negativas, então provavelmente a abordagem mais segura para NumericBox sem ValueConverter é operar no modo inteiro. A calculadora também pode ser implementada como ValueConverter, não há necessidade de sobrecarregar o controle com este trabalho.

@eugenegff Você realmente teve uma boa idéia de tornar a conversão de número em string genérica. Isso me permitiria lidar com a localização, mas também permitiria que os desenvolvedores fizessem qualquer outra coisa que desejassem, como adicionar unidades.

A única complexidade que vejo é manter um Culture / NumberFormatInfo relacionado ao controle. Eu acho que isso poderia ser um parâmetro de conversor em XAML indo para IValueConverter personalizado, mas provavelmente deve haver uma maneira mais limpa de lidar com isso no próprio controle.

Por que essa propriedade é necessária? Isso é uma coisa de localização em si? Nunca vi "-0,0" ou "-0". É sempre apenas "0".

É uma propriedade da classe DecimalFormatter no Windows. É estranho? Provavelmente. Existem algumas propriedades como IsGrouped e propriedades de localização que deixamos de fora, então talvez esta também não seja necessária. Ao mesmo tempo, ele também já está implementado, portanto, removê-lo não teria outro propósito a não ser revelar 3 linhas de código. Curiosamente, existem usos e pré-requisitos IEEE para zeros assinados .

Estou inflexível de que preciso desse controle para dar suporte à substituição da localização da IU e do formato de número. Tenho vários usos (aplicativos financeiros) onde preciso de valores locais e estrangeiros que devem ser exibidos de forma diferente. Não vejo isso em nenhuma parte das especificações.

@SavoySchuler talvez devêssemos dar uma olhada no suporte às configurações de Idiomas na classe DecimalFormatter. Não estou familiarizado com o seu comportamento.

Ok, acho que entendo o problema fundamental aqui. No mundo C ++, você tem acesso a DecimalFormatter, mas no mundo C # (se eu consumisse WinUI), normalmente usaria um IFormatProvider (NumberFormatInfo de uma cultura especificada). NumberFormatInfo já tem a maioria das propriedades (faltando IsZeroSigned coincidentemente), então eu estava pensando apenas em permitir que os desenvolvedores especifiquem isso ou um IFormatProvider. Bem, aí está o problema, C ++ não pode usar um IFormatProvider porque é do mundo .net.

Então, como esse controle oferece suporte total à localização em C # e C ++, considerando que eles têm duas maneiras diferentes de fazer isso? Bem, a menos que a Microsoft tenha uma solução inteligente, só consigo pensar em duas possibilidades:

1. Adicione totalmente todas as propriedades para formatação de número (reimplementando efetivamente NumberFormatInfo e DecimalFormatter). Adicionar apenas IsZeroSigned, IntegerDigits, FractionalDigits, etc. não vai cobrir isso. NumberNegativePattern, NumberGroupSeparator, NumberGroupSizes etc. também são necessários.
2. Faça como @eugenegff sugeriu e permita que os desenvolvedores substituam a formatação com algum tipo de retorno de chamada. Honestamente, essa parece ser a abordagem mais fácil.

Estou um pouco preocupado com a forma como a localização está se configurando nesse controle. Venho trazendo a localização desde o início (3º comentário sobre este tópico!). Deve haver alguma maneira de personalizar totalmente o formato do número quando o controle for convertido em uma string. Sem isso, esse controle será bastante limitado no uso no mundo real.

Então, como esse controle oferece suporte total à localização em C # e C ++, considerando que eles têm duas maneiras diferentes de fazer isso?

Nós ouvimos você! É algo que temos investigado offline, mas fundamentalmente .NET faz sua própria localização separada da plataforma. Acho que um retorno de chamada para substituir é uma grande saída de emergência, mas tenho esperança de que sua opção 1 seja o caminho que podemos seguir. No momento, as APIs do WinRT para formatação e análise não têm todos os botões de personalização de que precisamos. Ainda estamos investigando.

Não verifiquei se isso já foi discutido, mas gostaria de perguntar rapidamente se alguém vê uma grande necessidade ou, mais importante, qualquer precedente para suporte de função para cálculos, ou seja, qualquer um dos itens abaixo ou mais:
cos(), sin(), tan(), asin(), acos(), atan(), sqrt(), log(), abs(), ceil(), floor(), degree equivalents of trig functions, hyperbolic functions, etc

Estou juntando analisadores matemáticos para atender às nossas necessidades e as funções complicam o processo de conversão para RPN (que disse que já tenho uma versão que suporta esses com alguns bugs), então estou interessado em ver se algum deles vale a pena o problema ou se parece inchaço. Eu pessoalmente não acho que se encaixa muito bem, mas se houver muitos precedentes, não será muito problemático.

Eu acho que eles não seriam muito detectáveis ​​na maioria dos casos e se alguém precisar de suporte para funções mais complicadas - é melhor trabalhar abrindo a análise para um evento de retorno de chamada, permitindo que os usuários implementem sua própria análise ou lógica de pré-processamento.

O que seria mais valioso é permitir começar a digitar no texto com um operador, então se você clicar no texto - ele selecionará todos por padrão e você poderá digitar um novo valor sem ter que pressionar delete primeiro para excluir o anterior ou simplesmente digite algo como "* 1,2" ou "x1,2" [Enter] e faça com que o valor atual seja multiplicado por 1,2 mesmo que o texto inserido não contenha mais o valor inserido. A mesma coisa funcionaria para "+2", "-5", "/ 3", "% 120", etc.

É usado em algumas aplicações profissionais.

Nós (BeLight Software, projeto Live Home 3D) precisamos de ValueConverter plugável para conversão de texto de valor <=>, caso contrário, NumberBox não seria adequado para nós.

Acho que o uso dessas funções seria muito raro, tenho uma entrada de ângulo em meu aplicativo, mas é apenas um valor de grau. O uso mais importante para mim é poder adicionar um valor a um existente ou dividir o existente por um número, apenas para economizar tempo e evitar fazer esse cálculo mentalmente. (Aliás, acho que é isso que os aplicativos Adobe têm, os 4 operadores aritméticos: https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/suggestions/12992463-support-math-operators-in-number -Campos)

Também funciona como cos (), você provavelmente não quer onde não faz sentido, a menos que esteja fazendo algum tipo de aplicativo do Excel.

O uso mais importante para mim é ser capaz de adicionar um valor ao existente ou dividir o existente por um número, apenas para economizar tempo e evitar fazer esse cálculo mentalmente

OK ótimo! Parece semelhante ao que @xyzzer propôs. Vou dar uma olhada em implementações semelhantes e ver se há espaço para fazer isso de uma forma que pareça natural e intuitiva.

Nós (BeLight Software, projeto Live Home 3D) precisamos de ValueConverter plugável para conversão de texto de valor <=>, caso contrário, NumberBox não seria adequado para nós.

Dei uma olhada no exemplo do Slider que você deu e parece muito razoável - pude ver o valor em um IValueConverter para NumBox. Analisarei isso em breve e tentaremos decidir se ele se encaixa nas especificações de maneira adequada. Sem promessas de nada ainda!

@KevinTXY Suspeito que adicionar as funções que você mencionou acima abriria a porta para mais problemas do que o valor que ela pode fornecer. Isso porque permitiria a digitação de um número maior de caracteres (basicamente qualquer letra) no controle. Por sua vez, isso tornaria mais fácil digitar acidentalmente algo inválido e também adicionaria complexidade de validação e análise.
Também quebraria a primeira linha da descrição no início da especificação "A caixa numérica é um controle de texto apenas numérico ...".

Estou surpreso que ainda haja dúvidas sobre a localização. Como o controle será (deve?) Herdar de FrameworkElement ele terá acesso à propriedade Language e, portanto, como qualquer outro FrameworkElement, oferece suporte para definir a localidade diretamente e não depende das configurações de IU da localidade do sistema.
Isso significa que itens como caracteres decimais e de agrupamento podem ser definidos por instância.

Estou surpreso que ainda haja dúvidas sobre a localização.

O problema é que o idioma não é o que controla a formatação, são as configurações de região / cultura. A localização é sobre como obter as strings de IU atualizadas para serem exibidas no idioma correto, enquanto a formatação de número / moeda / data e hora é controlada por região. Mais informações aqui: https://docs.microsoft.com/en-us/globalization/locale/locale-and-culture. E para complicar as coisas, o Windows permite que você personalize suas configurações de localidade na IU substituindo os padrões - então você pode dizer que deseja que o separador decimal seja qualquer caractere aleatório em vez do padrão. Além disso, o .NET permite que os aplicativos personalizem isso também, de modo que os desenvolvedores esperam esse nível de personalização aqui.

O problema é que o idioma não é o que controla a formatação, são as configurações de região / cultura. A localização é sobre como obter as strings de IU atualizadas para serem exibidas no idioma correto, enquanto a formatação de número / moeda / data e hora é controlada por região. Mais informações aqui: https://docs.microsoft.com/en-us/globalization/locale/locale-and-culture. E para complicar as coisas, o Windows permite que você personalize suas configurações de localidade na IU substituindo os padrões - então você pode dizer que deseja que o separador decimal seja qualquer caractere aleatório em vez do padrão. Além disso, o .NET permite que os aplicativos personalizem isso também, de modo que os desenvolvedores esperam esse nível de personalização aqui.

Language assume um valor que é traduzido em CultureInfo note que uma cultura é chamada de localidade no desenvolvimento de código não gerenciado. Ele contém uma propriedade NumberFormat que é um tipo NumberFormatInfo que contém propriedades para decimais, agrupamento, sinais negativos e muito mais.

Meu entendimento é que se você quiser forçar uma formatação específica ou outras especificações de localização em um controle, em vez de depender das configurações do sistema, a maneira de fazer isso é especificar Language .

A descrição da propriedade afirma claramente que ela "define informações de idioma de localização / globalização que se aplicam a um FrameworkElement"

Ou talvez eu tenha entendido mal os documentos que estou fazendo referência, mas todos eles parecem fazer backup do que está coberto na página vinculada.
Talvez seja um problema de terminologia com C ++ e C # usando termos diferentes.
O que eu sei é que definir o idioma em XAML é como eu forçaria uma cultura / localidade em qualquer outro aplicativo e com qualquer outro controle.

As perguntas que tenho visto sobre localização são sobre forçar formatos de número específicos ou separadores de grupo e decimais. Ou é o problema real, como controlá-los sem afetar a localização das propriedades baseadas em texto (Header, PlaceholderText, etc.) do controle?

Language assume um valor que é traduzido em CultureInfo

Não em nativo / WinRT, apenas obtemos uma string de idiomas BCP-47. E esse é o problema. No .NET, você agrupa o CultureInfo, que contém as configurações de idioma e formato. No WinRT é separado e não há um equivalente ao objeto CultureInfo.

Ouvi dizer que as APIs ICU podem permitir o que estamos procurando, mas ainda não tivemos a chance de investigar isso.

Eu acho que a Microsoft terá que considerar ir direto ao ponto e implementar totalmente um mecanismo de conversão entre culturas .net / localização (CultureInfo) e nativo / WinRT. Idealmente, você não estaria considerando uma nova maneira de fazer as coisas:

Acho que a maioria dos aplicativos LOB é escrita em código gerenciado e isso precisa ser feito corretamente desde o início. O WinRT precisa obter os mesmos mecanismos / técnicas de localização do .net e as conversões precisam ser automáticas.

Isso daria muito mais trabalho? Curto prazo: sim, longo prazo: não. Isso provavelmente atrasaria a liberação do controle NumberBox? Provavelmente, a menos que os retornos de chamada fossem usados ​​no curto prazo.

Isso precisa ser feito da maneira certa ou haverá problemas em outro lugar. Já posso prever alguns problemas semelhantes com outros cenários, como CalendarDatePicker editável, etc. (# 735)

@SavoySchuler @jevansaks @chigy @mrlacey @KevinTXY
Aparentemente, a equipe do FastDNA também está trabalhando no controle Spinner para o design do campo de número de entrada e surgiu com uma proposta que pode valer a pena considerar.

Eles também perguntaram por que estamos usando Chevrons, em vez de Setas.

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

Mesmo se mantivermos os botões lado a lado, tendo o design expandido empilhado como um foco, pode ser uma ideia quando a largura do controle é muito estreita? Talvez possa haver algum consenso sobre um layout que funcione em todas as estruturas de IU da Microsoft?

@mdtauk , obrigado por nos avisar.
Verificar com o pessoal do FastDNA se este é o design que eles estão testando e validando a usabilidade.

De volta à NumberBox

Tudo bem, equipe,

Desculpas pelo intervalo inesperado. Estou de volta ao NumberBox a todo vapor e @teaP está se juntando a mim como nosso desenvolvedor de recursos! Ainda estamos planejando o final de novembro para a visualização deste controle, que nos levará a uma versão estável com WinUI 2.4.

Há muita bagagem no fluxo de trabalho antigo, então preservarei todas as perguntas abertas ou respondidas e as transferirei para um novo PR de especificação, onde @teaP e eu terminaremos de resolver nossos tópicos em aberto restantes sobre:

• localização
• design (especialmente em relação aos botões para cima / para baixo)
• hiperscroll / hyperdrag

Observe que o tópico de validação foi resolvido. Com o trabalho de validação de entrada de @LucasHaines sendo programado para o lançamento de planejamento WinUI 3.0 e NumberBox antes disso, reduzimos os modos de validação suportados de NumberBox V1 para:

enum NumberBoxBasicValidationMode
{
Desabilitado,
InvalidInputOverwritten,
};

Com o WinUI 3.0 e o trabalho de validação de entrada de co-requisito, estaremos procurando expandir esse enum com os modos de validação IconMessage e TextBlockMessage originalmente planejados em um NumberBox V2.

Vou retomar todo o nosso progresso anterior agora e postarei perguntas e solicitarei feedback conforme for relevante. Obrigado por ficar com a gente. 😄

Ufa. Estava ficando perto de mim tentar fazer isso sozinho.

Haha, eu gostaria de continuar trabalhando nisso passivamente, mas este semestre me atropelou. Fico feliz em ver que está ficando embrulhado, vou ficar de olho nisso!

Confirmação inicial da NumberBox ao vivo agora!

POR FAVOR - Tenha em mente este é ainda um trabalho em andamento, com acompanhamento de problemas ativa em ambos os dev e PM lado das coisas. Se você encontrar bugs ou pontas soltas gerais em recursos que ainda não foram observados em nenhum dos links apropriados, sinta-se capacitado para nos informar. 😊

@SavoySchuler , você vai abrir um novo PR para a especificação? Além disso, você notou o que escrevo neste comentário, particularmente sobre o display NaN? Obrigado.

@SavoySchuler Alguns comentários sobre o código spec / NumberBox até agora. Esperançosamente, comentários sobre isso podem acabar nas especificações / documentação também. No geral, é ótimo ver isso acontecendo!

StepFrequency

Usar a palavra 'Freqüência' aqui simplesmente não se aplica a mim. No controle Slider, TickFrequency faz sentido porque os ticks são calculados e mostrados em um módulo do intervalo máximo-mínimo geral. No entanto, neste controle, é apenas o tamanho do incremento / passo. É mais um 'StepAmount' ou 'StepValue' - melhor ainda, apenas 'Step' semelhante a 'Minimum' em vez de 'MinimumValue'.

Além disso, o usuário poderá inserir um valor que está fora da Etapa definida?
Por exemplo, Mínimo = 0, Máximo = 6, StepFrequency = 2. Usar o valor da seta para cima será {2, 4, 6} bastante justo. O usuário pode digitar 0,5 como um valor válido? Ou será arredondado para 0 ou 2?

Arredondamento

Como o arredondamento matemático é tratado? Isso é especialmente importante ao inserir valores de moeda usando expressões. Precisamos ser capazes de especificar - ou fornecer - arredondamento personalizado após o cálculo de uma expressão. HalfAwayFromZero é o que estou procurando para começar, mas outros modos de arredondamento também devem ser permitidos.

Localização

Confirme se a NumberBox aceitará qualquer implementação de INumberFormatter /

Quebra de Texto

Edit: Devo ler toda a especificação da próxima vez.

Por que você criou uma nova propriedade 'IsWrapEnabled'? É porque você acha que o termo 'Texto' não se aplica muito bem a uma NumberBox?

Além disso, eu entendo que talvez Wrap e WrapWithOverflow sejam implementados da mesma forma, mas então apenas permita que ambos os valores de enum sejam equivalentes e descreva a funcionalidade na documentação.

Manuseie Corretamente Aceleradores de Teclado

Certifique-se de que este controle seja compatível com o uso do acelerador de teclado melhor do que o TextBox. Talvez isso não possa ser feito até / se TextBox for corrigido, mas # 1435 é realmente um problema para mim que causa muitos problemas. O TextBox irá lidar com uma colagem 'Ctrl + V' e então qualquer KeyboardAccelerator será gerado. No entanto, não há nenhuma maneira dentro do KeyboardAccelerator saber que o TextBox apenas fez seu próprio trabalho.

Um pensamento rápido. Deve haver um Modo de Ângulo que acrescentaria o glifo de grau ao valor (e qualquer lógica para o contorno de 360 ​​°)

°

Ou este apêndice seria melhor tratado no futuro com minha proposta de sufixo para o TextBox # 784

@mdtauk , Adicionar o símbolo de grau seria possível com um INumberFormatter2 - esse é outro bom motivo pelo qual isso precisa ser mantido genérico. Você pode fazer o que for necessário para converter um número em uma string e passar a string de volta para o controle.

Para embrulhar, na verdade é para isso que serve a propriedade IsWrapEnabled ... Preciso ler o final da documentação da próxima vez.

Resumindo, acho que podemos fazer tudo o que você quiser com a API existente.

@mdtauk , Adicionar o símbolo de grau seria possível com um INumberFormatter2 - esse é outro bom motivo pelo qual isso precisa ser mantido genérico. Você pode fazer o que for necessário para converter um número em uma string e passar a string de volta para o controle.

Para embrulhar, na verdade é para isso que serve a propriedade IsWrapEnabled ... Preciso ler o final da documentação da próxima vez.

Resumindo, acho que podemos fazer tudo o que você quiser com a API existente.

Eu sei que o Min, Max, Wrap, lida com isso, mas os graus são comuns o suficiente para ter um modo de ângulo explícito para a caixa? E deve exibir o símbolo no TextBox Text, enquanto o Value interno é apenas o número.

@teaP Olhando para o novo SpinButtonMode compacto, seria possível adicionar uma animação de exibição e ocultação aos botões de rotação sobrepostos?

Você também considerou adicionar acrílico a isso, para melhor combinar ComboBoxes e outros campos de formulário com elementos de submenu?

Edit: Isso resolveria esse problema de visibilidade no Tema escuro. A intenção é combinar a cor em foco do TextBox ou combinar as cores do tema atual? De qualquer forma, o acrílico resolve isso.

@SavoySchuler , você vai abrir um novo PR para a especificação? Além disso, você notou o que escrevo neste comentário, particularmente sobre o display NaN? Obrigado.

@adrientetar com certeza. Quando NumberBox está vazio, Value será definido como NaN (como você solicitou) e PlaceholderText será exibido.

@SavoySchuler Alguns comentários sobre o código spec / NumberBox até agora. Esperançosamente, comentários sobre isso podem acabar nas especificações / documentação também. No geral, é ótimo ver isso acontecendo!

StepFrequency

Usar a palavra 'Freqüência' aqui simplesmente não se aplica a mim. No controle Slider, TickFrequency faz sentido porque os ticks são calculados e mostrados em um módulo do intervalo máximo-mínimo geral. No entanto, neste controle, é apenas o tamanho do incremento / passo. É mais um 'StepAmount' ou 'StepValue' - melhor ainda, apenas 'Step' semelhante a 'Minimum' em vez de 'MinimumValue'.

Compartilhei esse feedback com @MikeHillberg e estamos conversando sobre isso agora. Para ser autodocumentado entre todas as outras propriedades aqui, estamos considerando algo na linha de "SpinButtonStep", caso esse raciocínio seja justificativa o suficiente para desviar. Eu aviso você. Obrigado por levantar o assunto!

Além disso, o usuário poderá inserir um valor que está fora da Etapa definida?
Por exemplo, Mínimo = 0, Máximo = 6, StepFrequency = 2. Usar o valor da seta para cima será {2, 4, 6} bastante justo. O usuário pode digitar 0,5 como um valor válido? Ou será arredondado para 0 ou 2?

O usuário pode inserir qualquer entrada numericamente ou legalmente formula que desejar. Consulte a seção de formatação para obter um exemplo de como usar a propriedade NumberFormatter para forçar essa entrada para a formatação configurada.

O SpinButton só aumentará ou diminuirá esse valor pelo tamanho de etapa SpinButton definido (nome da API agora pendente). Portanto, certifique-se de configurar a formatação e um tamanho de etapa que combinem perfeitamente.

A estratégia de arredondamento usada é definida por meio de sua formatação . Para expor o exemplo DecimalFormatter, aqui está um exemplo de uma propriedade de arredondamento que você pode configurar.

Arredondamento

Como o arredondamento matemático é tratado? Isso é especialmente importante ao inserir valores de moeda usando expressões. Precisamos ser capazes de especificar - ou fornecer - arredondamento personalizado após o cálculo de uma expressão. HalfAwayFromZero é o que estou procurando para começar, mas outros modos de arredondamento também devem ser permitidos.

O arredondamento é feito por meio da formatação . Aqui está um exemplo de uma propriedade de arredondamento que pode ser definida para DecimalFormatter. Acrescentarei um exemplo nas Diretrizes para ajudar a tornar isso mais claro. Obrigado novamente. 😊

Localização

Confirme se a NumberBox aceitará qualquer implementação de INumberFormatter /

Essa é a intenção da implementação atual. Quanto às garantias de futuro, a NumberBox continuará a ter uma solução para as necessidades de localização e formatação. Por agora e no futuro previsível, temos isso implementado.

Quebra de Texto

Edit: Devo ler toda a especificação da próxima vez.

~ Por que você criou uma nova propriedade 'IsWrapEnabled'? Isso vai contra a convenção TextBox / XAML de usar TextBlock.TextWrapping e o TextWrapping Enum. É porque você acha que o termo 'Texto' não se aplica muito bem a uma NumberBox? ~

~ Além disso, eu entendo que talvez Wrap e WrapWithOverflow sejam implementados da mesma forma, mas então apenas permita que ambos os valores enum sejam equivalentes e descreva a funcionalidade na documentação. Criar uma nova propriedade aqui significa apenas que precisamos de novos conversores de valor, etc ... não há razão para quebrar uma convenção existente, eu acho. ~

Manuseie Corretamente Aceleradores de Teclado

Certifique-se de que este controle seja compatível com o uso do acelerador de teclado melhor do que o TextBox. Talvez isso não possa ser feito até / se TextBox for corrigido, mas # 1435 é realmente um problema para mim que causa muitos problemas. O TextBox irá lidar com uma colagem 'Ctrl + V' e então qualquer KeyboardAccelerator será gerado. No entanto, não há nenhuma maneira dentro do KeyboardAccelerator saber que o TextBox apenas fez seu próprio trabalho.

NumberBox contém um TextBox e adiciona propriedades e configurações na parte superior. Vou marcar @jevan porque ele pode ter um entendimento mais abrangente, mas minha intuição é que isso pode precisar ser corrigido no nível de TextBox.

Resumindo, feedback incrível @robloo! Agradeço o tempo que você dedicou para nos ajudar a garantir que sejamos tão abrangentes e completos com a V1 NumberBox quanto podemos ser! Entre em contato se tiver mais perguntas. 😊

@mdtauk

Um pensamento rápido. Deve haver um Modo de Ângulo que acrescentaria o glifo de grau ao valor (e qualquer lógica para o contorno de 360 ​​°)

°

Ou este apêndice seria melhor tratado no futuro com minha proposta de sufixo para o TextBox # 784

Até agora, a NumberBox não oferece suporte à exibição de nenhum caractere não numérico (até mesmo os caracteres de fórmula são removidos na avaliação das expressões).

Acho que sua proposta para o nº 784 é de longe a mais abrangente para nossa plataforma. Se essa proposta não for implementada, ela me parece um recurso V2 apropriado, NumberBox como um substituto.

Já estamos planejando lançar um V2 ao lado ou logo após o WinUI 3.0, pois dois dos modos de validação de entrada altamente solicitados para NumberBox estão bloqueados por precisar do WinUI 3.0. Portanto, estarei abrindo um problema V2 depois que V1 for ao ar e tentarei ter certeza de anotar isso também.

Para ser autodocumentado entre todas as outras propriedades aqui, estamos considerando algo na linha de "SpinButtonStep", caso esse raciocínio seja justificativa o suficiente para desviar

Vejo que StepFrequency é o que o Slider usa, então acho que estávamos tentando ser consistentes com essa terminologia. Não se esqueça de que não é apenas para botões de rotação, mas também para arrastar e alterar os valores do provedor UIAutomation.

@robloo e @mdtauk , eu deveria ter lido mais no tópico antes de responder sobre °. Eu não acredito que seja suportado atualmente ter este símbolo mostrado dentro de Text já que NumberBox mantém Text e Value em sincronia para o propósito de permitir que você, como desenvolvedor, possa pegar qualquer tipo de que você precisa sem a sobrecarga de conversão. Não vi uma maneira de fazer isso por meio das propriedades de formatação disponíveis, mas se você souber de uma maneira, por favor me avise!

Estamos nos aproximando da versão V1 agora, mas para a V2 daremos uma olhada novamente em prefixo / suficiente / caracteres especiais. Nesse ínterim, acredito que a proposta de @mdtauk para o # 784 é a solução mais abrangente que foi apresentada para a plataforma até agora. Dê a essa proposta uma aprovação e um comentário se esse for um recurso de que você precisa.

@adrientetar , scroll-to-change chegou a V1, mas arrastar para alterar foi adiado para V2. Como ainda estamos tentando concluir esses recursos, ainda não discutimos sua solicitação de que Shift + Up / Down step em unidades de 10 e Ctrl + Shift + Up / Down step em unidades de 100.

Você poderia me dar mais contexto sobre os cenários em que você usaria esse recurso? Como seus usuários sabem que isso está disponível? Você pode me ajudar a entender por que isso deve ser padrão (ou pelo menos disponível) em todas as NumberBoxes em comparação com implementado localmente em sua solução?

@SavoySchuler

Muito obrigado por seus comentários.

Para ser autodocumentado entre todas as outras propriedades aqui, estamos considerando algo na linha de "SpinButtonStep", caso esse raciocínio seja justificativa o suficiente para desviar

Eu gosto muito dessa terminologia, mas não percebi que o Slider já tem a propriedade StepFrequency. Já que esse é o caso, não faz sentido se desviar da convenção como @jevansaks afirmou.

O arredondamento é feito por meio da formatação. Aqui está um exemplo de uma propriedade de arredondamento que pode ser definida para DecimalFormatter.

Digamos que o usuário insira "1/3" no NumberBox. A seguinte sequência está correta:

• Na perda de foco / entrar, a expressão será avaliada e o valor duplo de 0,33333333 ... 34 será calculado
• O 0.33333333 ... 34 será passado para o DecimalFormatter
• O 0,333333333 ... 34, dependendo de suas configurações, pode ser arredondado para "0,30" (apenas para ser difícil)
• Esse valor "0,30" será então colocado no TextBox para exibição ao usuário
• O dobro de Value agora é {0,333333333 ... 34} e o Text agora é "0,30"
• A leitura do duplo Value NÃO retornará o número arredondado que é exibido em Text
  (Ou o valor formatado decimal de alguma forma é analisado novamente após a conversão em uma string? E, em seguida, tudo é reavaliado?)

Também estou preocupado com o fato de as propriedades Value e Text serem tão intimamente acopladas internamente. A documentação não define esse acoplamento e, se não for altamente estruturado, as dependências bidirecionais nunca são divertidas.

Não tenho certeza de como isso é implementado internamente ainda, mas parece que a maneira correta de fazer isso seria tratar o valor duplo como a única propriedade real. O texto é apenas uma versão formatada de Value. Então, o desenvolvedor seria capaz de formatar o valor da maneira que quiser que ele seja exibido no TextBox e na propriedade Text (obteríamos o símbolo de grau ou os símbolos de pés / polegadas solicitados anteriormente). Isso não seria difícil de fazer se tudo já fosse conduzido internamente pela propriedade Value. A entrada textual do usuário não é mantida de qualquer maneira e só seria usada para recalcular o valor que é formatado novamente para exibição.

A sequência deve ser:

• Entrada Textual do Usuário -> Analisador -> Valor Duplo -> Formatação -> Texto

Alterar o valor Text do código seria como se o usuário inserisse algum texto. Alterar o valor diretamente apenas passaria pela etapa de Formatação e Texto.

Para manter o arredondamento preciso entre a sequência de Valor e Texto seria mais parecido com:

• Entrada textual do usuário -> Analisador -> Valor -> Arredondamento -> Valor -> Formatação -> Texto

Editar: para implementar o arredondamento no analisador de expressão / entrada e no mecanismo de avaliação (seja lá como for chamado), você provavelmente precisará adicionar uma nova propriedade para definir o algoritmo como RoundingAlgorithm . Esse enum já está definido em Windows.Globalization.NumberFormatting como você apontou. INumberFormatter2 deve ser usado para formatação e nada mais - mais uma vez, mantenha os estágios desacoplados entre o cálculo e o texto finalmente exibido.

@adrientetar , scroll-to-change chegou a V1, mas arrastar para alterar foi adiado para V2. Como ainda estamos tentando concluir esses recursos, ainda não discutimos sua solicitação de que Shift + Up / Down step em unidades de 10 e Ctrl + Shift + Up / Down step em unidades de 100.

Você poderia me dar mais contexto sobre os cenários em que você usaria esse recurso? Como seus usuários sabem que isso está disponível? Você pode me ajudar a entender por que isso deve ser padrão (ou pelo menos disponível) em todas as NumberBoxes em comparação com implementado localmente em sua solução?

Um deve ser um incremento maior e o outro deve ser menor - semelhante a cutucar áreas / objetos selecionados em aplicativos Adobe

Você poderia me dar mais contexto sobre os cenários em que você usaria esse recurso?

É ótimo quando você deseja alterar um valor com implicações visuais (por exemplo, rotação de um objeto), mas não tem certeza de até onde deseja ir. Portanto, é bom para design visual.

Como seus usuários sabem que isso está disponível?

É apenas um recurso que as ferramentas modernas têm, por exemplo, Adobe XD, Framer ...

Você pode me ajudar a entender por que isso deve ser padrão (ou pelo menos disponível) em todas as NumberBoxes em comparação com implementado localmente em sua solução?

Eu acho que é bom ter isso quando você está em um dispositivo de toque, que é uma maneira conveniente, toque e arraste, para ajustar um determinado valor (tipo como o widget seletor de hora do telefone, onde você toca e arrasta para rolar os valores).

Um deve ser um incremento maior e o outro deve ser menor - semelhante a cutucar áreas / objetos selecionados em aplicativos Adobe

RangeBase tem propriedades SmallChange e LargeChange. Nós da BeLight Software em nossa versão de NumericUpDown derivamos de RangeBase e alteramos o valor por SmallChange usando os atalhos ArrowUp e ArrowDown, e por LargeChange usando atalhos PageUp e PageDown

E não estamos sozinhos aqui,
https://help.syncfusion.com/uwp/numeric-updown/gestures
https://docs.telerik.com/devtools/wpf/controls/radnumericupdown/features/navigation

Apenas uma observação sobre o teclado numérico do teclado que me veio à mente durante a chamada da comunidade ...

Na maioria dos aplicativos, o "." o botão do teclado ainda está mapeado para "." caractere, que é diferente do separador decimal ao usar um idioma diferente do inglês (por exemplo "," em francês). Então, quando você pressiona o "." no bloco de notas, ele escreve um "." characther.

Alguns aplicativos (o Excel é o mais conhecido sobre isso) alteram o comportamento dessa tecla para reinterpretar qualquer pressionamento de tecla no teclado "." como entrada do separador decimal. É mais compatível com o design de "calculadora" do teclado.

O aplicativo Calculadora também reescreve o "." pressione para interpretá-lo como um caractere separador decimal.

Como a caixa numérica poderá funcionar mais como uma "calculadora", o controle poderá permitir o uso do "." chave no teclado como separador decimal? Ou pelo menos fornecer uma maneira para o desenvolvedor adicionar esse recurso sem ter que lutar com os principais filtros e eventos?

Talvez uma propriedade possa permitir habilitar (se optar) ou desabilitar (se optar por não) o recurso. Como KeyPadDotAsDecimalSeparator="false" ?

Proposta da caixa de número V2: https://github.com/microsoft/microsoft-ui-xaml/issues/1736

Olá maravilhosa comunidade WinUI! Agradeço sinceramente por nos ajudar a levar para casa nosso primeiro controle proposto pela comunidade para ver o lançamento. Sabemos que este foi um grande empreendimento e que todos vocês investiram uma quantidade significativa de tempo para criar a melhor coleção de recursos V1 que poderíamos projetar juntos.

Também sabemos que nem tudo chegou ao lançamento V1. Algumas configurações de validação de entrada altamente desejadas dependem do trabalho de recursos do WinUI 3.0, algumas necessidades de recursos desejadas surgiram mais tarde na validação / aplicação e alguns recursos que sabíamos que seriam melhor explorados após o lançamento V1.

Estamos tentando terminar nosso trabalho pretendido com o recurso NumberBox com uma versão WinUI 3. Abri um problema para coletar feedback sobre os recursos necessários que estão faltando na V1. Se NumberBox estiver faltando algo de que você precisa, não deixe de deixar um comentário aqui: https://github.com/microsoft/microsoft-ui-xaml/issues/1736