В качестве отправной точки у Telerik есть https://www.telerik.com/universal-windows-platform-ui/numericbox. Он также доступен с открытым исходным кодом: https://github.com/telerik/UI-For-UWP/blob/master/Controls/Input/Input.UWP/NumericBox/RadNumericBox.cs.

Что мне в них нравится, так это их подход к форматированию со свойством ValueFormat.

Пример: ValueFormat = "{} {0,0: C2}"

Также убедитесь, что он правильно локализован. Реализация Windows Community Toolkit имеет некоторые недостатки:

Расширение TextBoxRegex с ValidationType = "Decimal" поддерживает не все культуры пользовательского интерфейса. Вместо этого он закреплен на InvariantCulture. На английском языке десятичные значения - «10,1234» с точкой. На испанском или немецком языке десятичные значения записываются как «10,1234». Разбор английский будет правильным; однако пользовательский ввод на испанском или немецком языке будет просто «101234» с потерей дробной части.

См. Https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/2700

Стрелки вверх и вниз должны увеличивать или уменьшать значение на значение, которое может установить разработчик, но по умолчанию должно быть int равным 1.

• Окружающие мин / макс значения хороши, например, при выборе угла
• возможность добавлять суффикс
• щелкните текстовое поле и перетащите вверх / вниз, чтобы изменить значения, Adobe XD имеет это в числовых входах.

Моя реализация в WinRT XAML Toolkit также поддерживает перетаскивание вверх / вниз для изменения значений, что делает его более удобным при использовании с мышью, чем нажатие кнопок в определенных сценариях.
https://github.com/xyzzer/WinRTXamlToolkit/tree/master/WinRTXamlToolkit/Controls/NumericUpDown

Привет, @sonnemaf , @ArchieCoder , @robloo , @mdtauk , @adrientetar и @xyzzer! Меня назначили на это предложение.

Во-первых, спасибо, @sonnemaf , за это. Я показал его на Microsoft Build 2019 на прошлой неделе, и публика приветствовала его! Ответ сообщества здесь, в комментариях, также отражает волнение, которое мы должны видеть в NumberBox.

Я прочитал все комментарии и обновил раздел о масштабах, чтобы отразить полученный вклад. Я был бы признателен, если бы каждый мог воспользоваться возможностью проверить это небольшое обновление и сообщить мне, _не_ точно ли я зафиксировал ваши запросы , отметив, что некоторые детали (например, локализация форматирования) будут обрабатываться на уровне спецификации.

Привет @SavoySchuler!

На этой неделе я работаю над функцией специальных возможностей в своем приложении. Это было бы плюсом, если бы доступность обрабатывалась правильно с новым элементом управления, например, приращение можно было бы произносить вслух вместо «плюс», «минус». Остальное мне кажется нормальным.

Важно обеспечить, чтобы рассказчик мог правильно зачитывать значения, чтобы было понятно, что происходит.

Не уверен, потребуется ли контроллеру Xbox какое-либо касание фокуса, чтобы аналоговые джойстики и D-Pad работали правильно

Небольшое исправление - перетаскивание для увеличения / уменьшения должно работать в самом текстовом поле, пока оно не будет активировано. IIRC в моей реализации мне пришлось наложить прозрачное наложение поверх текстового поля, чтобы включить его, а также скрыть курсор мыши при перетаскивании, чтобы границы элемента управления или экрана не ограничивали расстояние перетаскивания и что когда вы закончите перетаскивание и я снова показываю курсор - он появляется там, где он сначала исчез.

@SavoySchuler, у тебя

Возможно, вы также можете добавить колесо прокрутки мыши для вверх / вниз. Blend для Visual Studio поддерживает это.

Еще мне нравится перетаскивание, которое я часто использовал в Expression Blend.

Я не уверен, что будет делать проверка ввода, а что нет. Будет ли это только min / max или также ограниченная клавиатура (буквы az и т. Д.)? Будет ли он обрабатывать вставку неверных номеров?

Я хотел бы прочитать полные спецификации.

@ArchieCoder , я слышу тебя громко и ясно. Доступность является приоритетом, и ее лучше всего решать заранее. Я открыл раздел «Доступность и входные данные» по этому предложению, в который я добавил ваше примечание.

@mdtauk , как всегда отличный вопрос. Я добавил это в раздел «Доступность и входные данные» в качестве примечания, чтобы изучить его.

@xyzzer , ты прав. При реорганизации списка областей действия я сгруппировал кнопки «Вверх» / «Вниз» и перетаскивание для изменения в качестве связанных функций. При повторном прочтении все действительно выглядело так, как будто я предлагал перетащить для изменения функцию на кнопках. Я переместил перетаскивание для изменения в отдельный раздел для большей ясности.

@sonnemaf ,

Все , с пометкой о поддержке калькулятора - верю в стоимость. Я работаю со своей командой, чтобы выяснить, следует ли нам модулировать эту функциональность на случай, если функциональность может быть усилена на платформе. Кроме того, возникает вопрос, насколько далеко мы зайдем с поддержкой калькуляторов? Подойдет ли простой порядок операций с + - / *? Или что-то более комплексное, например подключение к какой-то альфа-службе вольфрамов? Изучение модульного маршрута, возможно, позволит нам начать с более простого случая, не блокируя возможности для более полной формы поддержки калькулятора. Мне было бы интересно узнать, что здесь нужно каждому.

Что касается проверки ввода, у меня такой же вопрос. Охватывает ли это значение min, max, без букв и недопустимая вставка?

Я считаю функцию калькулятора симпатичной, но как на практике эта функция может быть обнаружена пользователем? Будет ли это небольшой намек на виджет?

@ArchieCoder , как вы думаете, выцветший пользовательский текст-заполнитель в NumberBox может соответствующим образом подсказывать пользователю? Если это так, я полагаю, что такая строка, как «a + b - c» или «введите уравнение», может быть кратким способом доставки этой информации. Excel также создал стандарт, в котором "=" появляется в начале уравнения. Возможно, когда пользователь щелкает NumberBox, перед ним появляется неизменный знак «=», который пользователь затем вводит позади?

У нас есть ToolTip или более сложная TeachingTip для руководства на уровне приложения, на которое мы могли бы попросить разработчиков положиться, но я бы предпочел решить эту проблему в самом NumberBox.

Мне интересно услышать здесь ваши мысли!

Заполнитель действительно будет хорошим способом, если другой контекст не требуется из-за ограничения места. Я бы подумал, что ширина NumberBox будет меньше, чем, например, текстовое поле.

Если элемент управления не поддерживает числа, допускающие значение NULL, он всегда будет показывать значение,
поэтому внутри него не будет места для строки-заполнителя.

Пт, 17 мая 2019 г., 10:14 ArchieCoder [email protected]
написал:

Заполнитель действительно был бы хорошим способом, если другой контекст не
требуется из-за нехватки места. Я бы подумал, что ширина NumberBox будет
быть меньше, чем, например, текстовое поле.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMAL7LUOVPIM55PYO4LPV3RWPA5CNFSM4HA4PBNKYY3PNVWWK3TREX52GJ43DFWNVWWK3TULXXXXX4DFWNVWWK3TREXXXX4DFW2
или отключить поток
https://github.com/notifications/unsubscribe-auth/AANMBMBKHP7GP5WUHLPWNZLPV3RWPANCNFSM4HA4PBNA
.

@ArchieCoder , как и примеры @sonnemaf (еще раз спасибо за них), любой NumberBox, который недостаточно широк для отображения текста-заполнителя для «a + b - c», также не будет достаточно широким, чтобы создать рекомендуемый пользовательский интерфейс для ввод уравнений в. В этом отношении я полагаю, что этот вариант решения по-прежнему жизнеспособен для этой цели. Однако я действительно думаю, что вы попадаете в область, которую мы еще не рассмотрели, - сценарии, в которых мы хотим, чтобы был введен компактный NumberBox / только простое число. Я предполагаю, что для поддержки калькулятора потребуется API для его отключения, и в этом случае нам не нужно беспокоиться о длинном тексте-заполнителе или нарушении ограничений минимального пространства, которые в противном случае потребовались бы в форме уравнения NumberBox - хотя некоторые параметры текста-заполнителя для компактного режима все же могут быть приятными , даже если это просто что-то вроде «#» или «например 2».

@xyzzer , спасибо, что подняли этот вопрос. Давайте сначала убедимся, что это даже правильный пользовательский интерфейс, а оттуда мы сможем разобраться в реализации! Пока нет необходимости ограничивать наш поиск для _ правильного_ взаимодействия с пользователем из-за технических ограничений, которые мы, возможно, сможем смягчить. : расслабленный:

У меня ко всем приоритетный вопрос:

Вы бы предпочли иметь элемент управления NumberBox, который объединяет эти функции независимо от стандартного TextBox, или вы бы предпочли, чтобы эти функции были встроены в TextBox в качестве собственных возможностей, которые можно было бы активировать через API или InputScope?

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

Помещение всего этого в элемент управления TextBox - существенное изменение.

Проверка введенных символов.

Использование правильной раскладки клавиатуры с InputScope

Различное поведение мыши.

Возможность отображения кнопок счетчика, как в версии FabricWeb.

Если бы все это можно было добавить с перечислением поведения для определения типа TextBox, не оказывая влияния на всех остальных, которые в настоящее время используют TextBox в своем приложении, тогда хорошо.

И вы даже можете подумать об объединении других поведений TextBox, таких как значок, который может представлять поиск или календарь, который действует как кнопка. Маски для таких вещей, как IP-адреса или URL-адреса, которые отображают «http: //» в стиле текста-заполнителя, когда вы вводите текст рядом с ним.

FabricWeb имеет большое разнообразие текстовых полей.

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

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

Я бы определенно пошел с собственным элементом управления NumberBox вместо того, чтобы запекать все эти функции в элементе управления TextBox (аналогично тому, как есть элемент управления PasswordBox, а не TextBox с «паролем» режима ввода).

Элемент управления NumberBox будет намного больше, чем, например, простое поле ввода для IP-адресов. Он будет иметь свои собственные возможности доступа / уникальные функции прокрутки и перетаскивания, поддержку калькулятора ... все, что будет отличать его от того, как я обычно использовал TextBox до сих пор (случаи столь же просты, как указание имени представления для группы данных). И поскольку для элемента управления NumberBox будет предложено еще больше специальных функций / требований, мы можем сохранить четкое и четкое разделение между NumberBox и TextBox.

Это выражение также будет отражено в документации и в xaml-макете приложения (NumberBox легче обнаружить, чем, скажем, TextBox с множеством свойств, одно из которых определяет режим ввода). Вместо того, чтобы читать документацию TextBox о возможностях числового ввода, эта часть была бы удобна и аккуратна в документации по конкретному элементу NumberBox (точно так же, как сегодня с PasswordBox).

Что касается внешнего вида элемента управления, я думаю, что единица / суффикс могут отображаться в стороне с меньшим размером / ненасыщенным цветом, чтобы он отличался от самого значения:

При наведении курсора мыши на элемент управления стрелки вверх / вниз могут исчезать вместо единицы:

Альтернативой являются элементы управления числами с figma.com, когда вы наводите курсор на единицу, вы можете щелкнуть + перетащить влево / вправо, чтобы изменить значение.

Влево / вправо интересно тем, что перемещать мышь влево / вправо легче, чем вверх / вниз (запястье поднимать не нужно).

Другие вещи:

• При нажатии на несфокусированную текстовую область он должен выделить все содержимое. так что щелкните + введите значение + введите, чтобы изменить значение
• Shift + щелчок по стрелке или Shift + Up / Down при увеличении или уменьшении фокусировки на 10 (я думаю, это значение тоже должно быть настраиваемым).
• Я не думаю, что стрелки вверх / вниз очень полезны для пользователя. Если пользователю нужно точное значение, он просто вводит его, если он не уверен, какое значение он хочет, они могут визуализировать спектр изменений значений, щелкнув + перетащив. Так что стрелки вверх / вниз, вероятно, должны быть как минимум необязательными.

@adrientetar, помещающий указание устройства в элемент управления, создает множество дополнительных проблем:

• локализация
• доступность
• выбор
• оклейка
• конверсии

Всего этого можно было бы избежать, поместив это в заголовок, описание или отдельный текстовый блок.

Я бы выбрал отдельный элемент управления NumberBox со свойством Value и, возможно, не с свойством Text. Значение должно быть двойным, чтобы мы могли привязать его к данным (x: Bind). Я не уверен, следует ли нам также поддерживать тип данных Decimal и как это сделать.

Я думаю, что поддержка обнуляемых чисел ОБЯЗАТЕЛЬНА (спасибо @xyzzer). Свойство Value должно иметь значение Nullable.тип данных. Я не уверен, что это вызовет проблемы с привязкой при привязке к значению, не допускающему значения NULL.

В то время как композиция имеет преимущества и имеет привязанное поведение для пронумерованных
режим можно было бы реализовать и прикрепить к TextBox - я думаю, это сделало бы
это излишне сложно и ограничено.
Некоторые из самых больших проблем, с которыми вы, вероятно, столкнетесь при реализации, связаны с
доступность. Я считаю, что поддерживает некоторые шаблоны доступности -
вам нужно будет запекать реализацию определенных интерфейсов в TextBox
это сбивало бы с толку, если бы TextBox не находился в режиме числового поля.

В понедельник, 20 мая 2019 г., в 2:33 Fons Sonnemans [email protected]
написал:

Я думаю, что поддержка обнуляемых чисел ОБЯЗАТЕЛЬНА (спасибо @xyzzer
https://github.com/xyzzer ). Свойство Value должно иметь значение Nullable.
тип данных. Я не уверен, что это вызовет проблемы с привязкой при привязке к
значение, не допускающее значения NULL.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMBGVIQ36CDPQO6CWKLPWJV55A5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVYHVVA#issuecomment-493910740 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AANMBMBTHT2UXOAGRTEDF7LPWJV55ANCNFSM4HA4PBNA
.

У меня ко всем еще один вопрос. Вам нужна / предпочитаете проверку ввода или маскировку?

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

Проверка важна, так как вы не можете добавить число в строку. А математические операторы необходимо оценивать и обрабатывать.

Нужно ли отображать сообщение об ошибке, если он не может вычислить, в чем я не слишком уверен.

Было бы полезно использовать маскирование, но оно, вероятно, должно быть встроено в само текстовое поле, чтобы можно было обрабатывать ввод URL-адреса и электронной почты. NumberBox - это номера телефонов, IP-адреса и т. Д.

Я не думаю, что NumberBox следует использовать для телефонных номеров или IP-адресов. Они больше похожи на простые расширения маскировки / фильтрации для TextBox. NumberBox - это то, что вы хотите использовать для ввода одного значения.
Возможно, есть потенциал для управления валютным ящиком, но я также чувствую, что это должен быть отдельный элемент управления, отличный от TB или NB.

@xyzzer Мне кажется хорошей идеей сделать NumberBox более гибким для любого вида числового ввода. Он может быть производным от элемента управления TextBox, и этот элемент управления может иметь свойство Mask, а также другие поведенческие свойства.

Вот некоторые из этих свойств NumberBox:

• Показать / скрыть кнопки счетчика
• Разрешить увеличение и уменьшение значений
• Разрешить расчет значений
• Разрешить маскированный ввод
• Локализованные маски, такие как номера телефонов или IP-адреса

Свойства, которые можно добавить в TextBox, могут быть:

• Свойство маски - строка XAML для определения настраиваемого формата ([email protected]), а также локализованных масок, таких как почтовые индексы / почтовые индексы.
• Отображение префикса / суффикса (например, _http: // _ в качестве префикса)
• Показать / скрыть кнопку действия - со значком и свойством события щелчка
• Значок (в поле поиска пользовательского интерфейса Fabric отображается его значок слева, и он отключается, когда поле фокусируется)

Эти изображения представляют собой текстовое поле пользовательского интерфейса Fabric - и оно поддерживает все эти различные состояния - мы должны стремиться привести элементы управления Fluent WinUI 3.0 к паритету, где это возможно.

Кнопки Fabric UI Spinner слишком малы для прикосновения, поэтому я бы отформатировал их по-другому, чтобы кнопки вверх и вниз располагались рядом, а не накладывались друг на друга.

Для меня проверка - это НЕОБХОДИМО, а маскирование - ПРИЯТНО ИМЕТЬ. Я никогда не любил маскироваться; это слишком жестко.

@rudyhuyn предложил в репозитории Windows Calculator приятную возможность. @mdtauk прокомментировал это.

Вы можете открыть всплывающее окно калькулятора из NumberBox, аналогичное средству выбора даты / времени / календаря.

Подобно тому, что сказал выше @xyzzer . Существует фундаментальная разница между числом и строкой, содержащей последовательность цифр.
Лучше всего я слышал об описанной разнице в том, что вы можете выполнять операции умножения и деления над числами. Вы можете попросить половину числа и разделить его на два. Вы не можете попросить половину почтового индекса или «номер телефона» и получить что-то значимое.

Смешивание определенного NumberBox , имеющего математические возможности, с функцией захвата других значений, состоящих из цифр, также может привести к другим проблемам.
«Телефонные номера» могут начинаться с ведущих нулей (или знака «плюс»), и там они имеют значение. Для _number_ они этого не делают и будут раздеты.
«телефонные номера» также часто форматируются скобками и дефисами. При обработке как математических операциях они могут легко интерпретироваться как требующие умножения и вычитания.

Разрешение маскирования так же, как TextBox и как способ форматирования ввода, рискует запутать разницу между NumberBox и TextBox и тем, когда следует использовать каждый из них.

Простая проверка является обязательной , но нужно быть осторожным, чтобы, когда проверка приходит на платформу , это не приводит к появлению конфликтующих методов проверки или чему-то, что может легко подтолкнуть разработчиков к распространению своей проверки на несколько мест. .

Я бы продолжил валидацию только на основе этих свойств:

• Максимальное значение
• MinimumValue
• AllowDecimalPlaces

Отдельно должно быть указание на

• неверный результат расчетов
• как обрабатывать введенное / вставленное / вычисленное значение и что используется в привязке. Необходимо отобразить вычисление или недопустимое значение, чтобы показать, что оно недопустимо, но это нельзя передать ни в какое свойство поддержки,

Маскам потребуется визуальная возможность, чтобы прояснить, что требуется, тогда как базовые входные данные для расчетов не будут использоваться вместе с маскированными входными данными.

Текстовые элементы управления Fabric Web, похоже, прекрасно справляются с этим, но, конечно, область действия NumberBox отделена от общих улучшений подгонки и завершения для элемента управления TextBox по умолчанию.

Кнопки счетчика (и, возможно, дополнительное всплывающее окно Калькулятора) - единственные визуальные элементы, которые кажутся характерными для NumberBox.

Что касается свойств, возможно, если для изменения значения включены кнопки вверх и вниз на клавиатуре - можно включить значение Step, чтобы вы могли выбрать, на сколько увеличивать или уменьшать при нажатии клавиши.

@mdtauk , мне нравится значение Step , но не только при нажатии клавиши. Также на кнопке прокрутки и вверх / вниз.

@sonnemaf Конечно, Step хорош для чего-то двоичного, например,

Так что StepMinimum и StepMaximum возможно?

Так что StepMinimum и StepMaximum возможно?

Я понятия не имею, к чему могут относиться эти ценности и чего от них ожидать.
Если целью «Шага» является определение приращений, назовите его «Приращение».

Это позволит Max:100 Min:0 Increment:10 указывать только значения 0, 10, 20, 30, 40, 50, 60, 70, 80, 90 и 100.

Изменение величины шага / приращения в зависимости от расстояния перетаскивания может привести к непредсказуемым изменениям значений. Если цель этого элемента управления состоит в том, чтобы упростить определение числовых значений, то, если значение начинает меняться в разной степени, я, вероятно, сочту это очень разочаровывающим, что приведет к нарушению основной цели наличия специального элемента управления, чтобы упростить его.

@mrlacey Я использую Step, поскольку это свойство, названное для ползунка и индикаторов выполнения, но при желании можно использовать приращение. Значение увеличивается и уменьшается до тех пор, пока приращение не путается только с увеличением значения.

Есть предложение щелкнуть и перетащить вверх или вниз, чтобы увеличить или уменьшить значение. Если пользователь ожидает, что значение изменится быстрее, чем дальше вы перетаскиваете вверх или вниз, то наличие минимального и максимального значения Stap позволит разработчику контролировать это при изменении дельты. Таким образом, небольшое расстояние перетаскивания может изменяться с шагом 0,1 или 1, но дальнейшее перетаскивание может изменяться, например, с шагом 5 или 10 .

Я не говорю, что расстояние перетаскивания должно изменять скорость изменения значения - просто это идея, которая может быть полезна, если она кажется естественной и дает пользователю чувство уверенности и контроля.

Замечательный отзыв, всем! Я открыл спецификацию и PR, чтобы начать обдумывать детали.

@KevinTXY присоединится ко мне в качестве разработчика этого

Пожалуйста, не стесняйтесь присоединиться ко мне в написании спецификации.

Спецификация TeachingTip - это полнофункциональный пример того, как будет выглядеть законченная спецификация. Основным планом будет:

• Описание
• Примеры для каждого API / функции
• Руководящие указания
• API (IDL)

Отличные идеи, мне нравится, в каком направлении все это происходит. Добавляем мои два цента:

• Без сомнения, я думаю, что это должен быть отдельный NumberBox, а не интегрированный с TextBox. Кроме того, здесь обсуждается множество хороших функций, но мы также должны сделать NumberBox легким. Поэтому я предлагаю создать CalculatorBox или что-то подобное от NumberBox, которое может иметь расширенные входы «2 + 3» или кнопку для открытия калькулятора.
• Локализация должна быть заранее продумана в спецификации. Кроме того, есть случаи, когда вы хотите переопределить локальный пользовательский интерфейс. Поэтому установка свойства NumberformatInfo или CultureInfo может быть очень полезной. Например, в некоторых приложениях отслеживаются как иностранное, так и местное значение. Каждый потенциально может иметь другой формат.
• Элемент управления должен поддерживать перемещение десятичного знака. Это сложнее, чем просто проверять формат для каждого измененного текста. Необходимо отслеживать ввод каждого символа и при необходимости заменять предыдущий десятичный разряд.
• Любые стрелки увеличения / уменьшения должны быть сконфигурированы так, чтобы они были отключены, чтобы иметь простое поле ввода - снова нам нужен легкий элемент управления для тех случаев, когда он необходим как часть других элементов управления.
• Что-то еще, что не обсуждалось, - это то, что нам необходимо в идеале поддерживать несколько типов - Decimal, Integer и, возможно, Long, Double и т.д ... Это может фундаментально изменить многие вещи, и я сам еще не полностью продумал это .
• Это значение обязательно должно допускать значение NULL. Неустановленное значение отличается от нуля.
• Другая идея, которая не является критической, - это возможность указывать десятичную точность для типов decimal, double или float.

Я уверен, что последуют и другие идеи. Я с нетерпением жду возможности прочитать спецификацию!

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

У меня есть спецификация / PR, заполненная API и примерами для каждого. Я думаю, что я обратился к форматированию в соответствии с вашими спецификациями с помощью перечисления для основных предопределенных типов (все еще в разработке), а также настраиваемого свойства форматирования, которое переопределит предопределенные типы, если оно установлено.

Пожалуйста, проверьте его и дайте мне знать, если он не решит ваши проблемы, или его можно дополнить или улучшить. Я буду принимать запросы на вытягивание, которые соответствуют спецификациям, запрошенным здесь.

• Валидация отмечена как необходимость. Я назначил этот элемент управления производным от TextBox, чтобы бесплатно получить маскировку и другие вспомогательные свойства.

• К озабоченности @mrlacey я добавил API для включения / отключения удаления

• Это в сочетании с возможностью включения / отключения поддержки калькулятора, на мой взгляд, обеспечивает пересечение элемента управления, который может быть как легким для числовых значений / строк, так и предлагать достаточную поддержку вычислений и настройки. Я считаю, что краткость примеров подчеркивает это, но мне интересно услышать мнение любого, кто думает, что это сделает предполагаемый контроль более громоздким в использовании.

• @sonnemaf Я ценю новизну и интуитивность примера с иконкой> всплывающим калькулятором. На мой взгляд, это проистекает из концепции CalendarDatePicker и может быть отличным решением для функции V2, если не будет сильного толчка со стороны всех здесь, чтобы ее следовало рассмотреть для V1?

Всплывающий калькулятор может иметь смысл, если есть согласование с проектом Calculator с открытым исходным кодом. Как для единообразия внешнего вида всплывающего окна калькулятора, так и для движка, стоящего за ним.

Не уверен, что это место для публикации этого изображения, но вот дизайны для различных штатов, соответствующие спецификациям.

Изображение в масштабе 200%

@mdtauk для чего

Какое состояние пытается показать каждое изображение? Без вашего пояснения мы можем делать предположения, отличные от ваших.

Предполагается ли, что это идеальные ссылки на пиксель?

Можете ли вы указать, где что-то в ваших изображениях отличается от значения по умолчанию для платформы или базового элемента управления, чтобы было понятно, что (если что-то) вы добавляете или изменяете.

@mrlacey Я мог бы сделать более полную разбивку, если бы это было полезно? Я просто пытался проиллюстрировать некоторые примеры, приведенные в спецификации.

Их цель - попытаться проиллюстрировать, как эти элементы управления могут выглядеть с различными предлагаемыми элементами управления, такими как префикс, суффикс, маски, кнопки вверх и вниз. Они экстраполированы из дизайнов элементов управления FabricWeb, но с использованием элементов XAML, таких как FocusReveal, и управления размером кнопок.

В примерах показано состояние покоя - Фокус - Отключено.

Всплывающий калькулятор был бы хорошей функцией для V2.

Я не уверен, куда девать свои замечания. Должен ли я делать PR по спецификации или я могу продолжать писать свои мысли в этом выпуске?

Целое число

Было бы полезно использовать целочисленное значение NumberBoxFormatType?

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

Язык

Вы бы использовали язык для указания валюты, символов группировки десятичных цифр?

В следующем примере язык установлен на nl-NL. Означает ли это, что префикс - это знак евро, десятичный символ - это запятая с двумя десятичными знаками после нее, а группировка цифр - точка? Отрицательная валюта имеет знак минус впереди и без скобок, как в США.

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

Этого достаточно, потому что в Windows есть много вариантов формата чисел и валюты.

Значение свойства или свойства

Нужно ли нам свойство Value и какой (числовой) тип это будет. Я бы использовал его для привязки к данным. Это должно быть двойное, десятичное или целое число. Нужна ли нам поддержка Nullable (double?, Decimal?, Int?). Я не хочу использовать свойство Text унаследованного элемента управления TextBox для привязки данных. Нам также нужна поддержка Decimal, double недостаточно.

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

Что делать, если свойство Salary сотрудника не может быть обнулено(десятичный?). Нужно ли нам свойство зависимостей ValueNullableDecimal. SelectedDate элемента управления DatePicker имеет значение Nullable.. Обнуление - это проблема, особенно с привязкой данных.

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

То же самое с MinValue и MaxValue. Теперь они являются целыми числами в спецификации, но разве это не должно быть двойным ?.

@sonnemaf, потому что в спецификации говорится, что элемент управления предназначен для всего, где можно вводить цифры, я думаю, это должно означать, что он обрабатывает «Значение» как текст и полагается на код потребления для преобразования по мере необходимости. Это не идеально, но даже если бы свойство Value было длинным или плавающим, все равно было бы много случаев, когда потребовались бы преобразования.
Это лучше, чем перегрузки для каждого числового типа.
Затем есть вещи, для которых разрабатывается элемент управления, которые не могут быть преобразованы в «числовой» тип, такие как почтовый индекс США, номер телефона или IP-адрес. Для такого рода значений получение текста кажется лучшим (единственным) вариантом.
Я думаю, что это проще (по крайней мере, в начальной версии иметь один способ доступа к введенному значению и полагаться на преобразователи, где это необходимо. Я вижу место для набора помощников (или подклассов), которые сначала входят в набор инструментов, а затем некоторые из они включаются в основной контроль на основе обратной связи.

Требуется ли свойство Language ? Почему это не то же самое, что и UILocale? Могут быть веские причины, но похоже, что это должно быть настраиваемым пользователем (на уровне ОС), и предоставление возможности указать конкретный формат может привести к дополнительным проблемам для разработчиков, когда формат не соответствует где-либо еще или что пользователь приложение хочет. Вне моей головы: что, если кто-то вставит значение в другом формате?

@mdtauk для чего

Какое состояние пытается показать каждое изображение? Без вашего пояснения мы можем делать предположения, отличные от ваших.

Предполагается ли, что это идеальные ссылки на пиксель?

Можете ли вы указать, где что-то в ваших изображениях отличается от значения по умолчанию для платформы или базового элемента управления, чтобы было понятно, что (если что-то) вы добавляете или изменяете.

@mrlacey Это то, чего вы хотели?

@mdtauk это немного лучше, поскольку он объясняет кое-что из того, что вы пытаетесь показать.

Тем не менее, основной вопрос все еще остается: какова ваша цель, чтобы показать это? Это просто идея? Это ваша предпочтительная версия после изучения различных идей? Если да, то почему они самые лучшие / предпочтительные?

Сравнение текущих элементов управления с тем, как вы хотите, чтобы новые элементы управления отображались в ваших предпочтительных новых общесистемных стилях, означает, что невозможно отделить то, что характерно для элемента управления, от того, что находится в ваших предпочтительных новых общесистемных стилях.

Например, вы упомянули об изменении прозрачности границы. Это изменение касается всех элементов управления или только этого? И в каких штатах?

Предоставление явных размеров (для кнопок) может быть проблематичным в дизайнерских композициях, поскольку они не всегда переводятся в равные размеры в зависимости от изменения размера их контейнера. Всегда ли они должны быть квадратными? или их ширина фиксирована на основе высоты элемента управления по умолчанию?

Как вы предлагаете кисть фона для префиксов и суффиксов определяется? Я предполагаю, что это уже существующая системная кисть, но какая?

В этой спецификации маскировка не рассматривается. Ваши «замаскированные» примеры предназначены для связи со строками форматирования?
Как ваш пример в маске соответствует формату?
Я предполагаю, что ваш пример показывает запись IP-адреса версии 4, но там, похоже, много предположений, основанных на том, насколько аккуратно все кажется подходящим. Должны ли все не вводимые значения иметь фон и поля? Что, если они не всегда отображаются? Следует ли растянуть контент, чтобы уместить все доступное пространство, как в вашем примере? Как будет обрабатываться пространство, выделенное для не вводимых значений, при панорамировании содержимого, которое шире доступного пространства?

@mdtauk это немного лучше, поскольку он объясняет кое-что из того, что вы пытаетесь показать.

Тем не менее, основной вопрос все еще остается: какова ваша цель, чтобы показать это? Это просто идея? Это ваша предпочтительная версия после изучения различных идей? Если да, то почему они самые лучшие / предпочтительные?

Сравнение текущих элементов управления с тем, как вы хотите, чтобы новые элементы управления отображались в ваших предпочтительных новых общесистемных стилях, означает, что невозможно отделить то, что характерно для элемента управления, от того, что находится в ваших предпочтительных новых общесистемных стилях.

Например, вы упомянули об изменении прозрачности границы. Это изменение касается всех элементов управления или только этого? И в каких штатах?

Спецификация NumberBox не включала никаких наглядных примеров, а изображения в исходном предложении являются приблизительными примерами функциональности. Существует еще один PR # 524, в котором шаблоны элементов управления обновляются значениями CornerRadius в 2epx, что также является тем же округлением, что и в Fabric Web.

Таким образом, предполагая, что элементы управления, производные TextBox, также будут обновлены аналогичным образом, я использовал это в качестве руководства, чтобы показать, как предлагаемая функциональность NumberBox может вписаться в это. Текстовые поля Fabric Web уже поддерживают значения префикса и суффикса, поэтому я просто взял этот дизайн и использовал метрики XAML.

Предоставление явных размеров (для кнопок) может быть проблематичным в дизайнерских композициях, поскольку они не всегда переводятся в равные размеры в зависимости от изменения размера их контейнера. Всегда ли они должны быть квадратными? или их ширина фиксирована на основе высоты элемента управления по умолчанию?

Текущее поле TextBox имеет несколько встроенных кнопок, таких как SearchBox, кнопка восстановления пароля и кнопка очистки текста. Touch Targets для XAML предлагает кнопки размером 32 x 32 epx - я просто оставил их квадратными и использовал это руководство.

Как вы предлагаете кисть фона для префиксов и суффиксов определяется? Я предполагаю, что это уже существующая системная кисть, но какая?

В моем примере я использовал цвет переднего плана темы, но с непрозрачностью 15%. Кнопки FabricWeb используют около 10%, а кнопки XAML используют 20%.
Существуют аналогичные значения кисти, такие как ListLowBrush, но может потребоваться новая кисть TextBoxAppendixBackground. Текстовый передний план будет использовать ту же кисть PlaceholderTextForeground.

В этой спецификации маскировка не рассматривается. Ваши «замаскированные» примеры предназначены для связи со строками форматирования?
Как ваш пример в маске соответствует формату?
Я предполагаю, что ваш пример показывает запись IP-адреса версии 4, но там, похоже, много предположений, основанных на том, насколько аккуратно все кажется подходящим. Должны ли все не вводимые значения иметь фон и поля? Что, если они не всегда отображаются? Следует ли растянуть контент, чтобы уместить все доступное пространство, как в вашем примере? Как будет обрабатываться пространство, выделенное для не вводимых значений, при панорамировании содержимого, которое шире доступного пространства?

Я не буду притворяться, что у меня есть все ответы на этот вопрос, и то, как это будет заметно отображаться на элементе управления, будет зависеть от того, как форматирование маски реализовано в элементах управления.

Я использовал адрес IP v4, поскольку это пример, представленный в спецификации, и моим первоначальным намерением было проиллюстрировать то, что предлагалось (хотя примеры префикса и суффикса отсутствовали, поэтому я выбрал другие значения)

Я посмотрел, как другие элементы управления обрабатывают маскировку, а некоторые используют встроенный текст, который перемещает курсор при вводе значений. Другие будут вводить такие вещи, как скобки и дефисы при вводе номера телефона. Некоторые используют табуляцию или клавиши со стрелками для перемещения между сегментами. Самый близкий пример от Microsoft, который приходит на ум, - это ввод ключей продукта во время установки Windows.

Я думал, что использование того же стиля, что и добавляемые элементы, будет соответствовать эстетике, но я знаю, что это увеличивает длину элемента управления, чтобы уместить все это, а встроенные элементы могут лучше использовать пространство.

Просто примечание, поскольку я сейчас работаю с TextBox, с ним нет единого события, которое сигнализировало бы об изменении значения пользователем (т.е. объединении потерянного фокуса и нажатой клавиши возврата), аналогично https://doc.qt.io /qt-5/qlineedit.html#textEdited было бы здорово иметь это в NumberBox, поскольку оно предназначено для такого рода правок. Кстати, если он будет обрабатывать всевозможные значения, такие как IP-адреса, возможно, поле «Число» слишком узкое для имени? Это может ValueBox или около того

@adrientetar NumberBox кажется прекрасным именем, потому что все входные данные считаются числами. IP-адрес состоит из 4 цифр, телефонных номеров, валюты, размеров и т. Д.

DigitBox, NumeralBox и т. Д. - все варианты, которые не совсем соответствуют стилю именования Microsoft.

Значения также не обязательно должны быть числовыми по своей природе, поэтому ValueBox также может вводить в заблуждение.

@sonnemaf и @mdtauk , я говорил со своей командой об идее встроенного калькулятора, и, короче говоря, нам это нравится - без преувеличения. Мы безмерно рады тому, как вы уже повысили качество и креативность предоставляемых нами средств управления.

Мне понадобится твоя помощь, чтобы это произошло. То, как мы остаемся в курсе множества замечательных идей, которые появляются в нашем репо, - это не только руководствоваться идеями, но и сценариями. (Я разделяю это, потому что использование этого языка придаст вашим запросам функций конкретное влияние на протяжении всего нашего репо.)

Может ли кто-нибудь из вас предоставить мне реальные сценарии для встроенного калькулятора в любом из разрабатываемых вами приложений? Контекст, скриншоты, профили пользователей - все это помогает. (Моя электронная почта также находится в моем профиле GitHub, если вы предпочитаете сохранять конфиденциальность.) @Xyzzer , @mrlacey , @robloo , @ Felix-Dev, @adrientetar и @ArchieCoder , пожалуйста, поделитесь своим сценарием использования, если эта функция Вас также интересует.

Помимо этого шага, единственное, что может затруднить работу этой функции, - это риск завышения размера DLL WinUI с помощью механизма калькулятора. Я изучу это параллельно, чтобы оценить осуществимость.

Ранее я

Существует фундаментальная разница между числом и строкой, содержащей последовательность цифр.

Это было до того, как был опубликован первый черновик спецификации, поэтому я предполагаю, что это было учтено и было принято решение, чтобы этот элемент управления обрабатывал как «традиционные числовые значения», так и «строки, содержащие числовые цифры».

Я не думаю, что кто-то действительно будет пытаться утверждать, что IPv4-адрес был «числом» по какому-либо другому определению, кроме как обычно представляемого в виде отформатированной последовательности цифр. На самом деле это всего лишь 4-байтовое значение.

@SavoySchuler

• Возможно, ввод расходов - ввод этих статей из квитанции, где одни предметы являются личными, а другие - частью работы.
• Приложение для ресторана при разделении счета или, может быть, расчет чаевых?
• Приложение для редактирования Hex, чтобы вычислить значение смещения для перемещения выделения?

Наличие элемента управления, поддерживающего IP-адреса, было бы отличным дополнением к платформе, но я не думаю, что NumberBox - правильный элемент управления для этого сценария.

Как упоминалось ранее, элемент управления NumberBox:

• использовать виртуальную клавиатуру Number при использовании на устройстве без физической клавиатуры
• есть 2 кнопки - / +
• отображать всплывающее окно с калькулятором или позволять пользователю вводить основные арифметические операции

Ни одна из этих функций не имеет смысла с IP-адресом. Даже дизайн управления сильно отличается.

Более того, мы должны помнить, что если мы поддерживаем адреса IPv4, мы также должны поддерживать адреса IPv6, используя не цифры, а шестнадцатеричные числа.

Я думаю, что было бы разумнее не включать поддержку IP-адресов в этот элемент управления, а вместо этого работать над новым элементом управления MaskedTextBox для UWP (поддерживающим IPv4, IPv6, номер телефона, почтовый индекс, SSN и т. Д.) с богатым пользовательским интерфейсом (как продемонстрировано @mdtauk) для замены / улучшения TextBoxMask из набора инструментов сообщества (https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask)

Наличие элемента управления, поддерживающего IP-адреса, было бы отличным дополнением к платформе, но я не думаю, что NumberBox - правильный элемент управления для этого сценария.

Как упоминалось ранее, элемент управления NumberBox:

• использовать виртуальную клавиатуру Number при использовании на устройстве без физической клавиатуры
• есть 2 кнопки - / +
• отображать всплывающее окно с калькулятором или позволять пользователю вводить основные арифметические операции

Ни одна из этих функций не имеет смысла с IP-адресом. Даже дизайн управления сильно отличается.

Более того, мы должны помнить, что если мы поддерживаем адреса IPv4, мы также должны поддерживать адреса IPv6, используя не цифры, а шестнадцатеричные числа.

думаю, было бы разумнее не включать поддержку IP-адресов в этот элемент управления, а вместо этого работать над новым элементом управления MaskedTextBox для UWP (поддерживающим IPv4, IPv6, номер телефона, почтовый индекс, SSN и т. д.) с богатый пользовательский интерфейс (как продемонстрировано @mdtauk) и замена / улучшение TextBoxMask из набора инструментов сообщества (https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask)

@rudyhuyn Я в основном согласен с тем, что вы только что сказали, и мои иллюстрации были для предложенной спецификации.

Но, как уже упоминалось другими, текстовое поле с маской не обязательно должно ограничиваться только цифрами и может также включать строки. Поле Microsoft Product Key - хороший пример, в котором можно использовать 5 наборов символов от 0 до 9 AZ.

Даже если маскирование было отделено, я все же думаю, что есть хорошие варианты использования для включения свойств PrefixText и SuffixText в элемент управления NumberBox. Валюта, измерения - все это требует определенного контекста.

Кнопки вращения предназначены исключительно для увеличения и уменьшения значений, поэтому они также входят в область действия элемента управления NumberBox.

Префикс и суффикс могут стать свойствами самого элемента управления TextBox и, таким образом, унаследованы другими элементами управления. (Может потребоваться исключение для PasswordBox, если он открывает какие-либо уязвимости)

Маски для общих значений могут быть перечислением (вместе с CustomFormatMask) для этого отдельного элемента управления. Некоторые из этих масок могут включать контекст культуры, например, почтовый индекс Великобритании, являющийся буквенно-цифровым, и номера национального страхования Великобритании после специального форматирования и т. Д.

SW1A 2AA

Пример почтового индекса Великобритании (для № 10 Даунинг-стрит)

Похоже, мне не удалось обновить страницу сегодня утром перед тем, как отправить ответ ... Спасибо всем, рок-звезды, что подняли это предложение на совершенно новый уровень! Я знаю, что этими словами злоупотребляют на GitHub, но я серьезно!

@mdtauk - ваши свяжусь с @mrlacey здесь. Я прочитаю вашу ветку и отвечу более подробно в ближайшее время.

@sonnemaf , еще раз спасибо! Я бы посоветовал вам скопировать свой комментарий и опубликовать его здесь, на вкладке беседы Pull Request . Здесь наша команда инженеров начнет работу на уровне API и реализации. Чтобы дать исчерпывающий ответ, именно здесь я начинаю составлять руководящие принципы и документацию. Я буду предисловием коммитов с [DEV] для первого и [PM] для последнего. В противном случае это подходящий форум для обсуждения требований высокого уровня (таких как встроенный калькулятор и макеты @mdtauk ).

@mdtauk : Я согласен с вами, префикс / суффикс был бы хорошим дополнением к TextBox и не ограничивался числами, например:

• попросите сотрудника ввести свой адрес электронной почты, если домен всегда один и тот же (например, @ microsoft.com).
• введите имя формы, если она всегда начинается с W-

так далее...

Вам следует открыть еще один тикет, чтобы мы могли начать его обсуждение!

@rudyhuyn , видите ли вы возможность не поддерживать что-то вроде IP-адреса, но возможность поддерживать телефонный номер или почтовый индекс как работоспособную?
Я считаю, что если вы начинаете ограничивать одни вещи, а другие - нет, правила того, что покрывается, должны быть очень четко определены.
Простая поддержка значений, которые могут отображаться как целые числа, числа с плавающей запятой и т. Д., Делает вещи очень понятными и по-прежнему создает элемент управления, обеспечивающий большую ценность.

@SavoySchuler Мои проекты полностью в вашем распоряжении, я разместил их, чтобы попытаться визуализировать контроль для всех, кто вносит свой вклад.

@rudyhuyn Если бы вы опубликовали предложение для MaskedTextBox или FormattedTextBox, это могло бы иметь больший вес! Как и в случае с NumberBox, я рад, что любой из моих проектов будет включен в такое предложение, и могу сделать больше примеров, если вам потребуется.

@mrlacey Телефонные номера (за исключением символов форматирования) являются чистыми числами, но они не подпадают ни под какой вариант использования вычислений, поэтому лучше ли он подходит для текстового поля с маской, или есть смысл в предоставлении поддержки для них в NumberBox?

При создании элемента управления и документации важно предоставить четкий вариант использования и примеры того, какой элемент управления использовать в каком контексте.

@mrlacey : Я не знаю.

Как вы сказали ранее, мы должны разделять действительные числа, не только используя символы 0-9, но и связанные с арифметическим значением.

IP-адрес, номер телефона, SSN, почтовый индекс используют символы от 0 до 9, но не имеют арифметических значений (вы можете добавить 2 из них, если вы добавите «.00» в конец, вы измените значение значения и т. Д.) . В этих случаях значение представляет собой строку, а не int / double, более логичным будет MaskedTextBox.

Кроме того, в почтовом индексе используются только цифры в США, но не в Канаде, например, адрес IPv6 может содержать символы AF, номер телефона может содержать знак + (555-123-4567 и + 555-123-4567 - это два разных номера телефонов) и т. д.

Подводя итог моему мнению, NumberBox.Value должно быть двойным, а не строкой.

@mrlacey Телефонные номера (за исключением символов форматирования) являются чистыми числами, но они не подпадают ни под какой вариант использования вычислений, поэтому лучше ли он подходит для текстового поля с маской, или есть смысл в предоставлении поддержки для них в NumberBox?

Телефонные номера могут состоять полностью из цифр (плюс форматирование), но это не делает их числами. Вы не можете проделать с ними какие-либо арифметические операции и получить что-то значимое.
Также некоторые могут начинаться со знака плюс.
Также имеет значение количество ведущих нулей в телефонном номере. Для числового значения это не так.
Другие функции элемента управления, такие как вычисления или кнопки вверх и вниз, не имеют никакого смысла для «телефонного номера».

Этот элемент управления должен быть ограничен значениями, которые можно преобразовать в int / uint или десятичное без риска потери информации.

Чтобы убедиться, что я правильно синтезирую эту обратную связь, дайте мне большой палец вверх по этому комментарию, если вы считаете, что это лучшее место для ввода всех типов числовых строк (таких как номера телефонов и IPv4) с помощью типов форматов и большого пальца. вниз, если эту функцию следует передать другому или новому элементу управления, чтобы NumberBox фокусировался исключительно на математических и математических вычислениях. (Отмечая, что функции, поддерживающие математические операции, такие как режим калькулятора и кнопки вверх / вниз, требуют включения через соответствующие API.)

Я не могу гарантировать, что это будет принято демократическим путем, поскольку я приму решение, которое приведет к наилучшей окупаемости инвестиций для наших клиентов во всем мире, - но это поможет подтвердить то, что, как я думаю, я здесь вижу: никто не просит об этом для поддержки числовых значений. строки и предпочел бы для этого специальный элемент управления.

@SavoySchuler Числа, с которыми можно работать, увеличивать и уменьшать, а также префиксы и суффиксы, которые добавляют контекст и значение к значению.

Я просто синхронизировался с командой здесь и хотел поделиться обновлениями по некоторым из наших открытых вопросов:

• Мы прислушиваемся к вашим отзывам и согласны с тем, что NumberBox - не лучшее место для числовых строк. Свойства FormatKinds и CustomFormat были заменены более конкретными API-интерфейсами для управления форматом чисел более интуитивно понятными способами.
• Префикс и суффикс действительно принадлежат TextBox (от которого NumberBox унаследует их). Я дам @mdtauk , @mrlacey или кому-либо еще несколько дней
• Последний канал в NumberBox (после вычисления, округления и т. Д.) Будет сохранен как String в свойстве Text, которое выходит из TextBox И как Double в новом свойстве Value. Мы намерены получать обратную связь друг с другом, чтобы изменение одного отразилось на другом. Это делается для того, чтобы избавить вас от максимально возможного объема работы и подготовить ценность, которую можно будет использовать по мере необходимости.
• StepSize отсутствовал как свойство в спецификации.
• Целочисленные типы будут изменены на Double.
• Мы все еще восхищаемся идеей встроенного калькулятора и ищем другие сценарии, которые помогут нам это усовершенствовать. @mdtauk , спасибо, что уже ответили на этот отзыв!
• Что касается проверки ввода, идея состоит в том, чтобы сначала отправить событие типа ValueChanged, которое даст разработчику возможность манипулировать вводом или обрабатывать его при отправке конечной / блочной формы по мере необходимости. Если никаких корректирующих действий не предпринято (например, принуждение к минимальному / максимальному значению, удаление недопустимых символов и т. Д.), NumberBox вместо этого будет отображать для пользователя индикацию ошибки об их вводе. Этот двойной подход дает разработчикам возможность ответить, если они того пожелают, но также позволяет отложить исправление на усмотрение пользователя.

Было огромное количество отзывов, на которые я до сих пор отвечаю. Спасибо за терпение, я отвечу всем здесь, а также в репозитории спецификаций!

«Концепт-арт NumberBox со встроенным калькулятором». Сообщество WinUI, май 2019 г. (раскрашено)

(Комплимент от @ryandemopoulos )

@SavoySchuler Вы попросили привести несколько примеров сценариев, в которых можно было бы использовать обсуждаемые нами элементы управления. В моем приложении есть два, которые могут быть хорошими примерами.

Случай 1. Существует редактор настроек для 2D-графиков, в котором вы можете настроить ось.

• Для этого просто нужен простой числовой ввод. Здесь были бы полезны кнопки увеличения +/-.
• Двойное значение было бы хорошо, но вводимые данные необходимо подтверждать при нажатии символа. Пользователь никогда не должен даже иметь возможность нажимать «а», чтобы она отображалась в поле ввода. Проверка ввода не должна делать границу красной и предупреждать пользователя - просто не должно быть возможности ввести недопустимое значение.
• Локализация должна поддерживаться элементом управления, а перемещение десятичного разряда (будь то запятая, точка и т. Д.) Обрабатываться как особый случай (я продолжаю поднимать этот вопрос, потому что его легко пропустить)

Случай 2: есть поле ввода для значения валюты, как показано ниже. Это настраиваемый элемент управления CurrencyBox.

• Для этого можно использовать кнопку калькулятора, и возможность вводить уравнения 2 + 3 будет иметь здесь некоторую ценность (хотя я все же считаю, что это должен быть отдельный элемент управления)
• Двойное значение НЕ подходит для этого. Я бы предложил изменить спецификацию Value с двойного на десятичный, чтобы поддерживать этот тип использования . В противном случае разработчик должен проанализировать текст строки.
• Здесь есть особый случай, когда отрицательный знак обрабатывается отдельно. Это позволяет пользователю не ошибиться при подписи. На самом деле я не ожидаю, что NumberBox будет поддерживать это из коробки.
• Выравнивание текста важно установить, и префикс / суффикс были бы чрезвычайно полезны для отображения символа валюты (локализация по-прежнему потенциально может быть проблемой, зная, отображать ли символ справа или слева; однако само приложение может иметь эту логику)
• Пользователь может ввести как иностранное, так и местное значение. NumberFormatInfo и CultureInfo для обоих этих значений МОЖЕТ отличаться от культуры пользовательского интерфейса. Следовательно, для локализации элемент управления должен поддерживать переопределение на настраиваемый NumberFormatInfo.

Прямо сейчас в приложении для обоих случаев используется Windows Community Toolkit с прикрепленными свойствами к TextBox, как показано ниже:
TextBoxRegex.ValidationMode = "Динамический"
TextBoxRegex.ValidationType = "Десятичный"

Несколько заключительных комментариев (извините, это так долго!)

• Я думаю, что мы обсуждаем здесь потенциально 3 различных элемента управления. NumberBox в виде штриховых костей, CalculatorBox, который может иметь уравнения и расширенный числовой ввод (кнопка калькулятора!), И, наконец, MaskedTextBox для нечислового ввода, такого как номера телефонов и IP-адреса. Мы не должны путать их, и согласование того, как разделить эти концепции, является ключом к продвижению вперед со спецификацией.
• Мы не можем упустить из виду самый простой и, пожалуй, самый полезный вариант использования: нормальное текстовое поле, в котором нет ничего, кроме фильтрации ввода, поэтому можно ввести только действительное число. Все остальные параметры должны быть отключены (я думаю о кнопках увеличения +/-)
• Я по-прежнему предлагаю перейти с двойного на десятичное в спецификации, чтобы точно зафиксировать десятичную точность в проанализированном значении. Кроме того, мы, вероятно, должны рассматривать ввод целых чисел, отличных от ввода рациональных чисел. Вероятно, это новое свойство в API «IsInteger = true», которое нужно изменить с десятичного значения по умолчанию.

Изменить: удалена идея переключения с двойного на десятичный для типа NumberBox.Value. Я ошибался, предполагая, что это существует в мире C ++ WinRT. Это не так, и вместо этого находится только в .net core / framework.

@robloo , насчет последнего комментария, в WinRT нет типа Decimal.

Отладчик Visual Tree в XAML Toolkit - это инструмент, который в значительной степени полагается на элемент управления NumericUpDown этого инструментария, где увеличение / уменьшение с помощью перетаскивания мышью, кнопок и клавиатуры очень важны. Ввод с калькулятора также может помочь:

@robloo и @xyzzer , это именно та информация, которую я ищу!

Проверка / маскирование

@robloo , меня особенно интересует случай 1: пуля 2 - проверка против маскирования. Давайте поговорим о сценарии «плохого ввода» на данный момент:

• Новый пользователь вводит "два" в вашем NumberBox.
• NumberBox вызывает событие «ValueChanged», которое дает вам возможность вернуть нечисловой ввод в «0» - или иначе - по вашему выбору. Если не предпринять никаких действий, то ...
• В NumberBox запускается проверка, и отображается сообщение об ошибке для пользователя, информирующее его о том, что разрешен только числовой ввод (эта часть еще не была полностью рационализирована, так что это всего лишь гипотеза).

Дает ли эта серия мероприятий вам возможность создать необходимый опыт?

Я понимаю, что маскирование может быть желательным по умолчанию, но позвольте мне поделиться тем, что моя команда обсуждала на прошлой неделе - мы пришли к выводу, что проверка (индикатор / сообщение об ошибке) предпочтительнее в элементах управления Fluent, поскольку альтернатива, маскирование, может расстраивать и вводить в заблуждение конечных пользователей, когда они не получают вывода от ввода с клавиатуры. Другой способ подумать об этом заключается в том, что проверка предлагает уровень прозрачности и информации для пользователя, который делает их более осведомленными об опыте, в отличие от молчаливого принуждения. Таким образом, наш текущий курс действий заключался в том, чтобы встроить базовую проверку, не блокируя возможность для разработчика добавить расширенную проверку (скоро в TextBox) или маскировку через событие ValueChanged по мере необходимости. Насколько мы понимаем, это достаточно гибкий подход, позволяющий удовлетворить все потребности, обеспечивая при этом рекомендуемые возможности по умолчанию.

Что ты здесь думаешь? Мне были бы интересны любые ваши идеи для дальнейшего включения этих концепций или создания еще лучшего опыта, если мы сможем.

Форматирование значений

К другим вашим пунктам, @robloo , я добавил свойство точности DecimalPrecision в Spec . Установка этого значения = "0" приведет к получению целых чисел. Кроме того, установка MinValue = "0" может помочь сохранить неотрицательные числа (или событие ValueChanged - еще одна возможность для приведения входных данных к абсолютным значениям).

Вы уже просмотрели Спек ? Я считаю, что включил все свойства, необходимые для полноценного использования вашего опыта (в ожидании обсуждения проверки и маскирования), но мне не терпится узнать, думаете ли вы, что я что-то упустил.

маскирование, может расстраивать и сбивать с толку конечных пользователей, когда они не видят вывода при вводе с клавиатуры.

100% согласен да. Лучше всего выполнить проверку на LosingFocus / EnterPressed и восстановить oldValue, если введенное значение не проверяется, поэтому идеально было бы иметь сигнал, который запускается на LosingFocus / EnterPressed и содержит oldValue / newValue.

@adrientetar , отличный момент! Это опыт, который вам нужно создать? Если да, я посмотрю, что нам нужно сделать, чтобы событие ValueChanged отправило как старое, так и новое значение.

@SavoySchuler Это то, что я действительно хочу сделать в своем приложении, я бы сам построил такое поведение, если элемент управления не делает это по умолчанию.

Еще мне бы хотелось Shift + ↑ / ↓ для приращения 10 и Ctrl + Shift + ↑ / ↓ для приращения 100, хотя я считаю, что приращение 100 не всегда имеет смысл.

Отличный момент! Мы должны убедиться, что элемент управления является производным от RangeBase, который
определяет как SmallChange, так и LargeChange, и мы используем их оба в
по крайней мере.
Есть ли пример стандартных комбинаций клавиш для вызова
большое изменение в RangeBase UWP или WinForms / ComCtl (?) NumericUpDown?

В пн, 3 июня 2019 г., в 15:50 Адриен Тетар [email protected]
написал:

@SavoySchuler https://github.com/SavoySchuler Это то, что я хочу
действительно в моем приложении, я бы сам построил это поведение, если элемент управления не
это по умолчанию.

Еще мне бы хотелось Shift + ↑ / ↓ для приращения 10 и
Ctrl + Shift + ↑ / ↓ для приращения 100, хотя я считаю, что приращение 100
не всегда имеет смысл иметь.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMFZBHJIE4DR2KN46TTPYWN3BA5CNFSM4HA4PBNKYY3PNVWWK3TULXWORLV4DFV4DXWM8BWG4DFW4DXWMW4DXWM8WWB4DVB03DWMW2
или отключить поток
https://github.com/notifications/unsubscribe-auth/AANMBMG4AWBK44VE4O4GYR3PYWN3BANCNFSM4HA4PBNA
.

Я проверю, чтобы проверить, но я вполне уверен, что сочетания клавиш придется оставить приложениям для реализации. Я попробовал это с обоснованием доступности для # 21, и введение новых сочетаний клавиш - рискованная игра, поскольку почти все из них, на которые не претендовала Windows, теперь используются на уровне приложений (при этом TeachingTip смог перейти на победитель F6), но я проверю, допускает ли фокус управления какие-либо исключения здесь!

В сборке 2018 было объявлено о состоянии проверки для элементов управления TextBox с использованием INotifyDataErrorInfo.
Это было бы хорошо использовать с маскированием для проверки или аннулирования текущей текстовой строки.

РЕДАКТИРОВАТЬ: использование значка и более толстого цвета нижней границы помогает распознавать в ситуациях с дальтонизмом и при просмотре в черно-белом режиме. Нижний текст ошибки может быть выполнен в виде всплывающей подсказки на значке, если пространство ограничено.

@mdtauk, вы феноменальны в этих

@SavoySchuler Простая экстраполяция на основе примера, показанного на Build 2018

И есть на что посмотреть :)

Извините, это еще один длинный!

@SavoySchuler @adrientetar Я определенно понимаю, откуда вы исходите из приведенных ниже заявлений. Я не буду спорить, что в подавляющем большинстве случаев это лучший способ справиться с проверкой. Тем не менее, я должен думать, что есть некоторые особые случаи, когда это настолько очевидный числовой ввод, что вы на самом деле оказываете пользователю услугу, не позволяя ему вводить жирным пальцем неправильный символ.

маскирование, может расстраивать и сбивать с толку конечных пользователей, когда они не видят вывода при вводе с клавиатуры.

100% согласен да. Лучше всего выполнить проверку на LosingFocus / EnterPressed и восстановить oldValue, если введенное значение не проверяется, поэтому идеально было бы иметь сигнал, который запускается на LosingFocus / EnterPressed и содержит oldValue / newValue.

Тем не менее, я решил порыться в других приложениях, чтобы посмотреть, как с этим справляются. Я не думаю, что кто-то проводит больше исследований взаимодействия с пользователем, чем Microsoft, поэтому для справки я использовал 64-разрядную версию Word для настольных ПК, а затем версию OneNote для UWP. Это более или менее полностью совпадает с тем, что вы, ребята, говорите. Я могу ввести любой текст в поля ввода размера шрифта или размера формы, которые явно являются только числовым вводом. Он в основном проверяет потерю фокуса и возвращается к последнему действительному вводу.

| Название | Pic | Комментарий |
| ------ | ----- | ------------ |
| Запись размера шрифта UWP OneNote | | С клавиатуры можно ввести любое значение, оно автоматически проверяется и сбрасывается до последнего действительного значения при потере фокуса |
| Запись о размере шрифта рабочего стола Word | | С клавиатуры можно ввести любое значение, оно автоматически проверяется при потере фокуса, и если оно недействительно, появляется сообщение об ошибке. При нажатии [OK] сбрасывается до последнего действительного значения. |
| 2D-график UWP OneNote | | С клавиатуры можно ввести любое значение. Недействительные значения будут просто игнорироваться, и последний действительный ввод будет использоваться в вычислениях (не проверяется при потере фокуса). Нажатие кнопок инкремента +/- будет увеличивать с использованием последнего действительного ввода. |
| Запись размера формы слова рабочего стола | | С клавиатуры можно ввести любое значение, оно автоматически проверяется при потере фокуса и сбрасывается до последнего действительного значения при потере фокуса. |

Так что, полагаю, я просто оказался неправ, а это значит, что я должен согласиться с вами!

Боковые комментарии:

• Как ранее упоминалось кем-то другим, когда NumberBox имеет фокус клавиатуры с сенсорной / виртуальной клавиатурой, должна отображаться только цифровая клавиатура.
• Приращение вниз слева и увеличение справа - интересная идея для обсуждения здесь с точки зрения стиля. Мне это нравится!
  

• Новый пользователь вводит "два" в вашем NumberBox.
• NumberBox вызывает событие «ValueChanged», которое дает вам возможность вернуть нечисловой ввод в «0» - или иначе - по вашему выбору. Если не предпринять никаких действий, то ...
• В NumberBox запускается проверка, и отображается сообщение об ошибке для пользователя, информирующее его о том, что разрешен только числовой ввод (эта часть еще не была полностью рационализирована, так что это всего лишь гипотеза).
  Дает ли эта серия мероприятий вам возможность создать необходимый опыт?
  Что ты здесь думаешь? Мне были бы интересны любые ваши идеи для дальнейшего включения этих концепций или создания еще лучшего опыта, если мы сможем.

Я полностью понимаю и согласен с тем, что добавление проверки ввода отлично подходит для всей платформы. Однако вы, по сути, только что описали проверку ввода без специальной обработки числа. Следовательно, какая польза от NumberBox, кроме автоматического анализа значения? Как разработчику кажется, что TextBox с проверкой данных более или менее одинаков.

Я думаю, что на основе приведенных выше примеров функциональность «из коробки» должна сочетать обе наши идеи и то, что говорит @adrientetar . Пользователь может ввести любое значение, чтобы получить визуальную обратную связь. Однако при потере фокуса значение автоматически проверяется, и автоматически возвращается предыдущее допустимое число (или пустое). Это избавляет разработчика от необходимости самостоятельно выполнять проверку ввода (мы уже знаем, что это должно быть число в NumberBox). Он также четко отличается от текстового поля с проверкой данных.

Что касается событий, я все же хотел бы иметь возможность отменить изменения текста, если этот вариант использования станет более понятным. Поэтому в дополнение к ValueChanged я бы рекомендовал события ValueChanging и TextChanging, чтобы можно было сравнивать и отменять ввод. Определенно OldValue и NewValue необходимы независимо, это, по крайней мере, позволило бы нам быстро изменить его обратно на OldValue, если это необходимо (хотя UWP любит аварийно завершать работу, когда вы изменяете TextValue в событии).

Что касается спецификации: хорошие идеи с DecimalPrecision, мне нужно больше времени, чтобы пройти через это и добавить свои комментарии. Есть много мелких нюансов, например, значение по умолчанию должно быть String = Empty, Value = Null, а при нажатии кнопки увеличения +/- значение должно рассматриваться как ноль, а не как пустое.

@mdtauk По-человечески не должно быть возможности так быстро делать такие хорошие иллюстрации :)

@robloo Спасибо за добрый комментарий. У меня есть только небольшой комментарий относительно вашего +/−
Возможно, будет лучше придерживаться символов «Вверх» и «Вниз», используемых в текущих кнопках прокрутки, чтобы избежать путаницы с математическими операциями, которые может выполнять этот NumberBox.

iOS использует «шаговый» элемент управления, но ввод текста отдельный, и нет встроенных вычислений.

Вот еще несколько дизайнов, которые я нашел

Дизайн, который я выбрал, кажется, соответствует типичному стилю Microsoft для этого элемента управления, но это лучший выбор или правильный выбор. Мне было бы интересно услышать, что об этом думают другие.

РЕДАКТИРОВАТЬ: добавлены макеты альтернативных форм (но я думаю, что первая идея лучше ...)

Я согласен с @mdtauk относительно расположения +/-, первое - лучшее.

Существует XAML ControlTemplate, поэтому пользователь (разработчик) всегда может создать собственный шаблон для двух других макетов.

@robloo , вам не нужно извиняться за подробные ответы - особенно когда они содержат несколько хороших смешков! Отличная идея с сенсорной / виртуальной клавиатурой - я добавил ее в раздел « Открытые вопросы » в спецификации для запуска разработчиками / командой и убедился, что при этом нет недопустимых накладных расходов на производительность. Я думаю, что для пользователей было бы прекрасным удобством, если бы мы смогли это осуществить.

Вы поднимаете важный вопрос о валидации ...

[1] Вопрос: кто-нибудь будет против системы проверки, которая автоматически возвращает неприемлемый ввод к предыдущему значению, при этом обнаруживая события, которые позволили бы разработчику отменить это поведение и вместо этого решить, что делать / выдавать индикаторы ошибок или сообщения?

Визуально я вижу достоинства непересекающихся кнопок UpDownButtons в опубликованном вами примере. Я считаю, что @mdtauk и @sonnemaf находятся на правильном пути по умолчанию. Близость кнопок UpDownButtons является их истинным удобством, независимо от того, проверяете ли вы обратный и обратный результат различных (но не удаленных) вводов или исправляете выход за пределы шага. Расстояние, за исключением случаев, когда это заслуживает улучшенного дизайна или функциональности, может добавить к опыту работы, которой можно избежать, а также может поставить под угрозу ясность с помощью свойств / маркировки префикса / суффикса, в отличие от группировки этого отдельно в качестве функциональной части элемента управления, например: $ [-] 192 [+]

Я считаю, что есть сценарии для непересекающихся UpDownButtons. Я думаю о задачах, требующих минимального и однонаправленного ввода, или о задачах, в которых разработчик старается сделать ошибки ввода более сложными. Я считаю, что именно такой опыт дают некоторые приложения и веб-сайты, когда, например, вы покупаете билеты в кино или на концерт.

Тогда мой вопрос ...

[2] Вопрос: следует ли нам полагаться на Xaml ControlTemplate для создания NumberBox с непересекающимися UpDownButtons (т. Е. Это не достаточно распространено, чтобы оправдать поддержку из коробки), или мы должны включить свойство для установки того, будут ли UpDownButtons отображаться смежными против непересекающихся?

Я отвечу на этот вопрос

Я должен включить соображения доступности для разговора UpDownButtons: близость UpDownButtons друг к другу обеспечивает концептуальную ясность для пользователей экранного диктора / программы чтения с экрана, а также поддерживает эффективность навигации для пользователей, использующих навигацию с помощью клавиатуры, и также важно не идти на компромисс.

Если элемент управления не очень широкий, вам нужно, чтобы стрелки располагались вертикально (я знаю, что мне это нужно в моем приложении). Может быть, можно сделать управление чувствительным к установленной ширине? Это зависит от руководящих принципов беглого дизайна, чтобы указать это таким образом, если они думают, что это имеет смысл.

Я добавил в предложение 3 открытых вопроса.

Спасибо @mdtauk за концептуальные проекты!

@adrientetar Я рад, что вы указали на это как на необходимость. Похоже, нам нужно перечисление для этих трех конфигураций?

Если элемент управления не очень широкий, вам нужно, чтобы стрелки располагались вертикально (я знаю, что мне это нужно в моем приложении). Может быть, можно сделать управление чувствительным к установленной ширине? Это зависит от руководящих принципов беглого дизайна, чтобы указать это таким образом, если они думают, что это имеет смысл.

Было предложение о том, чтобы позволить элементам управления знать и реагировать на объем доступного им пространства # 677 Это можно было использовать для изменения положения кнопок вращения по мере сужения элемента управления. Может быть, должно быть свойство для NarrowWidth, аналогичное MinWidth, или, может быть, даже NumberOfDigits, чтобы действовать как подсказка?

Что касается примера серого текста - я беспокоюсь, что это может побудить пользователя ввести значения, которые появляются, а не действовать как намек на то, каким будет окончательный результат. Это похоже на PlaceholderText.

Как насчет использования AccentColor и другого веса шрифта, чтобы выделить его?

Отличная ссылка, @mdtauk. Я полагаю, что если мы идем по этой дороге, мы могли бы справиться с этим с помощью перечисления, которое имеет такие значения, как [Auto, Vertical, Horizontal, Detached], где Auto будет предпочитать Horizontal, пока компактность не будет требовать Vertical. Мысли?

Также обновил изображение! Я думаю, что вы правы, текст, выделенный серым цветом, может выглядеть как подсказка, если следовать ей, это приведет к ошибке из-за знака «=».

Отличная ссылка, @mdtauk. Я полагаю, что если мы идем по этой дороге, мы могли бы справиться с этим с помощью перечисления, которое имеет такие значения, как [Auto, Vertical, Horizontal, Detached], где Auto будет предпочитать Horizontal, пока компактность не будет требовать Vertical. Мысли?

Первоначальная мысль заключается в том, будет ли когда-нибудь число в контейнере достаточно большим там, где потребуется вертикальная ориентация? AutoCompleteBox не перемещает кнопку поиска, а строки обычно длиннее чисел.

Если это что-то, что связано исключительно с доступным пространством, автоматическое реагирующее поведение (если бы это предложение было одобрено) было бы лучше, чем перечисление. Предоставление разработчикам опции в самом элементе управления может привести к менее последовательному использованию элемента управления, но я думаю, что это должно быть то, на что, как мне кажется, должны будут обратить внимание пользовательские исследования, а не предписано нами только на github.

У разработчиков всегда есть возможность изменить шаблон элемента управления, если им действительно_ нужен другой макет для элемента управления, и можно включить для этого альтернативный стиль , если вы хотите: вертикальный стиль и шаблоны - и B) убедитесь, что оба стиля протестированы должным образом

@mdtauk Я согласен, что лучше всего использовать символы вверх / вниз. Я просто хотел показать пример со стрелками на противоположных сторонах ввода. Как упоминалось ранее, это помогает гарантировать, что пользователь не нажмет не ту кнопку, что почти обязательно в сенсорном интерфейсе пользователя. В примере, который я привел из OneNote, были символы +/-, но мне следовало добавить, чтобы игнорировать сами символы.

@SavoySchuler

[2] Вопрос: следует ли нам полагаться на Xaml ControlTemplate для создания NumberBox с непересекающимися UpDownButtons (т. Е. Это не достаточно распространено, чтобы оправдать поддержку из коробки), или мы должны включить свойство для установки того, будут ли UpDownButtons отображаться смежными против непересекающихся?

Я знаю, что когда UWP был впервые создан, сначала он был сенсорным, поэтому разрозненные кнопки UpDownButtons, возможно, были бы лучше. С тех пор требования Touch-First были ослаблены, и наверняка кнопки рядом друг с другом лучше, когда у пользователя есть точный метод ввода, такой как мышь (меньшее расстояние перемещения). Поскольку это зависит от варианта использования, я согласен с тем, что перечисление полезно для указания того, как должны отображаться UpDownButtons.

Для значений перечисления мы обсудили несколько состояний и, обобщая, мы можем добавить еще несколько:

• SeparatedHorizontal: стрелка вниз слева, стрелка вверх справа
• SeparatedVertical: стрелка вниз внизу, стрелка вверх вверху
• Слева: стрелки вверх и вниз рядом друг с другом слева (в горизонтальной ориентации).
• Справа: стрелки вверх и вниз рядом друг с другом справа (в горизонтальной ориентации).
• Вверху: стрелки вверх и вниз рядом друг с другом вверху (в вертикальной ориентации).
• Внизу: стрелки вверх и вниз рядом друг с другом внизу (в вертикальной ориентации).

Если все это станет слишком сложным (а это произойдет быстро), я буду рад повторно шаблонизировать элемент управления для моих собственных вариантов использования в XAML.

Просто выскажу еще одну идею: изменение ориентации символа для несвязанных кнопок UpDownButton также может иметь некоторый смысл [<] 123 [>]. Не стесняйтесь игнорировать эту дополнительную сложность, поскольку она, безусловно, может быть изменена для каждого приложения.

Кроме того, некоторые проблемы доступности уже могли быть решены в OneNote, откуда я взял пример.

@robloo Я думаю, что левое и правое размещение, которое вы упомянули, следует оставить для локализации RtL и LtR, а не для скрытых настроек.

Ниже мои мнения

Я также не уверен, что размещение кнопок над текстовым полем имеет семантический смысл, не говоря уже о том, что когда вы кладете палец на кнопку, может быть трудно увидеть изменение числа.

Наличие каждой комбинации, встроенной в элемент управления, приведет к хаотическому использованию, и все это можно сделать с помощью повторного шаблона, если возникнет острая необходимость.

Кнопки под текстовым полем могут иметь некоторое применение в ограниченном пространстве, а также в качестве опции на самом элементе управления, поскольку они делают кнопки намного больше, чтобы нажимать на них. Будь то стиль, связанный с элементом управления, или перечисление между:

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

Просто быстрый вопрос, возможное предложение: теоретически в числовом поле можно вводить только числа в числовое поле. Насколько сложно будет разобрать записанные числа и преобразовать их в действительные числа для этих полей?

Например:
один + два = 3
переводит
1 + 2 = 3

Или
один плюс два равно трем
переводится на
1 + 2 = 3

Это просто идея.

Просто быстрый вопрос, возможное предложение: теоретически в числовом поле можно вводить только числа в числовое поле. Насколько сложно будет разобрать записанные числа и преобразовать их в действительные числа для этих полей?

Например:
один + два = 3
переводит
1 + 2 = 3

Или
один плюс два равно трем
переводится на
1 + 2 = 3

Это просто идея.

Это имеет смысл для английского языка. Это становится проблемой, когда вам нужно перевести и проанализировать эти строки для других языков. А как насчет польского пользователя, набирающего английские слова?

На данный момент обсуждалась только форма цифр 0-9, десятичные дроби, разделители чисел и математические операторы. Но могут потребоваться и другие системы счисления.

Добавление языковых переводов потребует больших усилий, и неясно, в чем будет заключаться выгода.

Теперь, если бы этим элементом управления можно было управлять с помощью аудиовхода, то есть произнесение числа или операции - это может потребовать интерпретации языка, на котором говорят.

РАССКАЗЧИК:
«Pixels NumberBox без значения»

ПОЛЬЗОВАТЕЛЬ:
«Сто двадцать восемь пикселей»

[128 _________ | px]

ПОЛЬЗОВАТЕЛЬ:
«Добавить шестьдесят четыре пикселя»

[192 _________ | px]

РАССКАЗЧИК:
«Сто девяносто два пикселя»

[1] Вопрос: кто-нибудь будет против системы проверки, которая автоматически возвращает неприемлемый ввод к предыдущему значению, при этом обнаруживая события, которые позволили бы разработчику отменить это поведение и вместо этого решить, что делать / выдавать индикаторы ошибок или сообщения?

Если введенный текст становится недействительным, почему значение должно быть изменено на что-то более старое? Я не думаю, что попытка поддерживать «последний полезный Value » - это то, за что должен нести ответственность орган управления. Позвольте элементу управления обрабатывать одно текущее значение (или состояние ошибки), а приложение позаботится о любой дополнительной исторической обработке по мере необходимости с помощью события ValueChanged .

Для начальной версии, я думаю, будет хорошо, если будет просто поддерживать одно положение кнопок «Вверх» / «Вниз», поскольку при необходимости их можно изменить.
Если возможность определять положение кнопок вверх / вниз считается необходимостью, то любое добавляемое перечисление должно устранить необходимость иметь свойство UpDownButtonsEnabled и значение перечисления Hidden может быть добавлен взамен.
Также обратите внимание, что наличие встроенной поддержки для управления положением кнопок «Вверх» / «Вниз» добавит сложности любому, кому нужно настроить шаблоны для чего-либо, кроме предоставленной опции.

@shaheedmalik , а идея отличная и интуитивно понятная. Вы проверили спецификацию? У нас есть событие ValueChanged, которое позволит вам перехватить этот ввод и вручную преобразовать набранные числа в числовые значения - так что это можно было бы создать, особенно если вы имеете в виду конкретный язык. Что касается запекания глобального синтаксического анализатора языка в V1 элемента управления по умолчанию - @mdtauk прав, это добавит сложности и накладных расходов, которые потребуют значительного обоснования. Преимущество использования этих элементов управления с открытым исходным кодом состоит в том, что они могут быть разветвлены сообществом. В этом случае вы или другие члены сообщества можете создать языковые варианты этого элемента управления. Я считаю, что это был бы наиболее реалистичный путь к демократизации версии NumberBox с синтаксическим анализом языка.

@mrlacey, так и у вас есть шанс на обзор @robloo «s сравнительный анализ NumberBox аналогичный контроль используется по

| Название | Pic | Комментарий |
| ------ | ----- | ------------ |
| Запись размера шрифта UWP OneNote | | С клавиатуры можно ввести любое значение, оно автоматически проверяется и сбрасывается до последнего действительного значения при потере фокуса |
| Запись о размере шрифта рабочего стола Word | | С клавиатуры можно ввести любое значение, оно автоматически проверяется при потере фокуса, и если оно недействительно, появляется сообщение об ошибке. При нажатии [OK] сбрасывается до последнего действительного значения. |
| 2D-график UWP OneNote | | С клавиатуры можно ввести любое значение. Недействительные значения будут просто игнорироваться, и последний действительный ввод будет использоваться в вычислениях (не проверяется при потере фокуса). Нажатие кнопок инкремента +/- будет увеличивать с использованием последнего действительного ввода. |
| Запись размера формы слова рабочего стола | | С клавиатуры можно ввести любое значение, оно автоматически проверяется при потере фокуса и сбрасывается до последнего действительного значения при потере фокуса. |

@mdtauk , отмечая ваш комментарий к языкам LTR и RTL и стороне элемента управления, на которой появляются кнопки UpDownButtons. Я проведу его с экспертами по локализации, чтобы убедиться, что это необходимо учитывать.

@mrlacey, вы также правы, что логическое значение будет избыточным для перечисления. Я постараюсь в ближайшее время проверить, нужны ли какие-либо альтернативные конфигурации.

@adrientetar , вы наш основной покупатель вертикальных кнопок. У вас есть фрагменты экрана или контекст, которые могут помочь мне лучше понять ваше ограниченное пространство? @mdtauk заставил меня задуматься с этим ответом ранее:

Первоначальная мысль заключается в том, будет ли когда-нибудь число в контейнере достаточно большим там, где потребуется вертикальная ориентация? AutoCompleteBox не перемещает кнопку поиска, а строки обычно длиннее чисел.

@SavoySchuler (относительно возврата к последнему хорошему значению) Поскольку спецификация добавит больше возможностей NumberBox для обработки ошибок и отчетности, чем элементы управления в обзоре @robloo , я

Учти это:

1. NumberBox с AllowsCalculations=True
2. вручную введите 1100 и перейдите к следующему элементу управления
3. понять, что это не то, что хотел войти
4. вернитесь к элементу управления и введите "99 x 12"
5. перейдите к следующему элементу управления, и значение вернется к отображению «1100» («x» не то же самое, что «*», поэтому он не будет выполнен на этапе вычисления. Или рассмотрите любой другой недопустимый расчет, который не выполняется, если «x» не будет » t отображается при нажатии.)
6. Теперь оно показывает значение, которое не является результатом расчета, сообщение об ошибке не отображается, а введенная сумма теряется, поэтому нет записи о том, что произошло.

То, что я хотел бы сделать, когда переход к следующему элементу управления на шаге 5 будет

• «99 x 12» остается значением Text
• Отображается состояние ошибки.
• ValueChanged событие инициировано и передано (Text = '99 x 12 ', OldValue = 1100, NewValue = Double.NaN)
• Затем пользователь может увидеть, что что-то не так
• Пользователь может исправить проблему без повторного ввода всей суммы.
• Логика кода / приложения может сделать что-то подходящее, если это необходимо.

Если вы собираетесь автоматически вернуться к последнему известному значению при входе:

• Когда, кроме случая, когда в обязательное поле не вводится значение, будет отображаться состояние ошибки?
• Разве не уменьшилась ценность события ValueChanged поскольку оно никогда не сообщит о недопустимом состоянии?

@SavoySchuler @mrlacey Рассматривая эти примеры в других приложениях Microsoft ...

Любые модальные всплывающие окна должны быть исключены. Вместо этого это должно обрабатываться состоянием проверки самого элемента управления.

ИЗОБРАЖЕНИЕ

Если существует недопустимое значение Value, возможно, содержимое должно оставаться в этом недопустимом состоянии, но только пока элемент управления находится в фокусе. Если фокус потерян, значение текстового поля возвращается, но в уведомлении о проверке отображается, что ввел пользователь?

InputScope: Number или FormulaNumber?

Как упоминалось ранее (в PR-комментарии), FormulaNumber не включает «пробел», который включают все примеры вычислений здесь и в спецификации. FormulaNumber также включает математические символы, которые не поддерживаются этим элементом управления.

Я голосую за номер

Число

FormulaNumber

@SavoySchuler Я имею в виду, что я просто делаю настольное приложение (не пытаюсь сделать свою собственную версию Excel или что-то еще). Думаю, я просто отключу стрелки, думаю, хватит перетаскивания мышью. Если планируется перетаскивание мышью, возможно, изменение значения должно запускаться при каждом изменении, потому что пользователь хочет предварительно просмотреть диапазон возможных изменений в этом случае. Боковая панель:

Между прочим, содержимое TextBox не будет центрироваться по вертикали, и это с VerticalContentAlignment = "Center".

Он похож на боковую панель свойств, которую использует Paint 3D (которая также использует собственный стиль управления с более тонкими светлыми границами и то, что выглядит как свойство суффикса).

Если перетаскивание не будет реализовано, вы всегда можете сделать то же самое, что и Paint 3D, и привязать ползунок к NumberBox.

Это также похоже на то, что делает Adobe, имея на своем элементе управления раскрывающийся ползунок.

@adrientetar Вы, кажется, делаете там свою собственную версию NumberBox. Текст в вашем TextBox будет иметь выравнивание по базовой линии, так как у шрифтов будет нижний элемент, который необходимо учитывать.

Для NumberBox может быть случай наличия визуально центрированных символов, но тогда эти NumberBox не будут выравниваться при размещении рядом со стандартным TextBox или производным элементом управления TextBox, таким как ComboBoxes.

При создании шаблонов и стилей по умолчанию вы должны учитывать различные свойства Windows.UI.Xaml.Documents.Typography ...

• Типография.
• Typography.NumeralAlignment + Typography.NumeralStyle (Tabular может быть предпочтительнее пропорционального)

@mrlacey , у вас есть веский аргумент. Судя по ответу @adrientetar , как насчет следующего сценария:

События изменения значения / текста запускаются при _каждом_ изменении (для случаев, когда пользователи перетаскивания / прокрутки являются диапазоном тестирования), и, следовательно, проверка может происходить непрерывно, когда сообщение об ошибке и индикатор отображаются до тех пор, пока не будет нажата кнопка «Enter» / фокус будет потерян, в В этом случае переопределение значения проверки срабатывает и перезаписывает последнее хорошее значение (если это поведение не отключено соответствующим свойством).

Я побеседую с командой сегодня днем, чтобы проверить, является ли это постоянное срабатывание / проверка события реалистичной идеей - в противном случае мы можем построить диапазон, ограничивающий другой способ.

@mdtauk , но я считаю, что вы правы в своих утверждениях о визуальном представлении валидации. @LucasHaines , ты можешь меня дважды проверить?

@jevansaks , можете ли вы взвесить приведенное ниже соображение InputScope?

Как упоминалось ранее (в PR-комментарии), FormulaNumber не включает «пробел», который включают все примеры вычислений здесь и в спецификации. FormulaNumber также включает математические символы, которые не поддерживаются этим элементом управления.

Я голосую за номер

Число

FormulaNumber

@SavoySchuler об этом

События изменения значения / текста запускаются при каждом изменении (для случаев, когда пользователи перетаскивания / прокрутки находятся в диапазоне тестирования), и, следовательно, проверка может происходить непрерывно, когда сообщение об ошибке и индикатор отображаются до тех пор, пока не будет нажата кнопка «Enter» / фокус будет потерян, в В этом случае переопределение значения проверки срабатывает и перезаписывает последнее хорошее значение (если это поведение не отключено соответствующим свойством).

Событие ValueChanged должно срабатывать только при изменении фактического Value , а не при каждом изменении Text .

если это поведение не отключено соответствующим свойством

Что это за новое свойство?

Я не знаю, как более частые события решают проблему потери неверных значений и состояний ошибок при возврате к последнему известному хорошему значению.
Я чувствую, что здесь необходимы некоторые эксперименты, чтобы понять, как это будет на самом деле. (Если бы я только мог найти время ...)

По теме.

Я предполагаю, что существующее событие TextChanged унаследованное от TextBox , не будет изменено для потребителя. Но как насчет события TextChanging ? Будет ли здесь выполняться специфическая обработка нового элемента управления? Сможет ли потребитель элемента управления обработать и это событие?

Согласен - стоит изучить, но лучше всего этого избежать. Я изменил раздел о проверке и добавил свойство IsInvalidInputOverwritten, которое по умолчанию отключено. Что все думают о следующем:

• Ввод, который не является числовым форумным или превышает минимальные / максимальные значения, вызовет предупреждение о проверке
• Разработчик может перехватить события ValueChanged или TextChanged (которые раскрывают измененное свойство и то, которое будет обновлено) и вручную манипулировать недопустимым вводом до отображения предупреждения о проверке
• Включение свойства IsInvalidInputOverwritten вернет недопустимый ввод в последнее допустимое состояние без отображения предупреждения проверки ввода . Например, если IsInvalidInputOverwritten включен, StepSize = 0.2, MaxValue = 3.0 и значение 2,9 увеличивается, 3.1 будет регистрироваться как недопустимое и будет перезаписано обратно на 2.9.

Многое из этого можно резюмировать вопросом о том, должна ли проверка происходить во время ввода или после него. Я склоняюсь к этому ради производительности и потому, что опыт получения проверок при вводе может быть неприятным и труднодоступным, что приводит к тому, что вышеизложенное является моей предпочтительной реализацией.

FWIW, Adobe Photoshop и Illustrator возвращаются к предыдущему значению при попытке ввести недопустимое значение. Это имеет поведение вычисления, но суффикс единицы измерения является частью текста, что само по себе может вызвать проблемы с проверкой :)

Хотел подбросить идею, о которой я сам себе противоречил - я могу вспомнить из многих прошлых опытов, когда у меня было какое-то поле числа сортировки с функцией увеличения / уменьшения, переход ниже минимального значения вернул бы меня обратно к верхнему значению, наоборот. Я хотел посмотреть, имеет ли здесь смысл что-то вроде свойства _ValuesWrap_.

Это, очевидно, не имеет смысла во всех случаях, но в случаях с ограниченным числовым диапазоном в прошлом для меня было интуитивно понятно предполагать перенос чисел в таких случаях, как запись Age или DateOfBirth или для других случаев с небольшим диапазоном. С другой стороны, это иногда происходит только потому, что в этих случаях используется поле выбора с несколькими вариантами выбора, и они обычно переносят значения вместо остановки. Просто хотел проверить, есть ли в этом какое-либо обоснование или необходимость - это, конечно, вероятно, может быть реализовано на стороне разработчика через любое событие onValueChanged с дополнительной работой.

cc @SavoySchuler

Замечательная идея, @KevinTXY. Если кому-то из наших разработчиков понадобится что-то подобное, мы можем добавить это!

Время вопросов: есть ли у кого-нибудь реальные сценарии приложений, которые оправдывают необходимость поддержки шестнадцатеричного или двоичного кода? Обертывание максимальных / минимальных значений?

Я хотел посмотреть, имеет ли здесь смысл что-то вроде свойства ValuesWrap.

да, если у вас есть свойство угла, которое вы хотите перейти 359 → 0, в основном мод 360. Интересно то, что мне все равно пришлось создать подкласс элемента управления (был в Qt), потому что MaxValue мог быть только включающим, поэтому я мог указать 359 или 360, но я действительно хотел иметь возможность писать 359,99, но не 360 (т.е. я хотел <, а не ≤).

QSpinBox имеет свойство обертывания для этой цели https://doc.qt.io/qt-5/qabstractspinbox.html#wrapping -prop

@SavoySchuler Что касается шестнадцатеричного числа, я подозреваю, что шестнадцатеричный редактор может этого захотеть, но это похоже на действительно нишевый вариант использования, вам не нужно поддерживать все возможные вещи, просто убедитесь, что элемент управления легко подклассифицировать. В Qt у элемента управления есть метод, который преобразует строку текстового поля в числовое значение (int или double), которое можно переопределить.

Например, если IsInvalidInputOverwritten включен, StepSize = 0.2, MaxValue = 3.0 и значение 2,9 увеличивается, 3.1 будет регистрироваться как недопустимое и будет перезаписано обратно на 2.9.

В этом случае вы, вероятно, могли бы ограничить MaxValue.

@SavoySchler @xyzzer @mrlacey Я видел в твиттере, что в 20H1 есть что-то, что обеспечивает интеллектуальный ввод текста.

Это может помешать функции завершения предварительного просмотра, о которой мы говорили, и, возможно, необходимо что-то подавить в элементе управления NumberBox. Переходя к элементам управления Win32 и XAML, кажется ...

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

Я бы предположил, что обработка шестнадцатеричного или двоичного кода является даже более специализированным сценарием, чем обработка «строк, которые выглядят как числа», таких как номера телефонов и почтовые индексы. (и привносят свою сложность)
Таким образом, я думаю, что они должны быть вне области действия элемента управления NumberBox.

Говоря о функции предварительных расчетов, на случай, если она была упущена, я бы предложил дать пользователю возможность включить / выключить ее. Так что, возможно, добавив свойство вроде

public bool ShowPreviewResult { get; set; }

Зачем показывать результат предварительного просмотра? 🤔 Не похоже, чтобы пользователь изменил свою формулу в зависимости от результата, если они знают желаемый результат, они сразу же напечатают его.

Зачем показывать результат предварительного просмотра? 🤔 Не похоже, что пользователь будет вводить то, что он набирает, в зависимости от результата, если они знают, что они хотят, они просто напечатают это сразу

Одной из функций элемента управления является возможность ввода в вычисление, например 32 * 4, которое будет разрешено как 128 - функция предварительного просмотра покажет, каким будет этот результат, когда элемент управления теряет фокус или нажимается Enter.

@adrientetar Предварительный просмотр пока является предварительным. Я считаю, что значение будет частично находиться в ориентированной на пользователя проверке до того, как сработает проверка элемента управления, например, оно показывает только то, что введенное значение может быть вычислено / находится в пределах; например, проверка ожиданий («Я набрал время вместо плюса?»). Там проценты и окупаемость здесь пока не ясна.

Еще раз спасибо за отзыв, всем! Похоже, что на данный момент нет насущной необходимости или оправдания интереса к поддержке двоичных или шестнадцатеричных чисел. Его также можно разделить на подклассы, предложить в качестве нового элемента управления или предложить для V2 по мере необходимости.

@SavoySchuler в отношении

В случае, если более тонкая граница для текстовых полей не @chigy и принятия решений командой разработчиков WinUI - я подумал, что должен подготовить макет дизайна, который соответствует текущим предложениям по дизайну текстовых полей.

@kmahone - согласился. Как вы упомянули сегодня утром в кулере для воды, возможность удалить большой объем кода из ColorPicker, заменив его экземпляры локальной логики проверки TextBox + на NumberBox, может быть сама по себе победой.

@mdtauk - я слишком много раз говорил вам, что ваши макеты выглядят невероятно? Я скоро внесу их в спецификацию!

@SavoySchuler Если бы команда разработчиков Windows

Конечно, @mdtauk! Я надеюсь зафиксировать здесь функциональные требования для @KevinTXY в ближайшем будущем, и тогда я перейду к разговору о конвергенции дизайна с

Спасибо за обсуждение, я очень рад работать над этой функцией этим летом в качестве стажера!

Если это кому-то важно, я запустил прототип элемента управления на C # в следующем репозитории.
https://github.com/KevinTXY/NumberBox

По сути, это мой первый раз, когда я изучаю C # / UWP, так что все будет продвигаться медленно, и если кто-нибудь взглянет на это, я буду рад получить отзывы о том, что можно было бы сделать лучше!

Примерно реализованы следующие функции:

• Валидация числового ввода (пока не соответствует спецификациям предложения по
• Хранение / привязка значений
• Нулевая обрезка
• Полная поддержка ввода калькулятора / формул

В настоящее время работает над кнопками счетчика и тестовыми приложениями, а также над проверкой минимума / максимума.

Ваше здоровье!

Обновление графика!

Я интегрировал в спецификацию несколько обновлений, предложений и отзывов, которые я проверю с командой WinUI сегодня (четверг). Я надеюсь более или менее доработать API и поведенческие компоненты для V1.

Теперь я перейду к входам и доступности, данным и аналитике и визуальным компонентам.

Последним шагом будет приведение в порядок документации и формирование руководств.

Я думаю, что вариант несвязанного и непрерывного является очень нишевым без варианта использования, который должен был выполняться пользовательским интерфейсом приложений / оболочки Microsoft в WPF или Win32.

Если вы хотите включить его, я бы предпочел, чтобы это был включенный стиль, который вы можете применить к элементу управления, чем вариант. Как повторно шаблонные элементы управления NumberBox будут работать с этим свойством в своих новых шаблонах?

Если консенсус состоит в том, что этот режим должен быть включен, то могу ли я предложить ему стать значением перечисления как частью SpinButtonPlacementMode . Не уверен, как будет называться этот вариант. _Straddled_, возможно, недостаточно профессионален, смеется, и я не уверен, что _Bookended_ лучше.

Я просто смотрел последнюю версию Canary для Edge и увидел дизайн <input type="number"/> который наиболее близок к элементу управления NumberBox.

Просто подумал, что поделюсь этим изображением.

@mdtauk - согласен, SpinButtonPlacementMode будет подходящим местом для добавления альтернативных вариантов размещения SpinButton.

Что касается имен, @ Felix-Dev справедливо упомянул о том, что SpinButton, возможно, не самое интуитивно понятное или широко известное имя. SpinBox и UpDownButtons также имеют приоритет в экосистеме Windows. Я подхожу к этому чуть позже, но, пожалуйста, дайте мне знать, есть ли у кого-нибудь аргументы против любого из этих вариантов.

@mdtauk - Спасибо, что поделились этим! Я тоже использую Canary, поэтому я посмотрю, есть ли что-нибудь, чему мы можем научиться, или есть ли место, чтобы предложить согласовать разработки!

@SavoySchuler Я использую флаг Fluent Controls Enabled (включая экспериментальные элементы управления)

Я думаю, что реализация WinUI будет более продуманным дизайном, на который следует обратить внимание Fabric Web и Edge, но выравнивание - это хорошо.

Номер типа ввода w3schools

Кроме того, этот ползунок близок к тому, что планирует сделать WinUI, но не совсем так (обведенный круговой ползунок по сравнению с закрашенным кругом).

Я до сих пор не знаю, как настроить функции локализации. В США точка используется для десятичного разделителя. В Нидерландах (где я живу) мы используем запятую. Разделителем группировки в США является запятая, а в Нидерландах - точка.

Пример:

Должен ли я использовать свойство Language элемента Framework для указания разделителя цифр и группировки?

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

Я просто смотрел последнюю версию Canary для Edge и увидел дизайн <input type="number"/> который наиболее близок к элементу управления NumberBox.

Просто подумал, что поделюсь этим изображением.

@mdtauk , @SavoySchuler ,
Я не знаю, откуда взялся этот контроль. По словам моего контакта в команде Edge, вот элементы управления, которые они будут использовать.

Слайдер: https://explore.fastdna.net/components/slider/
Числовое поле: https://explore.fastdna.net/components/number-field/

Я не уверен, обновят ли они визуализацию, и окончательный результат может выглядеть не так (я так полагаю, но это мое безумное предположение).

@chigy Это изображение было из текущей сборки Edge Canary, но, как я уже заметил, это WIP и необязательный флаг, который вы включаете.

Думаю, это объясняет, для чего предназначен этот проект fastdna, о котором я говорил в предыдущем выпуске. 🙂

Должен ли я использовать свойство Language элемента Framework для указания разделителя цифр и группировки?

Эти параметры , как правило , происходят из «области», так что я думаю , что мы бы просто передать в HomeGeographicRegion конструктору DecimalFormatter. Я не вижу других мест в API, где мы позволяем пользователям настраивать регион (наши средства форматирования даты и времени не кажутся настраиваемыми?), Но средства выбора позволяют настраивать строку формата, поэтому, возможно, мы могли бы разрешить что и здесь.

Я не вижу способа настроить символы-разделители в API DecimalFormatter, поэтому их нужно извлекать из языковых настроек. 😖

@jevansaks , спасибо за понимание! Я отмечу @sonnemaf, чтобы убедиться, что он видит ответ.

@jevansaks, можете ли вы написать пример xaml, как использовать DecimalFormatter для NumberBox? Я хочу определить его в XAML, а не в коде. Для меня также подойдет наличие свойств DecimalSymbol и GroupingSymbol. Хотя это может быть слишком просто.

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

Извините, что вмешался, я только что открыл для себя эту тему, но ДА ДА ДА. Оба они часто отсутствуют в числовых элементах управления, и я и многие другие разработчики на github должны найти обходные пути для этого. В частности, в примере с калькулятором он должен не только форматировать число в шестнадцатеричном формате, но и полностью поддерживать ввод.

В данный момент я хотел бы предложить вам сделать префикс hexdecimals настраиваемым. В какой-то момент лучше вообще не иметь префикса, а в других случаях это не всегда 0x

вы можете написать пример xaml, как DecimalFormatter для NumberBox? Я хочу определить его в XAML, а не в коде. Для меня также подойдет наличие свойств DecimalSymbol и GroupingSymbol. Хотя это может быть слишком просто.

@sonnemaf все, с чем нам нужно работать в WinRT, - это DecimalFormatter, и, к сожалению, он не позволяет настраивать эти параметры. Единственный способ настроить десятичный символ или символ группировки - через пользовательские настройки в панели управления регионом ОС (насколько я могу судить).

Тем не менее, соблюдение региона пользователя для этих настроек кажется правильным - есть ли у вас сценарий, в котором вам нужно переопределить их?

@sonnemaf

Есть ли у кого-нибудь реальные сценарии приложений, которые оправдывают необходимость поддержки шестнадцатеричного или двоичного кода?

Извините, что заметил это и ответил немного поздно. Я считаю, что поддержка шестнадцатеричного / двоичного кода была бы очень полезной. Я активно участвую в проекте .NET IoT, и мы работаем в основном в шестнадцатеричном / двоичном мире, поскольку мы манипулируем битами / байтами, которые читают / записывают в регистры и контакты для управления вещами.

Поддержка шестнадцатеричного / двоичного кода была бы очень признательна. Спасибо

Мне не нужны шестнадцатеричные или двоичные файлы. Было бы неплохо иметь, особенно бинарный.

Обновление для разработчиков

Всем привет! Мы довольны спецификацией NumberBox, и я просто хочу обратить внимание, что я активно работаю над контролем , в идеале первый PR с наиболее важными функциями будет сделан очень и очень скоро, возможно, сегодня вечером.

Некоторые примечания:

• Мы решили не создавать подклассы TextBox, особенно из-за некоторых сложностей дизайна с InputValidation, NumberBox будет собственным элементом управления, содержащим TextBox.
  
  
  
  • Это означает, что все свойства TextBox не будут отображаться. Мне любопытно услышать, важно ли что-то из этого передать в NumberBox - я мог бы увидеть желание _Header, PlaceHolderText_ и, возможно, также _Text_? Определенно хотел приоткрыть это, потому что с моей стороны это очень легко изменить.
  
  
• Я вношу очень небольшие изменения в спецификацию, на данный момент это в основном просто исправления формулировок, но все еще остаются открытые вопросы, такие как предварительный просмотр значений, и когда я пишу элемент управления, я генерирую некоторые из своих собственных вопросов дизайна. Это все еще хорошее время, чтобы добавить информацию 😄

@KevinTXY Было одно предложение

• PlaceHolderText
• Заголовок
• Текст
• Значок проверки
• Сообщение о проверке
• Выбор
• Выделение
• Состояния фокуса / ресурсы и т. Д.

Я считаю, что это некоторые из обязательных элементов TextBox. Не уверен насчет кнопки «чистый текст», которая имеет больше смысла с длинными строками текста.

Предварительный просмотр значений, который я думал, был функцией V2, но изменилось ли это? В элементе управления «Ползунок» есть всплывающая подсказка, показывающая значение при перемещении ползунка. Я предложил это как один из способов справиться с этим, а также использовать сообщение проверки, чтобы справиться с этим, или отобразить его в строке.

У Inline есть проблема, связанная с тем, что Windows Insider экспериментирует с прогнозирующим завершением текста, отображаемым либо в виде всплывающей подсказки, либо в текстовых полях. Какой бы метод предварительного просмотра ни был выбран, он не должен противоречить тем или иным функциям прогнозирования, отключенным для этого элемента управления.

@KevinTXY Было одно предложение

NumberBox в настоящее время является собственным элементом управления (расширяет Windows.UI.Xaml.Controls.Control), который содержит TextBox в своей разметке, а не расширяет TextBox. Slider звучит интересно, но я думаю, что это сделало бы реализацию немного хакерской, в этих элементах управления также есть много свойств, которые мы не чувствовали принадлежащими NumberBox. Я не менеджер проекта, но по своему опыту разработки я считаю, что это хороший способ упростить разработку и обеспечить возможность расширения в будущем.

Я считаю, что это некоторые из обязательных элементов TextBox. Не уверен насчет кнопки «чистый текст», которая имеет больше смысла с длинными строками текста.

Это потрясающе - именно то, что я искал! Я согласен, что во всем этом есть ценность. Кнопка «Очистить все» в настоящее время присутствует, поскольку это функция по умолчанию для текстового поля - я полагаю, она имеет значение для больших записей или пользователей сенсорных экранов, хотя я еще не думал об ее отключении. Я определенно, по крайней мере, попытаюсь включить в предварительный просмотр три упомянутых мною (Header, PlaceholderText, Text).

Что касается предварительного просмотра значений, то здесь ничего не доработано, и это только в спецификации как открытый вопрос. Я полагаю, что самым простым временным решением было бы просто предоставить разработчикам значение предварительного просмотра для отображения по своему желанию - это может быть легко в рамках предварительной версии, но я оставлю это для @SavoySchuler & Co., чтобы он мог звонить. В любом случае расчеты, вероятно, даже не войдут в мой PR хотя бы в течение нескольких дней, пока я исследую математические машины, так что это не срочная деталь. Я ценю проведенное исследование, здесь много интересных идей!

@KevinTXY В идеале было бы сотрудничество с командой Calculator, чтобы создать базовый механизм вычислений, который можно было бы встроить, а также для будущего использования с идеей CalculatorPicker, которая обсуждалась вместе с этим элементом управления. (Элемент управления с кнопкой калькулятора, который отображает всплывающее меню со стандартным калькулятором)

На самом деле, сотрудничество со специалистами по обслуживанию калькулятора звучит как отличная идея. Вы можете открыть службу приложения из Calculator, которая будет выполнять математические вычисления, так что вам даже не потребуется загружать двоичный файл WinUI - просто поговорите со службой приложения, если приложение установлено, а в противном случае - просто потерпите неудачу без предупреждения.

Что касается заимствования из Slider - я действительно сказал RangeBase, и я все еще уверен, что это правильно, поскольку элемент управления в основном предоставляет почти все свойства и функции доступности, которые вам понадобятся, и заимствование из него обеспечит согласованную поверхность API среди ваш контроль и ползунок превращают их в легкую замену.

Ах да, RangeBase, вот и все.

В калькуляторе недавно была проделана работа по поддержке режима CompactOverlay, который всегда отображается наверху, так что размещение клавиатуры меньшего размера во всплывающем меню, аналогичном по размеру CalendarFlyout, является более достижимым. (Если элемент управления CalculatorBox одобрен для включения.

Не уверен, что это служба приложения (которая будет связывать обновления WinUI, частично зависящие от обновлений хранилища калькулятора, или это двоичный файл службы, который можно добавить в WinUI и получить из движка калькулятора.

Обновление: Код PR теперь существует 🎆!

Я отслеживаю некоторые проблемы там, но большинство из них не связано с дизайном.

Спасибо, @xyzzer и @mdtauk! Мы проверили RangeBase, и похоже, что он несет такой же багаж, как и подкласс TextBox. На данный момент мы будем использовать TextBox в элементе управления и добавлять только необходимые свойства и специальные возможности. Это все еще было стоящим рассмотрением и помогло нам проинформировать наш разговор о доступности, который происходит сейчас.

@mdtauk , спасибо за стартовый список! @KevinTXY начал предоставлять перечисленные вами API, и я скоро рассмотрю остальные.

Предварительный просмотр и всплывающий калькулятор, как упоминалось в @KevinTXY , в переговорах (хотя здесь нет гарантии v1). Мы активно обсуждаем вопросы согласования и работы с калькулятором. Вы молодцы! Спасибо за то, что продолжаете внедрять инновации в этот элемент управления. Это потрясающе. @KevinTXY разместил свой PR кода выше. Незадолго до того, как я перейду к составлению руководств и документации, я поделюсь со спецификацией все оставшиеся свободные концы.

Именование

Было так много комментариев, что спецификация ускользнула от меня, поэтому я только начинаю смотреть, как все уляжется. Во-первых, я заметил некоторые наименования, которые на самом деле не соответствуют соглашению C # - да, я знаю, что эти элементы управления написаны на C ++, но я все еще считаю, что это несовместимо с другими именами на платформе.

| Тип | Текущее имя | Предлагаемое имя |
| ------- | ---------------- | ------------------- |
| Boolean | AcceptsCalculation | IsCalculationAccepted |
| Boolean | HyperDragEnabled | IsHyperDragEnabled |
| Boolean | HyperScrollEnabled | IsHyperScrollEnabled |

StepFrequency

Кроме того, что такое StepFrequency? Это не определено в спецификации, и у меня нет опыта работы с "XAML Toolkit's NumericUpDown". В зависимости от того, что это делает, добавление слова «Частота» может не иметь смысла. Наверное, это просто «Шаг»? В элементе управления «Ползунок» TickFrequency имеет смысл, потому что галочки отображаются на модуле общего диапазона max-min. Однако в этом элементе управления я думаю, что это всего лишь минимальный размер приращения / шага. По сути, сможет ли пользователь ввести значение, выходящее за рамки шага?

Например, MinValue = 0, MaxValue = 6, StepFrequency = 2. Использование значения стрелки вверх будет достаточно {2, 4, 6}. Может ли пользователь ввести 0,5 как допустимое значение? Или это будет округлено до 0 или 2 в зависимости от RoundingMode?

Мин. / Макс. Значение

Я думаю, что для двух приведенных ниже свойств они должны быть минимальными и максимальными, как и в других элементах управления (Slider, RangeBase). API должны быть последовательными.
Double MinValue;
Double MaxValue;

Кнопки повтора вверх-вниз

Еще одна особенность, которая, насколько мне известно, не обсуждалась, заключается в том, нужно ли делать кнопки вверх / вниз на самом деле RepeatButtons (я думаю, что они должны быть). Если это кнопки повтора, то свойства Delay / Interval должны быть добавлены как элемент управления Slider: Slider.Interval Slider.Delay

Цифры

Можете ли вы добавить описание того, что представляют собой IntegerDigits и FractionDigits? Я предполагаю, что они ограничивают количество цифр для каждой части числа. IntegerDigits = 2 означает, что максимальное значение может быть 99. FractionDigits = 3 означает, что MaxValue может быть 0,999. Кроме того, как SignificantDigits переопределяет эти два свойства?

Отрицательный ноль?

Зачем нужна эта недвижимость? Это само по себе дело локализации? Я никогда не видел "-0.0" или "-0". Всегда просто «0».
Boolean IsZeroSigned;

Локализация

Я непреклонен, мне нужен этот элемент управления для поддержки переопределения локализации пользовательского интерфейса и числового формата. У меня есть несколько вариантов использования (финансовые приложения), где мне нужны местные и иностранные суммы, которые должны отображаться по-разному. Я не вижу этого нигде в спецификации.

Преобразование из double в текст должно настраиваться с помощью ValueConverter в духе Slider.ThumbToolTipValueConverter. Таким образом, самая сложная часть может быть настроена под любые нужды, как в некоторых реальных примерах ниже:

Обратите внимание, что десятичный разделитель для чисел и денег может быть другим, как и обозначение отрицательных сумм, поэтому, вероятно, самый безопасный подход для NumericBox без ValueConverter - работать в целочисленном режиме. Калькулятор тоже может быть реализован в виде ValueConverter, нет необходимости перегружать элемент управления этой работой.

@eugenegff У вас действительно хорошая идея сделать преобразование числа в строку универсальным. Это позволило бы мне заниматься локализацией, но также позволило бы разработчикам делать все, что им нужно, например, добавлять единицы.

Единственная сложность, которую я вижу, - это сохранение Culture / NumberFormatInfo, связанного с элементом управления. Я предполагаю, что это может быть параметр конвертера в XAML, идущий в пользовательский IValueConverter, но, вероятно, должен быть более чистый способ справиться с этим в самом элементе управления.

Зачем нужна эта недвижимость? Это само по себе дело локализации? Я никогда не видел "-0.0" или "-0". Всегда просто «0».

Это свойство класса DecimalFormatter в Windows. Это странно? Наверное. Есть некоторые свойства, такие как IsGrouped и свойства локализации, которые мы не учли, поэтому, возможно, и в этом нет необходимости. В то же время он уже реализован, поэтому его удаление не имело бы никакой другой цели, кроме как разблокировать 3 строки кода. Достаточно интересно, что существуют обычаи и предварительные требования IEEE для наличия подписанных нулей .

Я непреклонен, мне нужен этот элемент управления для поддержки переопределения локализации пользовательского интерфейса и числового формата. У меня есть несколько вариантов использования (финансовые приложения), где мне нужны местные и иностранные суммы, которые должны отображаться по-разному. Я не вижу этого нигде в спецификации.

@SavoySchuler, возможно, нам стоит изучить поддержку настроек языков в классе DecimalFormatter? Я не знаком с тем, как он себя ведет.

Хорошо, я думаю, что понимаю основную проблему здесь. В мире C ++ у вас есть доступ к DecimalFormatter, но в мире C # (если я использую WinUI) я бы обычно использовал IFormatProvider (NumberFormatInfo из указанной культуры). NumberFormatInfo уже имеет большинство свойств (по совпадению отсутствует IsZeroSigned), поэтому я подумал, что просто разрешите разработчикам указывать это или IFormatProvider. Что ж, вот в чем проблема: C ++ не может использовать IFormatProvider, поскольку он из мира .net.

Итак, как этот элемент управления полностью поддерживает локализацию на C # и C ++, учитывая, что у них есть два разных способа сделать это? Что ж, если у Microsoft нет умного решения, я могу думать только о двух возможностях:

1. Полностью добавьте все свойства для форматирования чисел (фактически повторно реализовав NumberFormatInfo и DecimalFormatter). Добавление только IsZeroSigned, IntegerDigits, FractionalDigits и т. Д. Не покрывает его. Также требуются NumberNegativePattern, NumberGroupSeparator, NumberGroupSizes и т. Д.
2. Сделайте так, как предложил @eugenegff, и позвольте разработчикам переопределить форматирование с помощью какого-либо обратного вызова. Честно говоря, это кажется самым простым подходом.

Меня немного беспокоит, как складывается локализация в этом элементе управления. С самого начала занимаюсь локализацией (3-й комментарий по этой теме!). Должен быть какой-то способ полностью настроить числовой формат при преобразовании элемента управления в строку. Без этого этот контроль будет весьма ограничен при использовании в реальном мире.

Итак, как этот элемент управления полностью поддерживает локализацию на C # и C ++, учитывая, что у них есть два разных способа сделать это?

Мы вас слышим! Это то, что мы изучали в автономном режиме, но, по сути, .NET выполняет свою собственную локализацию отдельно от платформы. Я думаю, что обратный вызов для отмены - отличный выход, но я надеюсь, что ваш вариант 1 - это путь, которым мы можем пойти. На данный момент API WinRT для форматирования и синтаксического анализа не имеют всех необходимых нам ручек настройки. Мы все еще ведем расследование.

Не проверял, обсуждалось ли это уже, но хотел быстро спросить, видит ли кто-нибудь большую потребность или, что более важно, какой-либо прецедент в поддержке функций для вычислений, что означает любое из следующих или более:
cos(), sin(), tan(), asin(), acos(), atan(), sqrt(), log(), abs(), ceil(), floor(), degree equivalents of trig functions, hyperbolic functions, etc

Я сшиваю математические синтаксические анализаторы, чтобы они соответствовали нашим потребностям, а функции усложняют процесс преобразования в RPN (при этом у меня уже есть версия, поддерживающая эти с некоторыми ошибками), поэтому мне интересно узнать, стоит ли что-нибудь из этого. проблема или если кажется, что вздутие живота. Я лично не думаю, что это подходит слишком хорошо, но если есть много прецедентов, это не слишком хлопотно.

Я думаю, что в большинстве случаев их будет сложно обнаружить, и если кому-то нужна поддержка более сложных функций - лучше поработать над открытием синтаксического анализа для события обратного вызова, позволяющего пользователям реализовать свою собственную логику синтаксического анализа или предварительной обработки.

Что было бы более ценно, так это позволить начать ввод текста с помощью оператора, поэтому, если вы щелкнете по тексту, он выберет все по умолчанию, и вы можете либо ввести новое значение, не нажимая сначала удалить, чтобы удалить предыдущее, либо просто введите что-то вроде «* 1.2» или «x1.2» [Enter] и умножьте текущее значение на 1,2, даже если введенный текст больше не содержит введенного значения. То же самое будет работать для «+2», «-5», «/ 3», «% 120» и т. Д.

Он используется в некоторых профессиональных приложениях.

Нам (BeLight Software, проект Live Home 3D) нужен подключаемый ValueConverter для преобразования значения <=> текста, иначе NumberBox нам не подойдет.

Я думаю, что использование этих функций будет довольно редким явлением, у меня есть ввод угла в моем приложении, но это всего лишь градусное значение. Самым важным для меня использованием является возможность добавить значение к существующему или разделить существующее на число, просто чтобы сэкономить время и избежать мысленных вычислений. (Кстати, я думаю, что это то, что есть в приложениях Adobe, 4 арифметических оператора: https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/suggestions/12992463-support-math-operators-in-number -поля)

Также функции, такие как cos (), вы, вероятно, не захотите там, где это не имеет смысла, если вы не создаете какое-то приложение Excel.

Самым важным для меня использованием является возможность добавить значение к существующему или разделить существующее на число, просто чтобы сэкономить время и избежать мысленных вычислений.

Ок, отлично! Похоже на то, что предложил @xyzzer . Я посмотрю на похожие реализации и посмотрю, есть ли место, чтобы сделать это естественным и интуитивно понятным способом.

Нам (BeLight Software, проект Live Home 3D) нужен подключаемый ValueConverter для преобразования значения <=> текста, иначе NumberBox нам не подойдет.

Я взглянул на приведенный вами пример Slider, и он звучит очень разумно - я мог видеть значение в IValueConverter для NumBox. Я скоро рассмотрю его, и мы постараемся решить, подходит ли он к спецификации должным образом. Но пока никаких обещаний!

@KevinTXY Я подозреваю, что добавление функций, о которых вы упомянули выше , откроет дверь к большему количеству проблем, чем та ценность, которую они могут предоставить. Это связано с тем, что это позволит вводить в элемент управления большее количество символов (в основном любую букву). В свою очередь, это упростит случайный ввод чего-то недопустимого, а также усложнит проверку и анализ.
Это также приведет к разрыву первой строки описания в начале спецификации «Числовое поле - это текстовый элемент управления только для цифр ...».

Я удивлен, что по-прежнему есть вопросы по локализации. Поскольку элемент управления будет (должен?) Унаследовать от FrameworkElement он будет иметь доступ к свойству Language, и поэтому, как и любой другой FrameworkElement, поддерживает прямую установку языкового стандарта и не зависит от настроек пользовательского интерфейса языкового стандарта системы.
Это означает, что такие вещи, как десятичные числа и символы группировки, могут быть установлены для каждого экземпляра.

Я удивлен, что по-прежнему есть вопросы по локализации.

Проблема в том, что форматирование управляется не языком, а настройками региона / культуры. Локализация заключается в обновлении строк пользовательского интерфейса для отображения на правильном языке, тогда как форматирование числа / валюты / даты и времени контролируется регионом. Подробнее здесь: https://docs.microsoft.com/en-us/globalization/locale/locale-and-culture. И что еще больше усложняет ситуацию, Windows позволяет вам настраивать параметры локали в пользовательском интерфейсе, переопределяя значения по умолчанию - так что вы можете сказать, что хотите, чтобы десятичным разделителем был любой случайный символ вместо значения по умолчанию. Кроме того, .NET позволяет приложениям настраивать и это, поэтому разработчики ожидают здесь такого уровня настройки.

Проблема в том, что форматирование управляется не языком, а настройками региона / культуры. Локализация заключается в обновлении строк пользовательского интерфейса для отображения на правильном языке, тогда как форматирование числа / валюты / даты и времени контролируется регионом. Подробнее здесь: https://docs.microsoft.com/en-us/globalization/locale/locale-and-culture. И что еще больше усложняет ситуацию, Windows позволяет вам настраивать параметры локали в пользовательском интерфейсе, переопределяя значения по умолчанию - так что вы можете сказать, что хотите, чтобы десятичным разделителем был любой случайный символ вместо значения по умолчанию. Кроме того, .NET позволяет приложениям настраивать и это, поэтому разработчики ожидают здесь такого уровня настройки.

Language принимает значение, которое переводится в CultureInfo примечание о том, что язык и региональные параметры называются локалью при разработке неуправляемого кода. Он содержит свойство NumberFormat которое является типом NumberFormatInfo которое содержит свойства для десятичных знаков, группировки, отрицательных знаков и т. Д.

Насколько я понимаю, если вы хотите принудительно применить к элементу управления определенное форматирование или другие особенности локализации, а не полагаться на системные настройки, то способ сделать это - указать Language .

В описании свойства четко указано, что оно «устанавливает информацию о языке локализации / глобализации, которая применяется к FrameworkElement».

Или, может быть, я неправильно понял документы, на которые я ссылаюсь, но все они, похоже, подтверждают то, что описано на странице, на которую вы ссылаетесь.
Возможно, это проблема терминологии, в которой C ++ и C # используют разные термины.
Что я знаю, так это то, что установка языка в XAML - это то, как я бы принудительно использовал культуру / языковой стандарт в любом другом приложении и с любым другим элементом управления.

Вопросы, которые я видел по локализации, касались принудительного использования определенных числовых форматов или групповых и десятичных разделителей. Или реальная проблема заключается в том, как управлять ими, не влияя на локализацию текстовых свойств (Header, PlaceholderText и т. Д.) Элемента управления?

Language принимает значение, которое переводится в CultureInfo

Не в native / WinRT, мы просто получаем строку языка BCP-47. И вот в чем проблема. В .NET вы объединяете CultureInfo, в котором есть настройки языка и формата. В WinRT он отдельный и не имеет эквивалента объекту CultureInfo.

Я слышал, что API-интерфейсы ICU могут позволить то, что мы ищем, но у нас еще не было возможности исследовать это.

Я думаю, что Microsoft придется подумать над тем, чтобы не пропустить этот вопрос и полностью реализовать механизм преобразования между культурами / локализацией .net (CultureInfo) и нативным / WinRT. В идеале вы бы не рассматривали новый способ ведения дел:

Я думаю, что управляемый код - это то, на чем написано большинство бизнес-приложений, и это нужно делать правильно с самого начала. WinRT должен иметь те же механизмы / методы локализации, что и .net, и преобразования должны быть автоматическими.

Было бы намного больше работы? Краткосрочный: да, долгосрочный: нет. Может ли это задержать выпуск элемента управления NumberBox? Возможно, если только обратные вызовы не использовались в краткосрочной перспективе.

Это должно быть сделано правильно, иначе возникнут проблемы в другом месте. Я уже могу предвидеть некоторые аналогичные проблемы с другими сценариями, такими как редактируемый CalendarDatePicker и т. Д. (# 735)

@SavoySchuler @jevansaks @chigy @mrlacey @KevinTXY
Очевидно, команда FastDNA также работает над своим элементом управления Spinner для своего дизайна поля ввода чисел, и они выступили с предложением, которое, возможно, стоит рассмотреть.

Они также спросили, почему мы используем шевроны, а не стрелы.

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

Даже если мы будем держать кнопки бок о бок, может ли быть идея, если ширина элемента управления будет слишком узкой? Может быть, можно было бы достичь консенсуса по макету, который работает во всех фреймворках Microsoft UI?

@mdtauk , спасибо, что
Проверка у людей FastDNA, если это дизайн, на котором они тестируют и проверяют удобство использования.

Вернуться к NumberBox

Хорошо, команда,

Приносим извинения за неожиданный перерыв. Я снова на полной мощности NumberBox, и @teaP присоединяется ко мне в качестве разработчика функций! Мы все еще нацелены на конец ноября для предварительного просмотра этого элемента управления, что заставит нас посмотреть на стабильный выпуск с WinUI 2.4.

В старом рабочем процессе много багажа, поэтому я сохраню все открытые вопросы или ответы на них и @teaP завершим решение оставшихся открытых тем, касающихся:

• локализация
• дизайн (особенно в отношении кнопок вверх / вниз)
• гиперскролл / гипердраг

Обратите внимание, что тема проверки решена. Поскольку работа по проверке ввода @LucasHaines запланирована для WinUI 3.0 и планируемого выпуска NumberBox до этого, мы сократили поддерживаемые режимы проверки NumberBox V1 до:

Переменная перечислимого типа NumberBoxBasicValidationMode
{
Отключено,
InvalidInputOverwritten,
};

Приходите WinUI 3.0 и сопутствующую работу по проверке ввода, мы будем стремиться расширить это перечисление с помощью первоначально запланированных режимов проверки IconMessage и TextBlockMessage в NumberBox V2.

Сейчас я собираюсь вернуться ко всему нашему предыдущему прогрессу, и я буду публиковать вопросы и запрашивать отзывы по мере необходимости. Спасибо, что остаетесь с нами. 😄

Уф. Это было близко ко мне, пытаясь сделать это сам.

Ха-ха, я бы хотел продолжать работать над этим пассивно, но этот семестр сбил меня с толку. Рад видеть, что он заворачивается, я буду следить за ним!

Начальная фиксация NumberBox уже доступна!

ПОЖАЛУЙСТА - имейте в виду, что это все еще незавершенная работа с активным отслеживанием проблем как для разработчиков, так и для PM . Если вы обнаружите ошибки или общие недостатки в функциях, которые еще не были отмечены ни по одной из соответствующих ссылок, дайте нам знать. 😊

@SavoySchuler , вы откроете новый PR для спецификации? Кроме того, вы обратили внимание на то, что я пишу в этом комментарии, в частности, относительно отображения NaN? Спасибо.

@SavoySchuler Некоторые комментарии к коду spec / NumberBox. Надеюсь, комментарии к этому также могут попасть в спецификацию / документацию. В целом, приятно видеть это вместе!

StepFrequency

Использование здесь слова «частота» меня не устраивает. В элементе управления «Ползунок» TickFrequency имеет смысл, потому что такты рассчитываются и отображаются по модулю общего диапазона max-min. Однако в этом элементе управления это просто размер приращения / шага. Это больше похоже на «StepAmount» или «StepValue» - еще лучше просто «Step», похожее на «Minimum» вместо «MinimumValue».

Кроме того, сможет ли пользователь ввести значение, выходящее за пределы определенного шага?
Например, Minimum = 0, Maximum = 6, StepFrequency = 2. Использование стрелки вверх будет достаточно равным {2, 4, 6}. Может ли пользователь ввести 0,5 как допустимое значение? Или это будет округлено до 0 или 2?

Округление

Как выполняется математическое округление? Это особенно важно при вводе значений валюты с помощью выражений. Нам нужно иметь возможность указать или предоставить настраиваемое округление после вычисления выражения. HalfAwayFromZero - это то, что я ищу, чтобы начать, но другие режимы округления также должны быть разрешены.

Локализация

Пожалуйста, подтвердите, что NumberBox примет любую реализацию INumberFormatter / INumberFormatter2 - и будет продолжать делать это в будущем (именно так это реализовано в коде, я просто хочу убедиться, что спецификация тоже это называет). Это должно позволить полный контроль над локализацией текста по сравнению с использованием существующего CurrencyFormatter / DecimalFormatter. Замечательно, что у нас есть решение!

Перенос текста

Изменить: в следующий раз я должен прочитать всю спецификацию.

Почему вы создали новое свойство IsWrapEnabled? Это потому, что вы считаете, что термин «текст» не очень хорошо применим к NumberBox?

Кроме того, я понимаю, что, возможно, и Wrap, и WrapWithOverflow реализованы одинаково, но тогда просто разрешите оба значения перечисления быть эквивалентными и описать функциональность в документации.

Правильное обращение с клавиатурой

Убедитесь, что этот элемент управления поддерживает использование ускорителя клавиатуры лучше, чем TextBox. Возможно, это невозможно сделать, пока / если TextBox не будет исправлен, но # 1435 действительно является для меня проблемой, вызывающей множество уродливых решений. TextBox сам обработает вставку Ctrl + V, а затем будет активирован любой KeyboardAccelerator. Однако в KeyboardAccelerator нет способа узнать, что TextBox просто сделал свое дело.

Быстрая мысль. Если есть угловой режим, который будет добавлять глиф градуса к значению (и любую логику для поворота на 360 °)

°

Или этот отросток будет лучше обработан в будущем с моим предложением суффикса для TextBox # 784

@mdtauk , Добавление символа градуса возможно с помощью INumberFormatter2 - это еще одна веская причина, по которой его нужно сохранить общим. Вы можете сделать все необходимое, чтобы преобразовать число в строку и передать ее обратно в элемент управления.

Что касается упаковки, собственно для этого и предназначено свойство IsWrapEnabled ... В следующий раз мне нужно прочитать конец документации.

В итоге, я думаю, мы можем делать все, что вы хотите, с существующим API.

@mdtauk , Добавление символа градуса возможно с помощью INumberFormatter2 - это еще одна веская причина, по которой его нужно сохранить общим. Вы можете сделать все необходимое, чтобы преобразовать число в строку и передать ее обратно в элемент управления.

Что касается упаковки, собственно для этого и предназначено свойство IsWrapEnabled ... В следующий раз мне нужно прочитать конец документации.

В итоге, я думаю, мы можем делать все, что вы хотите, с существующим API.

Я знаю, что Min, Max, Wrap справляются с этим, но достаточно ли распространены Degrees, чтобы иметь явный режим Angle для поля? И должен ли он отображать символ в тексте TextBox, а внутреннее значение - это просто число.

@teaP Глядя на новый режим Compact SpinButtonMode, можно ли добавить анимацию отображения и скрытия к наложенным кнопкам вращения?

Вы также думали о добавлении Acrylic к этому, чтобы лучше сочетать ComboBox и другие поля формы с всплывающими элементами?

Изменить: это решит проблему видимости в темной теме. Есть ли намерение соответствовать цвету в фокусе TextBox или текущим цветам темы? Так или иначе, Acrylic решает эту проблему.

@SavoySchuler , вы откроете новый PR для спецификации? Кроме того, вы обратили внимание на то, что я пишу в этом комментарии, в частности, относительно отображения NaN? Спасибо.

@adrientetar точно. Когда NumberBox пусто, Value будет установлено в NaN (как вы и просили), и отобразится PlaceholderText .

@SavoySchuler Некоторые комментарии к коду spec / NumberBox. Надеюсь, комментарии к этому также могут попасть в спецификацию / документацию. В целом, приятно видеть это вместе!

StepFrequency

Использование здесь слова «частота» меня не устраивает. В элементе управления «Ползунок» TickFrequency имеет смысл, потому что такты рассчитываются и отображаются по модулю общего диапазона max-min. Однако в этом элементе управления это просто размер приращения / шага. Это больше похоже на «StepAmount» или «StepValue» - еще лучше просто «Step», похожее на «Minimum» вместо «MinimumValue».

Я поделился этим отзывом с

Кроме того, сможет ли пользователь ввести значение, выходящее за пределы определенного шага?
Например, Minimum = 0, Maximum = 6, StepFrequency = 2. Использование стрелки вверх будет достаточно равным {2, 4, 6}. Может ли пользователь ввести 0,5 как допустимое значение? Или это будет округлено до 0 или 2?

Пользователь может ввести любые числовые или юридические формульные данные, которые ему нравятся. См. В разделе форматирования пример того, как использовать свойство NumberFormatter для последующего приведения этого ввода к настроенному форматированию.

SpinButton будет только увеличивать или уменьшать это значение на определенный размер шага SpinButton (имя API теперь ожидает). Поэтому убедитесь, что вы правильно настроили форматирование и размер шага.

Используемая стратегия округления определяется вашим форматированием . Чтобы разъяснить пример DecimalFormatter, вот пример свойства округления, которое вы можете настроить.

Округление

Как выполняется математическое округление? Это особенно важно при вводе значений валюты с помощью выражений. Нам нужно иметь возможность указать или предоставить настраиваемое округление после вычисления выражения. HalfAwayFromZero - это то, что я ищу, чтобы начать, но другие режимы округления также должны быть разрешены.

Округление осуществляется посредством форматирования . Вот пример свойства округления, которое можно установить для DecimalFormatter. Я добавлю пример в Руководство, чтобы прояснить это. Спасибо еще раз. 😊

Локализация

Пожалуйста, подтвердите, что NumberBox примет любую реализацию INumberFormatter / INumberFormatter2 - и будет продолжать делать это в будущем (именно так это реализовано в коде, я просто хочу убедиться, что спецификация тоже это называет). Это должно позволить полный контроль над локализацией текста по сравнению с использованием существующего CurrencyFormatter / DecimalFormatter. Замечательно, что у нас есть решение!

Это цель текущей реализации. Что касается гарантий безопасности в будущем, у NumberBox по-прежнему будет решение для локализации и форматирования. На данный момент и в обозримом будущем мы это реализовали.

Перенос текста

Изменить: в следующий раз я должен прочитать всю спецификацию.

~ Почему вы создали новое свойство IsWrapEnabled? Это противоречит соглашению TextBox / XAML об использовании TextBlock.TextWrapping и TextWrapping Enum. Это потому, что вы считаете, что термин «текст» не очень хорошо применим к NumberBox? ~

~ Кроме того, я понимаю, что, возможно, и Wrap, и WrapWithOverflow реализованы одинаково, но тогда просто разрешите оба значения перечисления быть эквивалентными и описать функциональность в документации. Создание здесь нового свойства просто означает, что нам нужны новые преобразователи значений и т. Д., Я думаю, нет причин нарушать существующее соглашение. ~

Правильное обращение с клавиатурой

Убедитесь, что этот элемент управления поддерживает использование ускорителя клавиатуры лучше, чем TextBox. Возможно, это невозможно сделать, пока / если TextBox не будет исправлен, но # 1435 действительно является для меня проблемой, вызывающей множество уродливых решений. TextBox сам обработает вставку Ctrl + V, а затем будет активирован любой KeyboardAccelerator. Однако в KeyboardAccelerator нет способа узнать, что TextBox просто сделал свое дело.

NumberBox содержит текстовое поле и добавляет свойства и конфигурации сверху. Я помечу @jevan, так как он может иметь более полное представление, но моя интуиция

В общем, отличный отзыв @robloo! Я признателен за время, которое вы потратили на то, чтобы убедиться, что мы настолько полны и укомплектованы V1 NumberBox, насколько это возможно! Пожалуйста, дайте мне знать, если у вас возникнут еще вопросы. 😊

@mdtauk

Быстрая мысль. Если есть угловой режим, который будет добавлять глиф градуса к значению (и любую логику для поворота на 360 °)

°

Или этот отросток будет лучше обработан в будущем с моим предложением суффикса для TextBox # 784

Пока NumberBox не поддерживает отображение каких-либо нечисловых символов (поскольку даже формульные символы удаляются при вычислении выражений).

Я думаю, что ваше предложение по № 784 на сегодняшний день является наиболее полным для нашей платформы. Если это предложение не будет реализовано, мне покажется, что это подходящая функция V2 NumberBox в качестве запасного варианта.

Мы уже планируем выпустить V2 одновременно с WinUI 3.0 или вскоре после него, поскольку два наиболее востребованных режима проверки ввода для NumberBox заблокированы при необходимости WinUI 3.0. Так что я открою выпуск V2 после того, как V1 выйдет в эфир, и я постараюсь также отметить это там.

Чтобы быть самодокументированным среди всех других свойств здесь, мы рассматриваем что-то вроде «SpinButtonStep», если это рассуждение будет достаточным оправданием для отклонения

Я вижу, что StepFrequency - это то, что использует Slider, поэтому я думаю, что мы пытались соответствовать этой терминологии. Не забывайте, что это касается не только кнопок вращения, но и значений изменения перетаскивания и поставщика UIAutomation.

@robloo и @mdtauk , я должен был прочитать дальше в теме, прежде чем отвечать по поводу °. Я не верю, что в настоящее время поддерживается отображение этого символа внутри Text поскольку NumberBox поддерживает синхронизацию Text и Value чтобы вы, как разработчики, могли захватить какой тип вам нужен, без накладных расходов на преобразование. Я не видел способа добиться этого с помощью доступных свойств форматирования, но если вы знаете способ, дайте мне знать!

Сейчас мы вплотную подошли к выпуску V1, но для V2 мы снова рассмотрим префикс / количество / специальные символы. Между тем , я считаю, @mdtauk для # 784 является наиболее полным решением, которое было выдвинуто для платформы до сих пор. Пожалуйста, отметьте это предложение большим пальцем и прокомментируйте, если это функция, которая вам нужна.

@adrientetar , прокрутка для изменения появилась в версии V1, но перетаскивание для изменения было отложено до версии V2. Поскольку мы все еще стремимся реализовать эти функции, мы еще не обсудили ваш запрос о том, что шаг Shift + Up / Down в единицах 10 и Ctrl + Shift + Up / Down шаг в единицах 100.

Не могли бы вы подробнее рассказать о сценариях, в которых вы будете использовать эту функцию? Как ваши пользователи узнают, что это доступно? Можете ли вы помочь мне понять, почему это должно быть по умолчанию (или, по крайней мере, доступно) во всех NumberBoxes по сравнению с тем, что реализовано локально в вашем решении?

@SavoySchuler

Большое спасибо за ваши комментарии.

Чтобы быть самодокументированным среди всех других свойств здесь, мы рассматриваем что-то вроде «SpinButtonStep», если это рассуждение будет достаточным оправданием для отклонения

Мне очень нравится эта терминология, но я пропустил, что у Slider уже есть свойство StepFrequency. В этом случае нет смысла отклоняться от соглашения, как заявил @jevansaks .

Округление осуществляется посредством форматирования. Вот пример свойства округления, которое можно установить для DecimalFormatter.

Допустим, пользователь вводит «1/3» в NumberBox. Тогда правильна ли следующая последовательность:

• При потере фокуса / вводе выражение будет оценено и будет вычислено двойное значение 0,33333333 ... 34
• 0.33333333 ... 34 будет передано в DecimalFormatter.
• 0,33333333 ... 34, в зависимости от ваших настроек, можно округлить до «0,30» (на всякий случай).
• Затем это значение «0,30» будет помещено в текстовое поле для отображения пользователю.
• Двойное значение Value теперь равно {0,33333333 ... 34}, а значение Text теперь равно "0,30".
• Чтение двойного Value НЕ вернет округленное число, которое отображается в Text
  (Или значение в десятичном формате каким-то образом снова анализируется после преобразования в строку? А затем все это переоценивается?)

Я также обеспокоен тем, что свойства Value и Text так тесно связаны внутри. Документация не определяет эту связь, и если она не сильно структурирована, двусторонние зависимости никогда не будут забавными.

Я еще не уверен, как это реализовано внутри, но кажется, что правильный способ сделать это - рассматривать двойное значение как единственное реальное свойство. Текст - это просто отформатированная версия Value. Тогда разработчик сможет отформатировать значение, как бы он ни хотел, чтобы оно отображалось в TextBox и свойстве Text (мы получим символ градуса или ранее запрошенные символы футов / дюймов). Это будет совсем несложно, если все уже внутренне управляется свойством Value. Текстовый ввод от пользователя в любом случае не сохраняется и будет использоваться только для пересчета значения, которое затем снова форматируется для отображения.

Последовательность должна быть:

• Пользовательский текстовый ввод -> Парсер -> Двойное значение -> Форматирование -> Текст

Изменение значения Text из кода будет таким, как если бы пользователь ввел какой-то текст. Для прямого изменения значения достаточно пройти этапы «Форматирование» и «Текст».

Чтобы сохранить точность округления между значением и текстом, последовательность будет больше похожа на:

• Пользовательский текстовый ввод -> Парсер -> Значение -> Округление -> Значение -> Форматирование -> Текст

Изменить: чтобы реализовать округление в анализаторе выражений / входных данных и механизме оценки (как бы он ни назывался), вам, вероятно, потребуется добавить новое свойство для определения алгоритма, такого как RoundingAlgorithm . Это перечисление уже определено в Windows.Globalization.NumberFormatting, как вы указали. INumberFormatter2 следует использовать для форматирования и ничего больше - снова держите этапы разделенными между вычислением и, наконец, отображаемым текстом.

@adrientetar , прокрутка для изменения появилась в версии V1, но перетаскивание для изменения было отложено до версии V2. Поскольку мы все еще стремимся реализовать эти функции, мы еще не обсудили ваш запрос о том, что шаг Shift + Up / Down в единицах 10 и Ctrl + Shift + Up / Down шаг в единицах 100.

Не могли бы вы подробнее рассказать о сценариях, в которых вы будете использовать эту функцию? Как ваши пользователи узнают, что это доступно? Можете ли вы помочь мне понять, почему это должно быть по умолчанию (или, по крайней мере, доступно) во всех NumberBoxes по сравнению с тем, что реализовано локально в вашем решении?

Одно должно быть больше, а другое должно быть меньше - аналогично смещению выбранных областей / объектов в приложениях Adobe.

Не могли бы вы подробнее рассказать о сценариях, в которых вы будете использовать эту функцию?

Это здорово, когда вы хотите изменить значение с визуальными эффектами (например, поворот объекта), но вы не знаете, как далеко вы хотите зайти. Так что это хорошо для визуального дизайна.

Как ваши пользователи узнают, что это доступно?

Это просто функция, которую имеют современные инструменты, например Adobe XD, Framer ...

Можете ли вы помочь мне понять, почему это должно быть по умолчанию (или, по крайней мере, доступно) во всех NumberBoxes по сравнению с тем, что реализовано локально в вашем решении?

Я думаю, что это хорошо иметь это, когда вы работаете на сенсорном устройстве, это удобный способ, касание-перетаскивание, чтобы настроить заданное значение (вроде как виджет выбора времени телефона, где вы нажимаете и перетаскиваете для прокрутки значений).

Одно должно быть больше, а другое должно быть меньше - аналогично смещению выбранных областей / объектов в приложениях Adobe.

RangeBase имеет свойства SmallChange и LargeChange. Мы в BeLight Software в нашей версии NumericUpDown производим от RangeBase и меняем значение с помощью SmallChange с помощью ярлыков ArrowUp и ArrowDown, а также с помощью LargeChange с помощью ярлыков PageUp и PageDown.

И мы здесь не одни,
https://help.syncfusion.com/uwp/numeric-updown/gestures
https://docs.telerik.com/devtools/wpf/controls/radnumericupdown/features/navigation

Только одно замечание относительно цифровой клавиатуры, которое пришло мне в голову во время разговора с сообществом ...

В большинстве приложений значок "." кнопка клавиатуры по-прежнему отображается на "." символ, который отличается от десятичного разделителя при использовании неанглийского языка (например, "," на французском языке). Поэтому, когда вы нажимаете "." клавишу в блокноте, он пишет "." characther.

Некоторые приложения (наиболее известным из которых является Excel) изменяют это поведение клавиш, чтобы переинтерпретировать любое нажатие клавиш на клавиатуре "." как входной десятичный разделитель. Он более совместим с «калькуляторным» дизайном клавиатуры.

Приложение "Калькулятор" также переписывает "." нажмите, чтобы интерпретировать его как десятичный разделитель.

Поскольку числовому окну будет разрешено работать больше как «калькулятор», может ли элемент управления разрешить использование «.» клавиша на клавиатуре в качестве десятичного разделителя? Или, по крайней мере, предоставить разработчику возможность добавить эту функцию без необходимости бороться с ключевыми фильтрами и событиями?

Возможно, свойство может позволить включить (если включено) или отключить (если отказаться) эту функцию. Например, KeyPadDotAsDecimalSeparator="false" ?

Предложение V2 NumberBox: https://github.com/microsoft/microsoft-ui-xaml/issues/1736

Привет, замечательное сообщество WinUI! Искренне благодарим вас за то, что помогли нам довести до релиза наш первый предложенный сообществом элемент управления. Мы знаем, что это была огромная задача, и что все вы потратили значительное количество времени на создание лучшей коллекции функций V1, которую мы могли бы разработать вместе.

Мы также знаем, что не все вошло в выпуск V1. Некоторые очень желательные конфигурации проверки ввода зависят от работы функций WinUI 3.0, некоторые желаемые функции должны появиться на поздних этапах проверки / приложения, а некоторые функции, которые, как мы знали, будут лучше изучены после выпуска V1.

Мы планируем завершить работу над запланированной функцией NumberBox с выпуском WinUI 3. Я открыл проблему для сбора отзывов о необходимых функциях, которые отсутствуют в V1. Если в NumberBox не хватает чего-то, что вам нужно, обязательно оставьте комментарий здесь: https://github.com/microsoft/microsoft-ui-xaml/issues/1736