시작점으로 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}"

ArchieCoder 에 2019년 03월 25일

👍3

또한 이것이 올바르게 현지화되었는지 확인하십시오. Windows Community Toolkit 구현에는 다음과 같은 몇 가지 단점이 있습니다.

ValidationType="Decimal"인 TextBoxRegex 확장은 모든 UI 문화권을 지원하지 않습니다. 대신 InvariantCulture로 고정됩니다. 영어에서 십진수 값은 마침표가 있는 "10.1234"입니다. 스페인어 또는 독일어 십진수 값은 "10,1234"로 표기됩니다. 영어 구문 분석이 정확할 것입니다. 그러나 스페인어 또는 독일어 사용자 입력은 분수 부분이 손실된 "101234"입니다.

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

robloo 에 2019년 05월 02일

👍8

위쪽 및 아래쪽 화살표는 개발자가 설정할 수 있는 값만큼 값을 증가 또는 감소시켜야 하지만 기본값은 int 1이어야 합니다.

mdtauk 에 2019년 05월 02일

👍4

예를 들어 각도를 선택하는 경우 랩 어라운드 최소/최대 값이 좋습니다.
접미사 추가 기능
텍스트 상자를 클릭하고 위/아래로 드래그하여 값을 변경합니다. Adobe XD는 숫자 입력에 이것을 가지고 있습니다.

adrientetar 에 2019년 05월 10일

👍5

WinRT XAML Toolkit의 구현도 값을 변경하기 위해 위/아래로 드래그를 지원하며 특정 시나리오에서 버튼을 클릭하는 것보다 마우스로 사용할 때 훨씬 더 유용합니다.
https://github.com/xyzzer/WinRTXamlToolkit/tree/master/WinRTXamlToolkit/Controls/NumericUpDown

xyzzer 에 2019년 05월 13일

👍3

안녕하세요, @sonnemaf , @ArchieCoder , @robloo , @mdtauk , @adrientetar , 그리고 @xyzzer입니다! 저는 이 제안에 배정되었습니다.

먼저 제출해 주신 @sonnemaf 님께 감사드립니다. 지난주 마이크로소프트 빌드 2019에서 선보였는데 관객들의 환호를 받았습니다! 댓글의 커뮤니티 반응은 또한 NumberBox가 일어나는 것을 보고 싶어하는 흥분을 반영합니다.

나는 모든 사람의 의견을 읽고 받은 입력을 반영하도록 범위 섹션을 업데이트했습니다. 모든 사람 이 이 작은 업데이트를 확인하고 내가 요청을 정확하게 캡처하지 못했다면 알려 주시면 감사하겠습니다. 일부 세부정보(예: 현지화 형식 지정)는 사양 수준에서 처리됩니다.

SavoySchuler 에 2019년 05월 16일

안녕하세요 @SavoySchuler 님 ,

이번 주에는 앱의 접근성 기능을 작업 중입니다. 예를 들어 "플러스", "마이너스" 대신 증분을 큰 소리로 말할 수 있는 새 컨트롤로 접근성이 올바르게 처리된다면 이것은 플러스가 될 것입니다. 나머지는 나에게 좋은 것 같습니다.

ArchieCoder 에 2019년 05월 17일

👍3

내레이터가 값을 올바르게 읽을 수 있는지 확인하여 무슨 일이 일어나고 있는지 명확하게 하는 것이 중요합니다.

Xbox 컨트롤러가 아날로그 스틱과 D-Pad가 올바르게 작동하도록 하기 위해 초점을 두드려야 하는지 확실하지 않습니다.

mdtauk 에 2019년 05월 17일

👍2

작은 수정 - 활성화될 때까지 텍스트 필드 자체에서 증가/감소 드래그가 작동해야 합니다. 내 구현에서 IIRC를 활성화하고 드래그하는 동안 마우스 커서를 숨겨서 컨트롤이나 화면의 테두리가 드래그 거리를 제한하지 않고 드래그가 완료되면 텍스트 필드 위에 투명 오버레이를 넣어야 했습니다. 커서를 다시 표시합니다. 커서가 처음 사라진 위치에 나타납니다.

xyzzer 에 2019년 05월 17일

👍1

@SavoySchuler 수고 하셨습니다. 나는 당신의 범위와 함께 살 수 있습니다. 계산기는 있으면 좋습니다(WinUI 3.0 또는 3.1). 저는 많은 데스크탑 환경(VB6, WinForms, WPF 및 UWP)에서 개발했으며 항상 NumberBox를 놓쳤습니다. 마침내 우리는 그것을 얻을 것입니다.

위/아래로 마우스 스크롤 휠을 추가할 수도 있습니다. Blend for Visual Studio는 이를 지원합니다.

또한 Expression Blend에서 많이 사용했던 Drag-to-change도 좋아합니다.

어떤 입력 유효성 검사가 수행되고 수행되지 않을지 잘 모르겠습니다. 최소/최대 또는 제한 키보드(문자 az 등)만 됩니까? 잘못된 숫자 붙여넣기를 처리합니까?

전체 사양을 읽고 싶습니다.

sonnemaf 에 2019년 05월 17일

👍3

@ArchieCoder , 크고

@mdtauk , 언제나처럼 훌륭한 질문입니다. 나는 이것을 조사하기 위한 메모로 접근성 및 입력 섹션에 추가했습니다.

@xyzzer님 말씀이 맞습니다. 범위 목록을 재구성할 때 관련 기능으로 Up/Down 버튼과 drag-to-change를 그룹화했습니다. 다시 읽으면 마치 드래그하여 변경이 버튼의 기능이라고 제안하는 것처럼 나타났습니다. 명확성을 제공하기 위해 드래그-투-체인지를 자체 섹션으로 옮겼습니다.

@sonnemaf , 굉장합니다. 사양에 대한 링크는 오늘이나 다음 주에 열리면 바로 게시하겠습니다. 저와 함께 글을 쓰도록 격려해주세요! 그때까지는 여기에서 범위에 스크롤하여 변경하는 기능을 추가했습니다.

모두 , 계산기 지원에 대한 메모와 함께 - 나는 가치를 믿습니다. 저는 우리 팀과 협력하여 플랫폼에서 기능을 추가로 활용할 수 있는 경우 모듈화해야 하는 항목인지 파악하고 있습니다. 또한 계산기 지원을 어디까지 할 수 있는지에 대한 질문이 있습니다. +-/*에 대한 간단한 작업 순서가 수행됩니까? 아니면 일종의 Wolfram 알파 서비스에 연결하는 것과 같은 보다 포괄적인 것입니까? 모듈식 경로를 탐색하면 더 포괄적인 형태의 계산기 지원 기회를 차단하지 않으면서 더 기본적인 경우부터 시작할 수 있습니다. 여기 모든 사람의 요구 사항을 알고 싶습니다.

입력 유효성 검사의 경우 동일한 질문이 있습니다. 최소, 최대, 문자 없음 및 잘못된 붙여넣기가 적용되지 않습니까?

SavoySchuler 에 2019년 05월 17일

❤1

나는 계산기 기능이 귀엽다고 생각하지만 실제로 이 기능을 사용자가 어떻게 발견합니까? 이에 대한 약간의 위젯 힌트가 있습니까?

ArchieCoder 에 2019년 05월 17일

@ArchieCoder ,

개발자에게 의존하도록 요청할 수 있는 앱 수준의 지침을 위한 ToolTip 또는 더 무거운 TeachingTip이 있지만 저는 NumberBox 자체 내에서 이 문제를 해결하는 것이 가장 좋습니다.

여기에서 당신의 생각을 듣고 싶습니다!

SavoySchuler 에 2019년 05월 17일

👍1

공간 제한으로 인해 다른 컨텍스트가 필요하지 않은 한 자리 표시자는 실제로 좋은 방법입니다. 예를 들어 NumberBox 너비가 텍스트 상자보다 작을 것이라고 생각합니다.

ArchieCoder 에 2019년 05월 17일

👍1

컨트롤이 nullable 숫자를 지원하지 않는 한 - 항상 값을 표시합니다.
따라서 그 안에 자리 표시자 문자열을 위한 공간이 없습니다.

2019년 5월 17일 금요일 오전 10시 14분 ArchieCoder [email protected]
썼다:

다른 컨텍스트가 아닌 한 자리 표시자는 실제로 좋은 방법입니다.
공간 제약으로 인해 필요합니다. NumberBox 너비가
예를 들어 텍스트 상자보다 작아야 합니다.
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMAL7LUOVPIM55PYO4LPV3RWPA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AANMBMBKHP7GP5WUHLPWNZLPV3RWPANCNFSM4HA4PBNA
.

xyzzer 에 2019년 05월 17일

👍2

@ArchieCoder , @sonnemaf 의 예를 보면(다시 한 번 감사합니다) "a + b - c"에 대한 자리 표시자 텍스트를 표시할 만큼 충분히 넓지 않은 NumberBox도 권장 사용자 경험을 생성하기에 충분히 넓지 않습니다. 에 방정식을 입력합니다. 그런 점에서 이 솔루션 옵션이 이 목적에 여전히 실행 가능하다고 생각합니다. 그러나 나는 당신이 우리가 아직 다루지 않은 영역을 두드리고 있다고 생각합니다. 즉, 컴팩트한 NumberBox/간단한 숫자만 입력하기를 원하는 시나리오입니다. 나는 계산기 지원이 그것을 비활성화하기 위한 API가 필요하다고 생각합니다. 이 경우 긴 자리 표시자 텍스트에 대해 걱정하거나 최소 공간 제약을 깨는 데 신경 쓸 필요가 없습니다. , "#" 또는 "예: 2"와 같은 경우에도 마찬가지입니다.

@xyzzer , 이 문제를 제기해 주셔서 감사합니다. 이것이 올바른 사용자 경험인지 먼저 확인하고 거기에서 구현을 파악할 수 있습니다! 완화할 수 있는 기술적 제한으로 인해 _right_ 사용자 경험에 대한 검색을 제한할 필요가 없습니다. :편안함:

SavoySchuler 에 2019년 05월 17일

모두에게 더 높은 우선순위 질문이 있습니다.

표준 TextBox와 독립적으로 이러한 기능을 통합하는 NumberBox 컨트롤을 사용하시겠습니까, 아니면 API 또는 InputScope를 통해 활성화할 수 있는 기본 기능으로 이러한 기능을 TextBox에 굽고 싶으십니까?

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

SavoySchuler 에 2019년 05월 18일

이 모든 것을 TextBox 컨트롤에 넣는 것은 중요한 변화입니다.

입력한 문자에 대한 유효성 검사입니다.

InputScope와 함께 올바른 키보드 레이아웃 사용

다양한 마우스 동작.

FabricWeb 버전에서와 같이 스피너 버튼을 표시하는 기능.

현재 앱에서 TextBox를 사용하는 다른 모든 사람에게 영향을 주지 않고 TextBox 유형을 정의하는 동작 열거형과 함께 이러한 모든 것을 추가할 수 있다면 좋습니다.

그리고 버튼처럼 작동하는 검색이나 달력을 나타낼 수 있는 아이콘과 같은 다른 TextBox 동작을 결합하는 것을 고려할 수도 있습니다. 옆에 있는 텍스트에 입력할 때 자리 표시자 텍스트 스타일로 "http://"를 표시하는 IP 주소 또는 URL과 같은 항목에 대한 마스크입니다.

FabricWeb은 TextFields와 함께 매우 다양합니다.

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

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

mdtauk 에 2019년 05월 18일

👍2

이러한 모든 기능을 TextBox 컨트롤에 굽는 대신 고유한 NumberBox 컨트롤을 사용하겠습니다(입력 모드 "비밀번호"가 있는 TextBox가 아닌 PasswordBox 컨트롤도 있는 것과 유사).

NumberBox 컨트롤은 예를 들어 IP 주소에 대한 단순한 입력 필드 그 이상입니다. 고유한 접근성/고유한 스크롤 및 끌기 기능, 계산기 지원 등이 제공됩니다. 이 모든 것이 지금까지 일반적으로 TextBox를 사용했던 방식과 상당히 구별됩니다(그룹의 표현 이름을 지정하는 것처럼 간단한 경우). 데이터). 그리고 NumberBox 컨트롤에 대해 더 많은 특수 기능/요구 사항이 제안됨에 따라 NumberBox와 TextBox를 훌륭하고 깔끔하게 분리할 수 있습니다.

해당 창은 문서 및 앱 xaml 레이아웃에도 표시됩니다(예: 입력 모드를 지정하는 속성 중 하나가 포함된 여러 속성이 있는 TextBox보다 NumberBox를 더 쉽게 감지할 수 있음). 숫자 입력 기능에 대한 TextBox 문서를 읽는 대신 해당 부분은 특정 NumberBox 제어 문서(오늘날 PasswordBox와 마찬가지로)에서 훌륭하고 깔끔합니다.

Felix-Dev 에 2019년 05월 18일

👍5

컨트롤의 모양과 관련하여 단위/접미사는 값 자체와 구별되도록 더 작은 크기/채도가 낮은 색상으로 옆에 표시될 수 있다고 생각합니다.

마우스가 컨트롤 위로 이동하면 위/아래 화살표가 장치 대신 페이드인될 수 있습니다.

대안은 figma.com의 숫자 컨트롤입니다. 장치 위로 마우스를 가져갈 때 클릭+왼쪽/오른쪽으로 끌어 값을 변경할 수 있습니다.

왼쪽/오른쪽은 위/아래보다 마우스를 왼쪽/오른쪽으로 움직이는 것이 더 쉽기 때문에 흥미롭습니다(손목을 들 필요가 없습니다).

다른 것들:

초점이 맞지 않는 텍스트 영역을 클릭하면 모든 내용이 선택되어야 합니다. 클릭+값 입력+Enter가 값을 변경하도록
Shift+화살표를 클릭하거나 Shift+위/아래로 초점을 맞추면 10씩 증가하거나 감소합니다(해당 값도 사용자 정의할 수 있어야 한다고 생각합니다).
위/아래 화살표가 사용자에게 그다지 유용하지 않다고 생각합니다. 사용자가 정확한 값을 원하면 입력하기만 하면 되고, 원하는 값이 무엇인지 확실하지 않은 경우 클릭+드래그로 값 변경 범위를 시각화할 수 있습니다. 따라서 위/아래 화살표는 최소한 선택 사항이어야 합니다.

adrientetar 에 2019년 05월 18일

👍2

@adrientetar 컨트롤 내부에 단위 표시를 넣으면 추가 문제가 많이 발생합니다.

현지화
접근성
선택
붙여넣기
전환

헤더, 설명 또는 별도의 TextBlock에 이것을 넣으면 모두 피할 수 있습니다.

mrlacey 에 2019년 05월 19일

Value 속성이 있는 별도의 NumberBox 컨트롤을 사용하고 Text 속성이 아닐 수도 있습니다. Value는 Double이어야 데이터 바인딩(x:Bind)할 수 있습니다. Decimal 데이터 유형도 지원해야 하는지, 어떻게 지원해야 하는지 잘 모르겠습니다.

sonnemaf 에 2019년 05월 20일

👍2

nullable 숫자에 대한 지원은 내가 생각하는 MUST입니다(@xyzzer에게 감사드립니다). Value 속성은 Nullable이어야 합니다.데이터 형식. nullable이 아닌 값에 바인딩할 때 바인딩 문제가 발생하는지 잘 모르겠습니다.

sonnemaf 에 2019년 05월 20일

👍2

구성에는 이점이 있고 번호 매기기에 대한 첨부된 동작이 있는 반면
모드를 구현하고 TextBox에 첨부할 수 있습니다.
불필요하게 복잡하고 제한적입니다.
구현과 관련하여 부딪힐 수 있는 가장 큰 문제 중 일부는
접근성. 일부 접근성 패턴을 지원한다고 생각합니다.
특정 인터페이스를 TextBox에 구현해야 합니다.
TextBox가 숫자 상자 모드에 있지 않으면 혼란스러울 수 있습니다.

2019년 5월 20일 월요일 오전 2:33 Fons Sonnemans [email protected]
썼다:

nullable 숫자에 대한 지원은 내가 생각하는 필수 사항입니다(@xyzzer에게 감사드립니다.
https://github.com/xyzzer ). Value 속성은 Nullable이어야 합니다.
데이터 형식. 바인딩할 때 바인딩 문제가 발생하는지 확실하지 않습니다.
nullable이 아닌 값.
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMBGVQ36CDPQO6CWKLPWJV55A5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREWSG43VMVBWJ63
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AANMBMBTHT2UXOAGRTEDF7LPWJV55ANCNFSM4HA4PBNA
.

xyzzer 에 2019년 05월 20일

👍2

모두에게 질문이 하나 더 있습니다. 입력 유효성 검사 또는 마스킹이 필요/선호합니까?

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

SavoySchuler 에 2019년 05월 21일

문자열에 숫자를 추가할 수 없으므로 유효성 검사가 필수적입니다. 그리고 수학 연산자를 평가하고 처리해야 합니다.

계산할 수 없는 경우 표시되는 오류 메시지가 필요합니까? 확신할 수 없습니다.

마스킹은 유용하지만 URL 및 이메일 입력을 처리할 수 있도록 텍스트 상자 자체에 내장되어야 합니다. NumberBox는 전화번호, IP 등이 될 것입니다.

mdtauk 에 2019년 05월 21일

👍2

전화번호나 IP에 NumberBox를 사용해서는 안 된다고 생각합니다. 이것은 TextBox에 대한 간단한 마스킹/필터링 확장과 비슷합니다. NumberBox는 단일 값을 입력하는 데 사용하려는 것입니다.
아마도 통화 상자 컨트롤을 가질 가능성이 있지만 TB 또는 NB와 다른 별도의 컨트롤이 되어야 한다고 생각합니다.

xyzzer 에 2019년 05월 21일

@xyzzer 모든 종류의 숫자 입력에 대해 NumberBox를 더 유연하게 만드는 것은 좋은 생각인 것 같습니다. TextBox 컨트롤에서 파생될 수 있으며 해당 컨트롤에는 Mask 속성과 기타 동작 속성이 있을 수 있습니다.

NumberBox의 속성 중 일부는 다음과 같습니다.

스피너 버튼 표시/숨기기
값의 증가 및 감소 허용
값 계산 허용
마스킹된 입력 허용
전화번호 또는 IP 주소와 같은 현지화된 마스크

TextBox에 추가할 수 있는 속성은 다음과 같습니다.

Mask 속성 - 사용자 지정 형식([email protected])과 우편/우편 번호와 같은 지역화된 마스크를 정의하는 XAML 문자열
접두사/접미사 텍스트 표시(예: 접두사로 _http://_)
작업 버튼 표시/숨기기 - 아이콘 및 클릭 이벤트 속성 포함
아이콘(Fabric UI 검색 상자는 왼쪽에 아이콘을 표시하고 상자에 포커스가 있을 때 애니메이션으로 표시됨)

이 이미지는 Fabric UI TextField의 이미지이며 이 모든 다양한 상태를 지원합니다. 가능한 경우 Fluent WinUI 3.0 컨트롤을 패리티로 가져오는 것을 목표로 해야 합니다.

Fabric UI Spinner 버튼은 터치하기에는 너무 작기 때문에 위아래 버튼이 서로 겹쳐지지 않고 나란히 있도록 형식을 다르게 지정합니다.

mdtauk 에 2019년 05월 21일

👍3

나에게 유효성 검사는 필수이며 마스킹은 있으면 좋습니다. 나는 마스킹을 좋아하지 않았다. 너무 딱딱합니다.

sonnemaf 에 2019년 05월 21일

👍2

@rudyhuyn 은 Windows 계산기 저장소에서 좋은 기능을 제안했습니다. @mdtauk이(가) 댓글 을

날짜/시간/달력 선택기와 유사한 NumberBox에서 계산기 팝업을 열 수 있습니다.

sonnemaf 에 2019년 05월 21일

👍2

@xyzzer 가 위에서 말한 것과 유사합니다. 숫자와 일련의 숫자를 포함하는 문자열 사이에는 근본적인 차이가 있습니다.
설명된 차이점을 가장 잘 들은 것은 숫자에 대해 곱셈과 나눗셈 연산을 수행할 수 있다는 것입니다. 숫자의 절반을 요청하고 2로 나눌 수 있습니다. 우편 번호의 절반이나 "전화 번호"를 요구하고 의미있는 것을 얻을 수는 없습니다.

숫자로 구성된 다른 값을 캡처하는 기능과 수학적 기능이 있는 특정 NumberBox 를 혼합하면 다른 문제도 발생할 수 있습니다.
"전화 번호"는 선행 0(또는 더하기 기호)으로 시작할 수 있으며 거기에 의미가 있습니다. _숫자_의 경우에는 제거되지 않으며 제거됩니다.
"전화 번호"는 종종 대괄호와 하이픈으로 형식이 지정됩니다. 수학적 연산으로 처리되면 곱셈과 뺄셈이 필요한 것으로 쉽게 해석될 수 있습니다.

TextBox 와 같은 방식으로 마스킹을 허용하고 입력 형식을 지정하면 NumberBox 와 TextBox 와 각각을 사용해야 하는 시기에 혼동을 일으킬 위험이 있습니다.

간단한 유효성 검사는 필수 사항이지만 유효성 검사가 플랫폼에 올 때 충돌하는 유효성 검사 방법이 있거나 개발자가 유효성 검사를 여러 위치로 퍼뜨리도록 쉽게 끝낼 수 있는 방법이 발생하지 않도록 주의해야 합니다. .

다음 속성을 기반으로 유효성 검사를 유지합니다.

최대값
최소값
AllowDecimalPlaces

별도로 표시해야 합니다.

계산의 잘못된 출력
입력/붙여넣기/계산된 값을 처리하는 방법과 바인딩에 사용되는 항목. 유효하지 않음을 나타내기 위해 계산 또는 유효하지 않은 값을 표시할 필요가 있지만 이는 지원 속성에 전달할 수 없습니다.

mrlacey 에 2019년 05월 21일

👍2

마스크는 필요한 것을 명확히 하기 위해 시각적 어포던스가 필요하지만 기본 계산 입력은 마스크된 입력과 함께 사용되지 않습니다.

Fabric 웹 텍스트 컨트롤은 이를 잘 처리하는 것처럼 보이지만 물론 NumberBox의 범위는 기본 TextBox 컨트롤에 대한 일반적인 맞춤 및 마무리 개선 사항과 별개입니다.

스피너 버튼(및 옵션인 계산기 플라이아웃)은 NumberBox와 관련된 유일한 시각적 요소입니다.

속성의 경우 값 변경을 위해 키보드 위/아래 버튼이 활성화되어 있는 경우 키를 누를 때 증가 또는 감소할 정도를 선택할 수 있도록 단계 값이 포함될 수 있습니다.

mdtauk 에 2019년 05월 21일

👍1

@mdtauk , 나는 Step 값을 좋아하지만 키 누름뿐만 아니라. 스크롤 및 위/아래 버튼에도 있습니다.

sonnemaf 에 2019년 05월 21일

👍1

@sonnemaf 물론, Step은 마우스 휠 틱, 키 누름 또는 키 다운과 같은 바이너리에 좋습니다. 아마도 상자에서 멀어지는 거리가 단계 양을 증가시킬 수 있습니까?

그래서 StepMinimum 과 StepMaximum은 아마도?

mdtauk 에 2019년 05월 21일

그래서 StepMinimum과 StepMaximum은 아마도?

나는 그 가치가 무엇과 관련이 있는지 또는 그것에 대해 무엇을 기대해야 하는지 전혀 모릅니다.
"Step"의 목적이 증분을 정의하는 것이라면 "Increment"라고 부릅니다.

이렇게 하면 Max:100 Min:0 Increment:10 에서 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100 값만 지정할 수 있습니다.

드래그한 거리에 따라 단계/증가량이 달라지면 예측할 수 없는 값 변경이 발생할 수 있습니다. 이 컨트롤의 목적이 숫자 값을 더 쉽게 지정할 수 있도록 하는 것이라면 값이 다양한 양으로 변경되기 시작하면 쉽게 만들 수 있는 전용 컨트롤을 갖는 기본 목표를 무찌르는 매우 실망스러울 것입니다.

mrlacey 에 2019년 05월 21일

@mrlacey 슬라이더 및 진행률 표시줄에 대해 명명된 속성이므로 Step을 사용하지만 원하는 경우 증분을 사용할 수 있습니다. 증가가 값의 증가와 혼동되지 않는 한 값은 오르락내리락합니다.

값을 높이거나 낮추기 위해 위 또는 아래로 클릭하고 드래그하는 제안이 있습니다. 사용자가 값이 더 빨리 변경되기를 기대하면 더 위 또는 아래로 드래그한 다음 Stap Min 및 Max 값이 있으면 개발자가 델타가 변경될 때 이를 제어할 수 있습니다. 따라서 작은 끌기 거리는 0.1 또는 1 씩 증가할 수 있지만 더 끌면 예를 들어 5 또는 10 씩 변할 수 있습니다.

드래그 거리가 값 변경 속도를 변경해야 한다고 말하는 것이 아닙니다. 단지 그것이 자연스럽게 느껴지고 사용자에게 자신감과 제어력을 제공한다면 도움이 될 수 있다는 아이디어일 뿐입니다.

mdtauk 에 2019년 05월 21일

👍1

멋진 피드백, 여러분! 세부 사항을 망치기 시작하기 위해 사양 및 PR 을 열었습니다.

@KevinTXY 가 이 컨트롤의 개발자로 저와 합류할 것입니다. 여기에서 요구 사항 대화를 계속 진행하고 PR에 대한 API/예제 특정 대화를 시작합니다.

사양 작성에 참여하도록 격려해 주십시오.

TeachingTip의 사양 은 완성된 사양이 어떻게 생겼는지에 대한 완전한 기능을 갖춘 예입니다. 주요 개요는 다음과 같습니다.

설명
모든 API/기능의 예
지침
API(IDL)

SavoySchuler 에 2019년 05월 29일

👍1

훌륭한 아이디어, 나는 이 모든 것이 어디로 가는지 좋아합니다. 내 두 센트 추가:

의심할 여지 없이 TextBox와 통합되는 대신 별도의 NumberBox여야 한다고 생각합니다. 또한 여기에서 설명하는 좋은 기능이 많이 있지만 NumberBox도 가볍게 유지해야 합니다. 따라서 저는 NumberBox에서 CalculatorBox 또는 이와 유사한 것을 파생할 것을 제안하며 고급 "2+3" 입력 또는 계산기를 여는 버튼을 가질 수 있습니다.
현지화는 사전에 사양에서 잘 생각해야 합니다. 또한 UI 로컬을 재정의하려는 경우가 있습니다. 따라서 NumberformatInfo 속성 또는 CultureInfo를 설정하는 것이 매우 유용할 수 있습니다. 예를 들어, 일부 애플리케이션에서는 외부 값과 로컬 값이 모두 추적됩니다. 각각은 잠재적으로 다른 형식일 수 있습니다.
컨트롤은 소수점 이하 자릿수 이동을 지원해야 합니다. 이것은 변경된 모든 텍스트의 형식을 단순히 검증하는 것보다 더 까다롭습니다. 각 문자 입력을 추적해야 하며 필요에 따라 이전 소수점 자리를 대체해야 합니다.
모든 증가/감소 화살표는 일반 입력 상자를 갖도록 끄도록 구성할 수 있어야 합니다. 다시 한 번 다른 컨트롤의 일부로 필요한 경우에 대해 경량 컨트롤이 필요합니다.
논의되지 않은 다른 것은 우리가 여러 유형을 이상적으로 지원해야 한다는 것입니다. Decimal, Integer 및 잠재적으로 Long, Double 등... 이것은 근본적으로 많은 것을 변경할 수 있으며 아직 완전히 생각하지 못했습니다. .
값은 반드시 nullable이어야 합니다. 설정되지 않은 값은 0과 다릅니다.
중요하지 않은 또 다른 아이디어는 decimal, double 또는 float 유형에 대해 소수 정밀도를 지정할 수 있도록 하는 것입니다.

더 많은 아이디어가 뒤따를 것이라고 확신합니다. 나는 사양을 읽기를 고대합니다!

robloo 에 2019년 05월 29일

👍1

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

나는 각각에 대한 API와 예제로 작성된 사양 / PR 을 가지고 있습니다. 기본 미리 정의된 유형(아직 진행 중)에 대한 열거형과 설정된 경우 미리 정의된 유형을 재정의하는 사용자 지정 서식 속성을 사용하여 사양에 맞게 서식 지정을 처리했다고 생각합니다.

확인해 보시고 문제가 해결되지 않거나 추가 또는 개선할 수 있는 사항이 있으면 알려주시기 바랍니다. 여기에서 요구하는 사양에 기여하는 풀 리퀘스트를 수락하겠습니다.

유효성 검사는 필수 항목으로 표시됩니다. 마스킹 및 기타 지원 속성을 무료로 얻기 위해 TextBox에서 파생되도록 이 컨트롤을 규정했습니다.
@mrlacey 의 우려로 사용자 지정 숫자 문자열 입력 시나리오를 활성화하기 위해 사용자 지정 형식 문자열과 함께 사용할 수 있는 선행 0 제거를 활성화/비활성화하는 API를 추가했습니다(국제 전화 번호 및 IP 주소는 이미 가능한 기본 형식 유형 목록에서).
이것은 계산기 지원을 활성화/비활성화하는 기능과 함께 숫자 값/문자열에 대해 경량일 수 있지만 충분한 계산 및 사용자 지정 지원을 제공할 수 있는 컨트롤에 대한 교차점을 제공합니다. 예제의 간결함이 이를 강조한다고 생각하지만 이것이 장래 제어를 사용하기 더 복잡하게 만들 것이라고 생각하는 사람의 의견을 듣고 싶습니다.
@sonnemaf 아이콘 > 팝업 계산기 예제의 참신함과 직관성에 감사드립니다. 나에게 이것은 CalendarDatePicker의 개념에서 예를 들어 파생되었으며 여기 모든 사람이 V1에 대해 고려해야 한다는 강력한 푸시가 없는 한 V2 기능에 대한 훌륭한 고려 사항이 될 수 있습니까?

SavoySchuler 에 2019년 05월 30일

계산기 오픈 소스 노력과 조정이 있는 경우 팝업 계산기가 의미가 있을 수 있습니다. 계산기 플라이아웃의 모양과 그 뒤에 있는 엔진의 일관성을 위해 둘 다.

mdtauk 에 2019년 05월 30일

👍1

여기가 이 이미지를 게시하는 곳인지 확실하지 않지만 사양을 준수하는 다양한 상태에 대한 디자인이 있습니다.

numberbox proposal
이미지는 200% 스케일입니다.

mdtauk 에 2019년 05월 30일

👍2 🎉1

@mdtauk 모형의 목적은 무엇입니까?

각 이미지는 어떤 상태를 보여주려고 합니까? 당신이 이것을 명확히 하지 않으면 우리는 당신과 다른 가정을 할 수 있습니다.

픽셀 완벽한 참조를 위한 것입니까?

이미지에서 플랫폼이나 기본 컨트롤의 기본값과 다른 부분을 호출하여 무엇을 추가하거나 변경하는지(있는 경우) 명확하게 할 수 있습니까?

mrlacey 에 2019년 05월 30일

@mrlacey 도움이 된다면 더 자세히 분석할 수 있을까요? 사양에서 언급된 몇 가지 예를 설명하려고 했습니다.

그 목적은 접두사, 접미사, 마스크, 위아래 버튼과 같이 제안된 다양한 컨트롤 요소로 이러한 컨트롤이 어떻게 보이는지 설명하는 것입니다. FabricWeb 컨트롤 디자인에서 추정되지만 FocusReveal과 같은 XAML 요소와 버튼의 컨트롤 크기 조정을 사용합니다.

예는 휴식 - 집중 - 비활성화 상태를 보여줍니다.

mdtauk 에 2019년 05월 30일

👍1

팝업 계산기는 V2에 좋은 기능이 될 것입니다.

제 의견을 어디에 올려야 할지 모르겠습니다. 사양에 대한 PR을 작성해야 합니까, 아니면 이 호에 계속 제 생각을 써도 됩니까?

정수

NumberBoxFormatType의 정수 값이 유용합니까?

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

언어

통화, 십진수 그룹화 기호를 지정하는 데 언어 를 사용하시겠습니까?

다음 예에서 언어는 nl-NL로 설정됩니다. 이것은 접두어가 유로 기호이고 소수점 기호 뒤에 2개의 소수점이 있는 쉼표이며 숫자 그룹이 점이라는 것을 의미합니까? 음수 통화는 미국과 같이 앞에 마이너스 기호가 있고 괄호가 없습니다.

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

Windows에는 많은 숫자 및 통화 형식 옵션이 있기 때문에 이 정도면 충분합니다.

가치 속성

Value 속성이 필요하고 어떤 (숫자) 유형이 필요합니까? 나는 그것을 데이터 바인딩하는 데 사용할 것입니다. double, decimal 또는 int여야 합니다. Nullable 지원(double?, decimal?, int?)이 필요합니다. 데이터 바인딩에 상속된 TextBox 컨트롤의 Text 속성을 사용하고 싶지 않습니다. Decimal에 대한 지원도 필요합니다. double로는 충분하지 않습니다.

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

직원의 Salary 속성이 Nullable인 경우(소수?). ValueNullableDecimal 종속성 속성이 필요합니까? DatePicker 컨트롤의 SelectedDate는 Nullable입니다.. Nullable은 특히 데이터 바인딩에서 문제입니다.

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

MinValue 및 MaxValue도 마찬가지입니다. 그들은 이제 사양에서 정수이지만 이것은 Double이 아니어야 합니까?

sonnemaf 에 2019년 05월 30일

👍1

@sonnemaf 사양에 따르면 컨트롤은 숫자를 입력할 수 있는 모든 것에 대한 것이므로 "값"을 텍스트로 취급하고 필요에 따라 변환하는 소비 코드에 의존해야 한다고 생각합니다. 이상적이지는 않지만 long 또는 float인 Value 속성이 있더라도 여전히 변환이 필요한 경우가 많습니다.
모든 숫자 유형에 대한 오버로드보다 낫습니다.
그런 다음 US 우편 번호, 전화 번호 또는 IP 주소와 같이 "숫자" 유형으로 변환할 수 없는 컨트롤이 디자인되고 있는 항목이 있습니다. 이러한 종류의 값의 경우 텍스트를 가져오는 것이 최상의(유일한) 옵션인 것 같습니다.
(최소한 초기 버전에서는 입력된 값에 액세스하고 필요한 경우 변환기에 의존하는 한 가지 방법을 사용하는 것이 더 간단하다고 생각합니다. 초기에 툴킷에 오는 도우미(또는 하위 클래스) 모음을 위한 장소를 볼 수 있습니다. 피드백을 기반으로 메인 컨트롤에 통합됩니다.

Language 속성이 필요합니까? 이것이 UILocale과 같지 않은 이유는 무엇입니까? 좋은 이유가 있을 수 있지만 이것은 사용자가 구성할 수 있어야 하며(OS 수준에서) 특정 형식을 지정할 수 있는 기능을 제공하면 형식이 다른 곳이나 사용자가 사용하는 것과 일치하지 않을 때 개발자에게 더 많은 문제가 발생할 수 있습니다. 응용 프로그램이 원하는. 내 머리 꼭대기에서: 누군가 다른 형식의 값을 붙여넣으면 어떻게 될까요?

mrlacey 에 2019년 05월 30일

👍1

@mdtauk 모형의 목적은 무엇입니까?
각 이미지는 어떤 상태를 보여주려고 합니까? 당신이 이것을 명확히 하지 않으면 우리는 당신과 다른 가정을 할 수 있습니다.
픽셀 완벽한 참조를 위한 것입니까?
이미지에서 플랫폼이나 기본 컨트롤의 기본값과 다른 부분을 호출하여 무엇을 추가하거나 변경하는지(있는 경우) 명확하게 할 수 있습니까?

@mrlacey 이것이 당신이 원했던 종류입니까?
numberbox comparison

mdtauk 에 2019년 05월 30일

👍2 🎉1

@mdtauk 당신이 보여주려는 것 중 일부를 설명하기 때문에 조금 더 좋습니다.

근본적인 질문은 여전히 남아 있습니다. 이것을 보여주는 목표는 무엇입니까? 그냥 아이디어인가요? 다양한 아이디어를 탐색한 후 선호하는 버전입니까? 그렇다면 왜 이것이 최고/선호입니까?

현재 컨트롤을 원하는 새 시스템 전체 스타일에 표시할 새 컨트롤과 비교한다는 것은 컨트롤에 특정한 것을 선호하는 새 시스템 전체 스타일에 있는 것과 분리할 수 없다는 것을 의미합니다.

예를 들어 테두리의 투명도를 변경하는 것을 언급합니다. 이 변경 사항은 모든 컨트롤을 위한 것입니까, 아니면 이 컨트롤에만 적용되는 것입니까? 그리고 어느 주에 있습니까?

버튼에 대해 명시적인 크기를 지정하는 것은 크기가 조정되는 컨테이너에 따라 항상 균등하게 변환되지 않기 때문에 디자인 구성 요소에서 문제가 될 수 있습니다. 항상 정사각형이어야 합니까? 또는 너비가 기본 컨트롤 높이에 따라 고정되어 있습니까?

접두사와 접미사에 대한 배경 브러시가 어떻게 결정됩니까? 기존 시스템 브러시를 사용한다고 가정하지만 어떤 브러시인가요?

마스킹은 이 사양에서 다루지 않습니다. "Masked" 예제가 형식 문자열과 관련되도록 의도되었습니까?
마스크 된 예제는 형식에 어떻게 대응합니까?
나는 당신이 버전 4 IP 주소의 항목을 보여주는 예라고 가정하지만 모든 것이 얼마나 깔끔하게 맞는지에 따라 거기에 많은 가정이 있는 것처럼 보입니다. 입력할 수 없는 모든 값에 배경과 여백이 있어야 합니까? 항상 표시되지 않으면 어떻게 합니까? 귀하의 예와 같이 사용 가능한 모든 공간에 맞게 콘텐츠를 늘려야 합니까? 사용 가능한 공간보다 넓은 콘텐츠를 패닝할 때 입력할 수 없는 값에 할당된 공간은 어떻게 처리됩니까?

mrlacey 에 2019년 05월 30일

@mdtauk 당신이 보여주려는 것 중 일부를 설명하기 때문에 조금 더 좋습니다.
근본적인 질문은 여전히 남아 있습니다. 이것을 보여주는 목표는 무엇입니까? 그냥 아이디어인가요? 다양한 아이디어를 탐색한 후 선호하는 버전입니까? 그렇다면 왜 이것이 최고/선호입니까?

현재 컨트롤을 원하는 새 시스템 전체 스타일에 표시할 새 컨트롤과 비교한다는 것은 컨트롤에 특정한 것을 선호하는 새 시스템 전체 스타일에 있는 것과 분리할 수 없다는 것을 의미합니다.

예를 들어 테두리의 투명도를 변경하는 것을 언급합니다. 이 변경 사항은 모든 컨트롤을 위한 것입니까, 아니면 이 컨트롤에만 적용되는 것입니까? 그리고 어느 주에 있습니까?

NumberBox 사양에는 시각적 예가 포함되어 있지 않으며 원본 제안서의 이미지는 기능에 대한 대략적인 예입니다. 컨트롤 템플릿이 2epx의 CornerRadius 값으로 업데이트되는 또 다른 PR #524가 있습니다. 이는 Fabric Web에서 사용하는 것과 동일한 반올림이기도 합니다.

따라서 TextBox 파생 컨트롤도 유사하게 업데이트될 것이라고 가정하고 이를 NumberBox의 제안된 기능이 여기에 어떻게 맞출 수 있는지 보여주기 위한 지침으로 사용했습니다. Fabric 웹 텍스트 필드는 이미 Prefix 및 Suffix 값을 지원하므로 해당 디자인을 선택하고 XAML 메트릭을 사용했습니다.

버튼에 대해 명시적인 크기를 지정하는 것은 크기가 조정되는 컨테이너에 따라 항상 균등하게 변환되지 않기 때문에 디자인 구성 요소에서 문제가 될 수 있습니다. 항상 정사각형이어야 합니까? 또는 너비가 기본 컨트롤 높이에 따라 고정되어 있습니까?
현재 TextBox에는 SearchBox, Password Reveal 버튼 및 Clear Text 버튼과 같은 통합 버튼이 있습니다. XAML용 터치 대상은 버튼을 32 x 32 epx로 제안합니다. 저는 버튼을 정사각형으로 유지하고 해당 지침을 사용했습니다.

접두사와 접미사에 대한 배경 브러시가 어떻게 결정됩니까? 기존 시스템 브러시를 사용한다고 가정하지만 어떤 브러시인가요?
내 예에서는 테마 전경색을 사용했지만 불투명도는 15%를 사용했습니다. FabricWeb은 10%에 가깝고 XAML 버튼은 20%를 사용합니다.
ListLowBrush와 같은 유사한 브러시 값이 있지만 새 TextBoxAppendixBackground 브러시가 필요할 수 있습니다. 텍스트 전경은 동일한 PlaceholderTextForeground 브러시를 사용합니다.

마스킹은 이 사양에서 다루지 않습니다. "Masked" 예제가 형식 문자열과 관련되도록 의도되었습니까?
마스크 된 예제는 형식에 어떻게 대응합니까?
나는 당신이 버전 4 IP 주소의 항목을 보여주는 예라고 가정하지만 모든 것이 얼마나 깔끔하게 맞는지에 따라 거기에 많은 가정이 있는 것처럼 보입니다. 입력할 수 없는 모든 값에 배경과 여백이 있어야 합니까? 항상 표시되지 않으면 어떻게 합니까? 귀하의 예와 같이 사용 가능한 모든 공간에 맞게 콘텐츠를 늘려야 합니까? 사용 가능한 공간보다 넓은 콘텐츠를 패닝할 때 입력할 수 없는 값에 할당된 공간은 어떻게 처리됩니까?

나는 이것에 대한 모든 답을 가지고 있는 척하지 않을 것이며, 그것이 컨트롤에 어떻게 가시적으로 표시되는지는 컨트롤에서 마스크 서식이 구현되는 방식으로 귀결됩니다.

IP v4 주소는 사양에 나와 있는 예제로 사용했으며 원래 의도는 제안된 내용을 설명하는 것이었습니다(접두사 및 접미사 예제가 부족하여 다른 값을 선택했지만).

다른 컨트롤이 마스킹을 처리하는 방법을 살펴보고 일부는 값이 입력될 때 캐럿을 이동하는 인라인 텍스트를 사용합니다. 다른 사람들은 전화번호를 입력할 때 대괄호와 하이픈과 같이 입력합니다. 일부는 탭 또는 화살표 키를 사용하여 세그먼트 사이를 이동합니다. 마음에 떠오르는 가장 가까운 Microsoft의 예는 Windows 설치 중에 제품 키를 입력하는 것입니다.

추가된 요소와 동일한 스타일을 사용하는 것이 미적 감각에 맞을 것이라고 생각했지만, 이것이 모든 것을 맞추기 위해 컨트롤의 길이를 추가하고 인라인이 공간을 더 잘 사용할 수 있다는 것을 알고 있습니다.

mdtauk 에 2019년 05월 30일

👍2 🎉1

지금 TextBox로 작업할 때 참고 사항입니다. https://doc.qt.io 와 유사하게 사용자가 값을 변경했음을 알리는 단일 이벤트가 없습니다(즉, 포커스를 잃은 것과 리턴 키를 눌렀을 때의 합집합).

adrientetar 에 2019년 05월 30일

@adrientetar NumberBox는 모든 입력이 숫자로 계산되기 때문에 이름으로 괜찮아 보입니다. IP 주소에는 전화번호, 통화, 측정치 등 4개의 숫자가 있습니다.

DigitBox, NumeralBox 등은 모두 Microsoft 명명 스타일에 맞지 않는 변형입니다.

값은 본질적으로 숫자일 필요가 없으므로 ValueBox도 약간 오해의 소지가 있습니다.

mdtauk 에 2019년 05월 30일

@sonnemaf 및 @mdtauk , 나는 내장 계산기 아이디어에 대해 팀과 이야기했으며 요컨대 우리는 그것을 좋아합니다. 과장이 아닙니다. 우리는 여러분 모두가 우리가 제공하는 컨트롤의 품질과 창의성을 이미 어떻게 향상시켰는지에 대해 더할 나위 없이 기쁩니다.

이렇게 하려면 당신의 도움이 필요합니다. 우리의 리포지토리를 통해 나오는 수많은 멋진 아이디어를 파악하는 방법은 아이디어 중심뿐만 아니라 시나리오 중심이기도 합니다. (이 언어를 사용하면 귀하의 기능 요청이 우리 리포지토리 전체에서 구체적인 영향력을 발휘할 수 있기 때문에 이것을 공유합니다.)

개발 중인 앱에 내장형 계산기에 대한 실제 시나리오를 제공할 수 있습니까? 컨텍스트, 스크린샷, 사용자 프로필이 모두 도움이 됩니다. (세부 사항을 기밀로 유지하려면 내 이메일도 내 GitHub 프로필에 있습니다.) @xyzzer , @mrlacey , @robloo , @Felix-Dev, @adrientetar 및 @ArchieCoder , 이 기능이 있으면 사용 시나리오를 공유하는 것이 좋습니다. 당신에게도 관심이 있습니다.

이 단계를 넘어 이 기능에 병목 현상을 일으킬 수 있는 유일한 것은 계산기 앱의 엔진으로 WinUI의 DLL 크기를 부풀릴 위험이 있다는 것입니다. 타당성을 확인하기 위해 병행하여 검토하겠습니다.

SavoySchuler 에 2019년 05월 30일

이전에 이 컨트롤을 단순한 숫자 유형 이상으로 취급 제기했습니다 .

숫자와 일련의 숫자를 포함하는 문자열 사이에는 근본적인 차이가 있습니다.

이것은 사양의 첫 번째 초안이 게시되기 전이었으므로 이 컨트롤이 "전통적인 숫자 값"과 "숫자 숫자를 포함하는 문자열"을 모두 처리하도록 고려하고 결정했다고 가정합니다.

나는 아무도 IPv4 주소가 형식화된 숫자 시퀀스보다 일반적으로 표현되지 않는 다른 정의에 의해 "숫자"였다고 주장하려고 시도하고 주장하지 않을 것이라고 생각합니다. 실제로는 4바이트 값에 불과합니다.

mrlacey 에 2019년 05월 30일

👍3

@SavoySchuler

비용 입력 - 일부 항목은 개인용이고 다른 항목은 작업의 일부인 영수증에서 해당 항목을 입력합니다.
청구서를 분할할 때 레스토랑 앱, 또는 팁 계산?
16진수 편집 앱, 선택 항목을 이동할 오프셋 값을 계산하려면?

mdtauk 에 2019년 05월 30일

👍1

IP 주소를 지원하는 컨트롤이 있으면 플랫폼에 큰 도움이 될 것이지만 NumberBox가 이 시나리오에 적합한 컨트롤이라고 생각하지 않습니다.

앞에서 언급했듯이 NumberBox 컨트롤은 다음을 수행합니다.

물리적 키보드가 없는 장치에서 사용할 때 Number 가상 키보드 사용
2개의 버튼이 있습니다 -/+
계산기로 팝업을 표시하거나 사용자가 기본 산술 연산을 입력할 수 있도록 합니다.

이러한 기능 중 어느 것도 IP 주소와 관련이 없습니다. 컨트롤의 디자인조차도 매우 다릅니다.

또한 IPv4 주소를 지원하는 경우 숫자가 아닌 16진수를 사용하여 IPv6 주소도 지원해야 합니다.

이 컨트롤에 IP 주소 지원을 포함하지 않고 UWP에 대한 새로운 MaskedTextBox 컨트롤(IPv4, IPv6, 전화 번호, 우편 번호, SSN 등 지원)을 작업하는 것이 더 합리적이라고 생각합니다 TextBoxMask 를 대체/개선하기 위한 풍부한 UI(@mdtauk가 시연)로

rudyhuyn 에 2019년 05월 30일

👍4

IP 주소를 지원하는 컨트롤이 있으면 플랫폼에 큰 도움이 될 것이지만 NumberBox가 이 시나리오에 적합한 컨트롤이라고 생각하지 않습니다.
앞에서 언급했듯이 NumberBox 컨트롤은 다음을 수행합니다.
물리적 키보드가 없는 장치에서 사용할 때 Number 가상 키보드 사용
2개의 버튼이 있습니다 -/+
계산기로 팝업을 표시하거나 사용자가 기본 산술 연산을 입력할 수 있도록 합니다.
이러한 기능 중 어느 것도 IP 주소와 관련이 없습니다. 컨트롤의 디자인조차도 매우 다릅니다.
또한 IPv4 주소를 지원하는 경우 숫자가 아닌 16진수를 사용하여 IPv6 주소도 지원해야 합니다.
이 컨트롤에 IP 주소 지원을 포함하지 않고 대신 UWP에 대한 새로운 MaskedTextBox 컨트롤(IPv4, IPv6, 전화 번호, 우편 번호, SSN 등 지원)을 작업하는 것이 더 합리적이라고 생각합니다 TextBoxMask 대체/개선

@rudyhuyn 나는 당신이 여기에서 말한 것에 대부분 동의하며 제 일러스트레이션은 제안된 사양을 위한 것입니다.

그러나 다른 사람들이 언급했듯이 Masked Text Box는 숫자에만 국한되지 않고 문자열도 포함할 수 있습니다. Microsoft 제품 키 상자는 5개 세트의 0-9 AZ 문자가 허용되는 좋은 예입니다.

Masking이 분리되더라도 여전히 NumberBox 컨트롤에 PrefixText 및 SuffixText 속성을 포함하는 좋은 사용 사례가 있다고 생각합니다. 통화, 측정, 모두 일종의 컨텍스트가 필요합니다.

회전 버튼은 순전히 값을 증가 및 감소시키기 위한 것이므로 이러한 값도 NumberBox 컨트롤의 범위 내에 있습니다.

접두사 및 접미사는 TextBox 컨트롤 자체의 속성이 될 수 있으므로 다른 컨트롤에서 상속됩니다. (취약점을 여는 경우 PasswordBox에 대한 예외가 필요할 수 있습니다.)

공통 값의 마스크는 이 분리된 컨트롤에 대한 열거형(CustomFormatMask와 함께)일 수 있습니다. 이러한 마스크 중 일부는 영국 우편번호가 영숫자이고 영국 국민 보험 번호가 특수 형식을 따르는 것과 같은 문화 컨텍스트를 포함할 수 있습니다.

SW1A 2AA

영국 우편번호 예(No. 10 Downing Street용)

mdtauk 에 2019년 05월 30일

답장을 보내기 전에 오늘 아침에 페이지를 새로고침하지 못한 것 같습니다... 이 제안을 완전히 새로운 차원으로 끌어 올린 모든 록스타 에게 감사합니다! GitHub에서 단어가 남용된다는 것을 알고 있지만 진심입니다!

@mdtauk - 당신의 목업은 환상적입니다. 나는 아직 이 컨트롤에 대한 프로토타입 디자인의 초안을 작성하지 않았습니다. 모형을 분해하여 디자이너가 팔레트를 시작하는 데 사용할 프로토타입으로 사양에 추가해도 될까요? 오늘 연락하여 디자이너를 요청하고 여기에서 @mrlacey 로 귀하의 스레드에 회신할 수

@sonnemaf , 다시 한 번 감사합니다! 귀하의 의견을 복사하여 여기 Pull Request의 대화 탭 에 다시 게시하는 것이 좋습니다. 여기에서 엔지니어링 팀이 API 및 구현 수준에 참여하기 시작할 것입니다. 포괄적인 답변을 제공하기 위해 여기에서 가이드라인과 문서의 초안을 작성하기 시작합니다. 나는 전자의 경우 [DEV], 후자의 경우 [PM]으로 커밋을 시작합니다. 그렇지 않으면 이것은 여전히 높은 수준의 요구 사항 토론을 위한 올바른 포럼입니다(예: 내장 계산기 및 @mdtauk 의 모형).

SavoySchuler 에 2019년 05월 30일

👍1

@mdtauk : 나는 당신의 말에 동의합니다. 접두사/접미사는 TextBox 좋은 추가가 될 것이며 숫자에 국한되지 않습니다. 몇 가지 예:

도메인이 항상 동일한 경우(예: @microsoft.com) 직원에게 이메일 주소를 입력하도록 요청합니다.
항상 W- 시작할 때 양식의 이름을 입력하십시오

등...

토론을 시작할 수 있도록 다른 티켓을 열어야 합니다!

rudyhuyn 에 2019년 05월 30일

@rudyhuyn IP 주소 같은 것은 지원하지 않지만 전화번호나 우편번호는 지원하는 기능이 실행 가능한 것으로 보십니까?
제 생각에는 어떤 것은 제한하기 시작하고 다른 것은 제한하지 않는 경우 적용 대상에 대한 규칙이 매우 명확하게 정의되어야 합니다.
정수, 부동 소수점 등으로 표시될 수 있는 값을 지원하면 상황이 매우 명확해지며 여전히 많은 가치를 제공하는 컨트롤이 생성됩니다.

mrlacey 에 2019년 05월 30일

👍1

@SavoySchuler 내 디자인은 전적으로 귀하의 처분에 달려 있으며, 기여하는 모든 사람을 위한 제어를 시각화하는 데 도움이 되도록 게시했습니다.

@rudyhuyn MaskedTextBox 또는 FormattedTextBox에 대한 제안을 게시하면 더 많은 비중을

@mrlacey 전화번호(서식 문자 제외)는 순수한 숫자이지만 어떤 종류의 계산 사용 사례에도 속하지 않으므로 마스크된 TextBox에 더 잘 맞습니까? 아니면 NumberBox에서 이를 지원하는 데 가치가 있습니까?

컨트롤을 생성할 때 어떤 컨텍스트에서 사용할 컨트롤이 중요한지에 대한 명확한 사용 사례와 예제를 제공하는 문서.

mdtauk 에 2019년 05월 30일

🎉1 👍1

@mrlacey : 그렇지 않습니다.

이전에 말했듯이 0-9 문자를 사용하는 것뿐만 아니라 산술 값과 연결된 실수를 분리해야 합니다.

IP주소, 전화번호, 주민등록번호, 우편번호는 0~9자리를 사용하지만 산술적 값은 없습니다(2개 추가 가능, 끝에 ".00"을 붙이면 값의 의미가 바뀌는 등..) . 이러한 경우 값은 int/double이 아닌 문자열이므로 MaskedTextBox가 더 적합합니다.

또한 우편 번호는 미국에서는 숫자만 사용하지만 캐나다에서는 사용하지 않습니다. 예를 들어 IPv6 주소에는 AF 문자가 포함될 수 있고 전화 번호에는 + 기호가 포함될 수 있습니다(555-123-4567 및 +555-123-4567은 2개의 다른 전화번호) 등...

내 의견을 요약하자면 NumberBox.Value는 문자열이 아니라 double이어야 합니다.

rudyhuyn 에 2019년 05월 30일

👍5

@mrlacey 전화번호(서식 문자 제외)는 순수한 숫자이지만 어떤 종류의 계산 사용 사례에도 속하지 않으므로 마스크된 TextBox에 더 잘 맞습니까? 아니면 NumberBox에서 이를 지원하는 데 가치가 있습니까?

전화 번호는 전체 숫자(형식 포함)로 구성될 수 있지만 그렇다고 해서 숫자가 되는 것은 아닙니다. 어떤 종류의 산술 연산도 수행할 수 없으며 의미 있는 결과를 얻을 수 없습니다.
또한 일부는 더하기 기호로 시작할 수 있습니다.
또한 전화번호에서 앞에 오는 0의 수는 의미가 있습니다. 숫자 값의 경우 그렇지 않습니다.
계산 또는 위/아래 버튼과 같은 컨트롤의 다른 기능은 "전화 번호"에 대해 의미가 없습니다.

이 제어는 정보 손실 위험 없이 int/uint 또는 소수로 변환할 수 있는 값으로 제한되어야 합니다.

mrlacey 에 2019년 05월 30일

👍2

이 피드백을 적절하게 합성하고 있는지 확인하기 위해 형식 유형 및 엄지손가락을 통해 모든 유형의 숫자 문자열 입력(예: 전화 번호 및 IPv4)에 가장 적합한 위치라고 생각되면 이 댓글에 엄지 손가락을 올려 주세요. NumberBox가 수학 및 수학 값 캡처에만 집중할 수 있도록 해당 기능을 다른 컨트롤이나 새 컨트롤로 연기해야 하는 경우 아래로 . (계산기 모드 및 Up/Down 버튼과 같은 수학 연산을 지원하는 기능은 해당 API를 통해 활성화해야 합니다.)

전 세계적으로 고객에게 최고의 투자 수익을 제공하는 결정을 내릴 것이기 때문에 이것이 민주적으로 결정될 것이라고 보장할 수는 없습니다. 문자열에 대한 전용 컨트롤을 선호합니다.

SavoySchuler 에 2019년 05월 30일

👎7

@SavoySchuler 값에 컨텍스트와 의미를 추가하는 접두사와 접미사 뿐만 아니라

mdtauk 에 2019년 05월 30일

👍1

저는 여기에서 팀과 동기화했으며 일부 공개 질문에 대한 업데이트를 공유하고 싶었습니다.

우리는 귀하의 피드백을 듣고 있으며 NumberBox가 숫자 문자열에 적합한 장소가 아니라는 데 동의합니다. FormatKinds 및 CustomFormat 속성은 보다 직관적인 방식으로 숫자 형식을 제어하기 위해 보다 구체적인 API로 대체되었습니다.
접두사 및 접미사는 실제로 TextBox에 속합니다(NumberBox가 이를 상속함). @mdtauk , @mrlacey 또는 다른 사람에게 기능 요청을 제안하기 위해 며칠 앞서 시작할 것입니다. 그렇지 않으면 시작하고 여기에 링크하겠습니다. 당분간은 NumberBox가 현지화/자동화 출력에서 차단되는 것을 방지할 것입니다.
NumberBox의 최종 피드(계산, 반올림 등)는 TextBox에서 나오는 Text 속성의 문자열로 유지되고 새 Value 속성의 Double로 유지됩니다. 우리는 이러한 피드백을 서로에게 전달하여 하나에 대한 변경이 다른 하나에 반영되도록 할 것입니다. 이 작업의 목적은 가능한 한 많은 작업을 수행하고 필요할 때 액세스할 수 있도록 값을 준비하는 것입니다.
사양의 속성으로 StepSize가 누락되었습니다.
정수 유형은 Double로 변경됩니다.
우리는 여전히 내장형 계산기에 대한 기대를 갖고 있으며 이를 개선하는 데 도움이 되는 더 많은 시나리오를 찾고 있습니다. @mdtauk , 이 피드백 지점에 이미 응답해 주셔서 감사합니다!
입력 유효성 검사와 관련하여 아이디어는 개발자가 입력을 조작하거나 필요에 따라 끝/차단 양식 제출에서 처리할 기회를 제공하는 ValueChanged 유형의 이벤트를 먼저 보내는 것입니다. 수정 조치가 취해지지 않은 경우(예: 최소/최대 범위 내에서 강제 실행, 유효하지 않은 문자 제거 등) NumberBox는 대신 사용자에게 입력에 대한 오류 표시를 표시합니다. 이 이중 접근 방식을 통해 개발자는 원하는 경우 응답할 수 있지만 수정을 사용자에게 연기할 수도 있습니다.

내가 여전히 응답하고 있는 엄청난 양의 피드백이 있습니다. 기다려 주셔서 감사합니다. 여기와 사양 리포지토리에 있는 모든 사람에게 답변을 드리겠습니다!

SavoySchuler 에 2019년 05월 31일

"임베디드 계산기가 있는 NumberBox의 컨셉 아트." WinUI 커뮤니티, 2019년 5월. (색상)

muscle car with flames

( @ryandemopoulos 의

SavoySchuler 에 2019년 05월 31일

@SavoySchuler 우리가 논의하고 있는 제어 유형을 사용할 수 있는 몇 가지 시나리오 예제를 요청했습니다. 내 앱에는 좋은 예가 될 수 있는 두 가지가 있습니다.

사례 1: 축을 조정할 수 있는 2D 그래프용 설정 편집기가 있습니다.

이것은 단순한 숫자 입력만 있으면 됩니다. 여기서 증가 +/- 버튼이 유용할 것입니다.
이중 값은 괜찮지만 입력은 문자를 누를 때 유효성을 검사해야 합니다. 사용자는 'a'를 눌러도 입력 상자에 표시되어서는 안 됩니다. 입력 유효성 검사는 테두리를 빨간색으로 만들고 사용자에게 경고를 주어서는 안 됩니다. 단순히 잘못된 값을 입력할 수 없어야 합니다.
현지화는 컨트롤에 의해 지원되어야 하고 소수점 이하 자릿수(쉼표, 마침표 등) 이동은 특별한 경우로 처리되어야 합니다.

사례 2: 아래와 같이 통화 값에 대한 입력 필드가 있습니다. 이것은 사용자 정의 컨트롤 "CurrencyBox"입니다.

이것은 계산기 버튼을 사용할 수 있고 방정식 2+3을 입력하는 기능은 여기에 약간의 가치가 있을 것입니다(나는 여전히 이것이 별도의 컨트롤이어야 한다고 생각합니다)
~~이중 값은 이에 적합하지 않습니다.~~ 이러한 유형의 사용 사례를 지원하기 위해 Value에 대한 사양을 double에서 decimal로 변경하는 것이 좋습니다 . 그렇지 않으면 문자열 텍스트를 구문 분석하는 것은 개발자의 몫입니다.
음수 부호가 별도로 처리되는 특별한 경우가 있습니다. 따라서 사용자가 사인에서 실수를 하지 않는 것이 훨씬 쉽습니다. 나는 실제로 NumberBox가 그것을 즉시 지원할 것이라고 기대하지 않습니다.
텍스트 정렬은 설정하는 데 중요하며 접두사/접미사는 통화 기호를 표시하는 데 매우 유용합니다(현지화는 기호를 오른쪽 또는 왼쪽에 표시할지 여부를 아는 데 여전히 잠재적인 문제가 될 수 있지만 앱 자체에는 해당 논리가 있을 수 있음)
사용자는 외부 또는 로컬 값을 모두 입력할 수 있습니다. 두 값 모두에 대한 NumberFormatInfo 및 CultureInfo는 UI 문화권과 다를 수 있습니다. 따라서 현지화를 위해 컨트롤은 사용자 지정 NumberFormatInfo에 대한 재정의를 지원해야 합니다.

지금 앱에서 Windows Community Toolkit은 아래와 같이 TextBox에 속성이 연결된 두 경우 모두에 사용됩니다.
TextBoxRegex.ValidationMode="동적"
TextBoxRegex.ValidationType="10진수"

마지막 댓글 몇 개(너무 길어서 죄송합니다!)

여기에서 잠재적으로 3가지 다른 컨트롤에 대해 논의하고 있다고 생각합니다. Bar-bones NumberBox, 방정식과 고급 숫자 입력이 가능한 CalculatorBox(계산기 버튼!), 마지막으로 전화 번호 및 IP 주소와 같은 숫자가 아닌 입력을 위한 MaskedTextBox입니다. 우리는 그것들을 혼동해서는 안 되며 이러한 개념을 분리하는 방법에 동의하는 것이 사양을 진행하는 데 핵심입니다.
우리는 가장 기본적이고 틀림없이 가장 유용한 사용 사례에 대한 초점을 놓을 수 없습니다. 유효한 숫자만 입력할 수 있도록 입력 필터링 외에는 아무 것도 없는 평범한 텍스트 상자입니다. 다른 모든 옵션은 끌 수 있어야 합니다(증가 +/- 버튼을 생각하고 있습니다)
~~나는 여전히 구문 분석된 값에서 소수점 정밀도를 정확하게 캡처하기 위해 사양에서 2배에서 10진수로 변경하는 것이 좋습니다.~~ 또한 유리수 입력과 다른 정수 입력을 고려해야 합니다. 이는 API "IsInteger = true"에서 십진 기본값에서 변경하는 새로운 속성일 것입니다.

편집: NumberBox.Value 유형에 대해 2배에서 10진수로 전환하는 아이디어를 제거했습니다. 이것이 C++ WinRT 세계에 존재한다고 가정하는 것은 틀렸습니다. 그렇지 않고 대신 .net 코어/프레임워크에만 있습니다.

robloo 에 2019년 05월 31일

👍3

@robloo , 그 마지막 코멘트에 대해 WinRT에는 Decimal 유형이 없습니다.

MikeHillberg 에 2019년 05월 31일

👍2

XAML 도구 키트의 Visual Tree 디버거는 도구 키트의 NumericUpDown 컨트롤에 크게 의존하는 도구로, 마우스 끌기, 버튼, 키보드를 사용한 증가/감소가 모두 중요합니다. 계산기 입력도 도움이 될 수 있습니다.

xyzzer 에 2019년 05월 31일

👍1

@robloo 와 @xyzzer , 이것은 내가 찾고 있는 바로 그 종류의 정보입니다!

검증/마스킹

@robloo , 특히 사례 1: Bullet 2 - 유효성 검사 대 마스킹에 관심이 있습니다. 현재 "잘못된 입력" 시나리오를 통해 이야기해 보겠습니다.

새 사용자가 NumberBox에 "2"를 입력합니다.
NumberBox는 숫자가 아닌 입력을 "0"으로 반환할 수 있는 기회를 제공하는 "ValueChanged" 이벤트를 발생시킵니다. 아무런 조치도 취하지 않으면...
NumberBox의 유효성 검사가 빨간색으로 빛나고 숫자 입력만 허용됨을 알리는 오류 메시지를 사용자에게 표시합니다(이 부분은 아직 완전히 합리화되지 않았으므로 이것은 가설일 뿐입니다).

이 일련의 이벤트를 통해 생성하는 데 필요한 경험을 생성할 수 있습니까?

마스킹이 바람직한 기본값이 될 수 있다는 점을 이해하지만 지난 주에 우리 팀이 논의한 내용을 공유하겠습니다. Fluent 컨트롤에서 유효성 검사(오류 표시기/메시지)가 대안인 마스킹이 실망스럽고 실망스러울 수 있다는 방향에 착륙했습니다. 최종 사용자가 키보드 입력에서 아무 출력도 경험하지 못할 때 혼란스럽습니다. 이에 대해 생각할 수 있는 또 다른 방법은 유효성 검사가 사용자에게 일정 수준의 투명성과 정보를 제공하여 사용자가 소리 없이 강제되는 것과는 반대로 경험을 더 잘 알 수 있도록 한다는 것입니다. 따라서 우리의 현재 조치는 개발자가 고급 유효성 검사(곧 TextBox에 제공됨)를 추가하거나 필요에 따라 ValueChanged 이벤트를 통해 마스킹할 기회를 차단하지 않으면서 기본 유효성 검사를 구축하는 것이었습니다. 이해하자면, 이는 권장 환경을 기본으로 제공하면서 모든 요구 사항을 충족할 수 있을 만큼 충분히 유연합니다.

당신의 생각은 무엇입니까? 가능하다면 이러한 개념을 추가로 구성하거나 더 나은 경험을 구축하기 위한 아이디어에 관심이 있습니다.

값 형식

귀하의 다른 요점인 @robloo 에 DecimalPrecision 정밀도 속성을 Spec 에 추가했습니다. 이것을 ="0"으로 설정하면 정수가 됩니다. 또한 MinValue="0"을 설정하면 숫자를 음수가 아닌 상태로 유지하는 데 도움이 될 수 있습니다(또는 ValueChanged 이벤트는 입력을 절대값으로 강제 변환할 수 있는 또 다른 기회입니다).

아직 스펙 을 살펴보셨나요? 나는 당신의 경험을 완전히 가능하게 하는 데 필요한 모든 속성을 포함했다고 생각하지만(검증 대 마스킹 논의 보류 중) 내가 놓친 것이 있다고 생각하는지 알고 싶습니다.

SavoySchuler 에 2019년 06월 04일

👍1

마스킹은 최종 사용자가 키보드 입력에서 아무 출력도 경험하지 못할 때 실망스럽고 혼란스러울 수 있습니다.

100% 동의합니다. 더 나은 방법은 LosingFocus/EnterPressed에서 유효성을 검사하고 입력된 값이 유효성을 검사하지 않는 경우 oldValue를 복원하는 것입니다. 이것이 LosingFocus/EnterPressed에서 트리거되고 oldValue/newValue를 포함하는 신호가 완벽한 이유입니다.

adrientetar 에 2019년 06월 04일

👍1

@adrientetar , 좋은 지적입니다! 그것이 당신이 만들어야 할 경험입니까? 그렇다면 ValueChanged 이벤트가 이전 값과 새 값을 모두 보내도록 해야 하는 작업을 살펴보겠습니다.

SavoySchuler 에 2019년 06월 04일

@SavoySchuler 그것은 실제로 내 앱에서하고 싶은 것입니다. 컨트롤이 기본적으로 수행하지 않는 한 해당 동작을 직접 빌드합니다.

내가 원하는 다른 것은 10 증분의 경우 Shift+↑/↓ 이고 100 증분의 경우 Ctrl+Shift+↑/↓ 이지만 100 증분이 항상 의미가 있는 것은 아니라고 생각합니다.

adrientetar 에 2019년 06월 04일

좋은 점! 컨트롤이 RangeBase에서 파생되는지 확인해야 합니다.
SmallChange와 LargeChange를 모두 정의하고 이 둘을 다음에서 사용합니다.
아주 최소한.
호출하는 데 사용할 표준 키보드 조합의 예가 있습니까?
UWP의 RangeBase 또는 WinForms/ComCtl(?) NumericUpDown에 큰 변화가 있습니까?

2019년 6월 3일 월요일 오후 3시 50분 Adrien Tétar [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=AANMBMFZBHJIE4DR2KN46TTPYWN3BA5CNFSM4HA4PBNKYY4TWWWK3TUL52HS4DFVREXG43VMVBW63
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AANMBMG4AWBK44VE4O4GYR3PYWN3BANCNFSM4HA4PBNA
.

xyzzer 에 2019년 06월 04일

확인을 위해 확인하겠지만 키보드 단축키는 구현하려면 앱에 맡겨야 한다고 자신합니다. 나는 이것을 #21에 대한 접근성 근거로 시도했고 새로운 키보드 단축키를 도입하는 것은 Windows에서 주장하지 않은 거의 모든 단축키가 이제 앱 수준에서 사용되었기 때문에 플레이하기에는 위험한 게임입니다. F6 bandwagon) - 하지만 여기서 제어 포커스가 예외를 허용하는지 확인하겠습니다!

SavoySchuler 에 2019년 06월 04일

빌드 2018은 INotifyDataErrorInfo를 사용하여 TextBox 컨트롤에 대한 유효성 검사 상태가 발표된 때였습니다.
이것은 현재 텍스트 문자열의 유효성을 검사하거나 무효화하기 위해 마스킹과 함께 사용하는 것이 좋습니다.

편집: 아이콘과 더 두꺼운 하단 테두리 색상의 사용은 색맹 상황과 흑백으로 볼 때 인식을 돕기 위한 것입니다. 공간이 부족한 경우 하단 오류 텍스트가 아이콘의 툴팁으로 표시될 수 있습니다.

mdtauk 에 2019년 06월 04일

🎉1 👍1

@mdtauk 당신은 이러한 마크업에 경이

SavoySchuler 에 2019년 06월 04일

@SavoySchuler 빌드 2018에 표시된 예제를 기반으로 한 쉬운 외삽

그리고 많은 예제를 볼 수 있습니다 :)

mdtauk 에 2019년 06월 04일

👍1

죄송합니다. 이것은 또 다른 긴 것입니다!

@SavoySchuler @adrientetar 아래 진술에서 귀하가 어디에서 왔는지 확실히 알 수 있습니다. 대부분의 경우 유효성 검사를 처리하는 가장 좋은 방법이라고 주장하지는 않습니다. 그러나 숫자만 입력하는 것이 매우 명백한 몇 가지 특별한 경우가 있다고 생각해야 합니다. 사용자가 잘못된 문자를 뚱뚱하게 핑거링하지 못하도록 함으로써 실제로 사용자에게 호의를 베풀고 있습니다.

마스킹은 최종 사용자가 키보드 입력에서 아무 출력도 경험하지 못할 때 실망스럽고 혼란스러울 수 있습니다.
100% 동의합니다. 더 나은 방법은 LosingFocus/EnterPressed에서 유효성을 검사하고 입력된 값이 유효성을 검사하지 않는 경우 oldValue를 복원하는 것입니다. 이것이 LosingFocus/EnterPressed에서 트리거되고 oldValue/newValue를 포함하는 신호가 완벽한 이유입니다.

그럼에도 불구하고 어떻게 처리되는지 알아보기 위해 다른 앱을 둘러보기로 했습니다. 사용자 상호 작용에 대해 Microsoft보다 더 많은 연구를 하는 사람은 없을 것 같아서 데스크톱 64비트 버전의 Word와 UWP 버전의 OneNote를 차례로 가져왔습니다. 님 말씀에 거의 전적으로 동의합니다. 분명히 숫자 입력일 뿐인 글꼴 크기 또는 모양 크기 입력 상자에 텍스트를 입력할 수 있습니다. 초점 손실을 크게 확인하고 마지막 유효한 입력으로 되돌립니다.

| 제목 | 그림 | 댓글 |
|---------|-----|------------|
| UWP OneNote 글꼴 크기 항목 | | 모든 값은 키보드에서 입력할 수 있으며 자동으로 유효성이 검사되고 초점을 잃은 경우 마지막 유효한 값으로 재설정됩니다. |
| 데스크탑 단어 글꼴 크기 항목 | | 키보드에서 모든 값을 입력할 수 있으며 초점을 잃으면 자동으로 유효성이 검사되며 유효하지 않은 경우 오류 메시지가 나타납니다. [확인]을 클릭하면 마지막 유효한 값으로 재설정됩니다. |
| UWP OneNote 2D 그래프 | | 어떤 값이든 키보드에서 입력할 수 있습니다. 유효하지 않은 값은 무시되고 계산에 마지막 유효한 입력이 사용됩니다(초점 상실 시 유효성을 검사하지 않음). 증가 +/- 버튼을 누르면 마지막 유효한 입력을 사용하여 증가합니다. |
| 바탕 화면 단어 모양 크기 항목 | | 키보드에서 모든 값을 입력할 수 있으며 초점을 잃으면 자동으로 유효성이 검사되고 초점을 잃으면 마지막 유효한 값으로 재설정됩니다. |

그래서 나는 내가 틀렸다는 것을 증명했다고 생각합니다. 즉, 당신과 동의해야합니다!

사이드 코멘트:

이전에 다른 사람이 언급했듯이 NumberBox에 터치/가상 키보드가 있는 키보드 포커스가 있는 경우 숫자 키보드만 표시되어야 합니다.
왼쪽에서 아래로 증가하고 오른쪽에서 위로 증가하는 것은 스타일링 측면에서 여기에서 논의할 흥미로운 아이디어입니다. 좋아요!

새 사용자가 NumberBox에 "2"를 입력합니다.
NumberBox는 숫자가 아닌 입력을 "0"으로 반환할 수 있는 기회를 제공하는 "ValueChanged" 이벤트를 발생시킵니다. 아무런 조치도 취하지 않으면...
NumberBox의 유효성 검사가 빨간색으로 빛나고 숫자 입력만 허용됨을 알리는 오류 메시지를 사용자에게 표시합니다(이 부분은 아직 완전히 합리화되지 않았으므로 이것은 가설일 뿐입니다).
이 일련의 이벤트를 통해 생성하는 데 필요한 경험을 생성할 수 있습니까?
당신의 생각은 무엇입니까? 가능하다면 이러한 개념을 추가로 구성하거나 더 나은 경험을 구축하기 위한 아이디어에 관심이 있습니다.

입력 유효성 검사를 추가하는 것이 전체 플랫폼에 좋다는 점을 완전히 이해하고 동의합니다. 그러나 본질적으로 숫자에 대한 특별한 처리 없이 입력 유효성 검사를 설명했습니다. 따라서 값을 자동으로 구문 분석하는 것 외에 NumberBox가 무슨 소용이 있습니까? 개발자로서 데이터 유효성 검사가 포함된 TextBox는 거의 동일합니다.

위의 예를 기반으로 기본 기능은 우리의 아이디어와 @adrientetar 가 말하는 것의 혼합이어야 한다고 생각합니다. 사용자는 시각적 피드백을 받을 수 있도록 아무 값이나 입력할 수 있습니다. 그러나 손실 초점에서 값은 자동으로 유효성이 검사되고 이전의 유효한 숫자(또는 비어 있음)는 자동으로 되돌아갑니다. 이것은 개발자가 입력 유효성 검사를 직접 처리해야 하는 번거로움을 덜어줍니다(우리는 이미 NumberBox의 숫자여야 한다는 것을 알고 있습니다). 또한 데이터 유효성 검사가 포함된 TextBox와 명확하게 구별됩니다.

이벤트 측면에서 사용 사례가 더 명확해지면 텍스트 변경을 취소할 수 있는 기회를 갖고 싶습니다. 따라서 ValueChanged 외에 입력을 비교 및 취소할 수 있도록 ValueChanging 및 TextChanging 이벤트를 권장합니다. 확실히 OldValue와 NewValue는 관계없이 필요합니다. 이렇게 하면 최소한 필요한 경우 다시 OldValue로 빠르게 변경할 수 있습니다(UWP는 이벤트 내에서 TextValue를 수정할 때 충돌하는 것을 좋아하지만).

사양과 관련하여: DecimalPrecision에 대한 좋은 아이디어가 있지만 검토하고 내 의견을 추가하려면 더 많은 시간이 필요합니다. 기본값은 String=Empty, Value=Null이어야 하고 증분 +/- 버튼을 눌렀을 때 값이 비어 있는 대신 0으로 처리되어야 하는 것과 같은 작은 뉘앙스가 많이 있습니다.

@mdtauk 이렇게 좋은 일러스트를 이렇게 빨리 만들

robloo 에 2019년 06월 04일

🎉1 😄1 👍1

@roblo 친절한 댓글 감사합니다. 나는 당신의 +/-에 관해 간단히 할 말이 있습니다
이 NumberBox가 수행할 수 있는 수학적 연산과 혼동을 피하기 위해 현재 스핀 버튼에 사용되는 Up 및 Down 기호를 사용하는 것이 더 나을 수 있습니다.

iOS는 "스테퍼" 컨트롤을 사용하지만 텍스트 입력은 별도이며 인라인 계산이 없습니다.

여기 내가 찾은 몇 가지 더 많은 디자인이 있습니다

내가 선택한 디자인은 이 컨트롤에 대한 Microsoft의 일반적인 스타일에 맞는 것 같지만 최선의 선택입니까 아니면 올바른 선택입니까? 다른 사람들이 그것에 대해 어떻게 생각하는지 듣고 싶습니다.

편집: 대체 양식의 일부 모형을 추가했습니다(하지만 첫 번째 아이디어가 가장 좋다고 생각합니다...)

mdtauk 에 2019년 06월 04일

🎉1

+/- 위치에서 @mdtauk 에 동의합니다. 첫 번째 위치가 가장 좋습니다.

XAML ControlTemplate이 있으므로 사용자(개발자)는 항상 다른 두 레이아웃에 대한 사용자 지정 템플릿을 만들 수 있습니다.

sonnemaf 에 2019년 06월 04일

👍4

@robloo , 당신은 상세한 답변에 대해 사과할 필요가 없습니다 - 특히 그들이 몇 가지 좋은 웃음을 포장할 때! 터치/가상 키보드에 대한 탁월한 아이디어 - 개발자/팀에서 실행하도록 사양의 공개 질문 섹션에 추가했으며 허용할 수 없는 성능 오버헤드가 없는지 확인합니다. 우리가 그것을 가능하게 할 수 있다면 그것은 사용자들에게 굉장한 편리함이 될 것이라고 생각합니다.

당신은 검증에 대한 훌륭한 요점을 제시합니다 ...

[1] 질문 시간: 개발자가 이 동작을 취소하고 대신 수행할 작업/오류 표시기 또는 메시지를 표시할 수 있는 이벤트를 노출하면서 허용되지 않는 입력을 자동으로 이전 값으로 되돌리는 유효성 검사 시스템에 반대하는 사람이 있습니까?

시각적으로 게시한 예제에서 분리된 UpDownButtons의 장점을 봅니다. 나는 @mdtauk 와 @sonnemaf 가 기본값에 대한 올바른 길을

분리된 UpDownButton에 대한 시나리오가 있다고 생각합니다. 내 마음은 최소한의 단방향 입력을 기대하는 작업이나 개발자가 입력 실수를 더 어렵게 만드는 작업으로 이동합니다. 나는 이것이 예를 들어 영화나 콘서트 티켓을 구매할 때 여러 응용 프로그램과 웹 사이트에서 제공하는 경험이라고 생각합니다.

그때 제 질문은...

[2] 질문 시간: 분리된 UpDownButton이 있는 NumberBox를 생성하기 위해 Xaml ControlTemplate에 의존해야 합니까(즉, 이것은 기본적으로 지원을 정당화하기에 충분히 일반적이지 않음) 또는 UpDownButton이 연속적으로 나타나는지 여부를 설정하기 위한 속성을 포함해야 합니다. 대 분리?

Fluent Design System 지침이 이 두 번째 질문을 무시할 수 있으므로 이 질문에 대해 @chigy 를 핑할 것입니다.

UpDownButtons 대화에 대한 접근성 고려 사항을 포함해야 합니다. UpDownButtons가 서로 근접하면 내레이터/화면 판독기 사용자에게 개념적 명확성을 제공하는 동시에 키보드 탐색 사용자를 위한 탐색 효율성을 유지할 수 있으며 이를 타협하지 않는 것도 중요합니다.

SavoySchuler 에 2019년 06월 05일

컨트롤이 매우 넓지 않은 경우 화살표가 수직으로 쌓이도록 하고 싶을 것입니다(내 앱에 필요하다는 것을 알고 있습니다). 설정된 너비에 따라 제어가 가능할까요? 그것이 의미가 있다고 생각하는 경우 그렇게 지정하는 것은 유창한 디자인 지침에 달려 있습니다.

adrientetar 에 2019년 06월 05일

👍1

나는 3개의 공개 질문으로 제안을 업데이트했습니다.

컨셉 디자인을 해주신 @mdtauk님 감사합니다!

SavoySchuler 에 2019년 06월 05일

@adrientetar 필요하다고 지적해주셔서 기쁩니다. 이 세 가지 구성에 대해 열거형이 필요한 것 같습니까?

SavoySchuler 에 2019년 06월 05일

컨트롤이 매우 넓지 않은 경우 화살표가 수직으로 쌓이도록 하고 싶을 것입니다(내 앱에 필요하다는 것을 알고 있습니다). 설정된 너비에 따라 제어가 가능할까요? 그것이 의미가 있다고 생각하는 경우 그렇게 지정하는 것은 유창한 디자인 지침에 달려 있습니다.

컨트롤이 사용할 수 있는 공간의 양을 인식하고 반응하도록 하는 제안이 있었습니다. #677 컨트롤이 좁아짐에 따라 스핀 버튼의 위치를 변경하는 데 사용할 수 있습니다. MinWidth와 유사한 NarrowWidth 속성이 필요하거나 힌트 역할을 하는 NumberOfDigits가 필요할 수도 있습니다.

mdtauk 에 2019년 06월 05일

회색으로 표시된 텍스트 예와 관련하여 - 이것이 최종 결과가 무엇인지에 대한 힌트 역할을 하기보다 사용자가 표시되는 값을 채우도록 부추길 수 있다는 점을 우려합니다. PlaceholderText처럼 보입니다.

AccentColor와 다른 글꼴 두께를 사용하여 눈에 띄게 만드는 것은 어떻습니까?

mdtauk 에 2019년 06월 05일

👍1

훌륭한 링크, @mdtauk. 이것이 우리가 가는 길이라면 [Auto, Vertical, Horizontal, Detached]와 같은 값을 가진 열거형으로 이것을 처리할 수 있다고 상상합니다. 생각?

또한, 나는 이미지를 업데이트했습니다! 회색으로 표시된 텍스트가 프롬프트처럼 보일 수 있다는 생각이 옳다고 생각합니다. 이 메시지를 따르면 "="로 인해 오류가 발생합니다.

SavoySchuler 에 2019년 06월 05일

훌륭한 링크, @mdtauk. 이것이 우리가 가는 길이라면 [Auto, Vertical, Horizontal, Detached]와 같은 값을 가진 열거형으로 이것을 처리할 수 있다고 상상합니다. 생각?

초기 생각은 컨테이너의 숫자가 수직 방향이 필요한 곳에서 충분히 커질 수 있을까요? AutoCompleteBox는 검색 버튼을 움직이지 않으며 문자열은 일반적으로 숫자보다 깁니다.

그것이 순전히 사용 가능한 공간에 국한된 것이라면 자동 응답 동작(해당 제안이 계속 진행되는 경우)이 열거형보다 낫습니다. 개발자에게 컨트롤 자체의 옵션을 제공하면 컨트롤의 일관성 없는 사용으로 이어질 수 있지만, 이것은 github에서 우리가 단독으로 처방하는 것이 아니라 사용자 연구에서 살펴봐야 하는 것이어야 한다고 생각합니다.

개발자는 컨트롤에 대해 _정말_ 다른 레이아웃이 필요한 경우 컨트롤을 다시 템플릿할 수 있는 옵션이 항상 있으며, 원하는 경우 이에 대한 대체 스타일 을 포함할 수 있습니다. A) 기본값과 수직 스타일 및 템플릿 - 및 B) 두 스타일이 모두 올바르게 테스트되도록 합니다.

mdtauk 에 2019년 06월 05일

👍1

@mdtauk 위/아래 기호가 최고라는 데 동의합니다. 저는 입력의 반대쪽에 화살표가 있는 예를 보여주고 싶었습니다. 이전에 언급했듯이 사용자가 터치 기반 UI에서 거의 필수인 잘못된 키를 누르지 않도록 하는 데 도움이 됩니다. OneNote에서 제공한 예제에는 +/- 기호가 있었지만 기호 자체를 무시하도록 추가했어야 했습니다.

@SavoySchuler

[2] 질문 시간: 분리된 UpDownButton이 있는 NumberBox를 생성하기 위해 Xaml ControlTemplate에 의존해야 합니까(즉, 이것은 기본적으로 지원을 정당화하기에 충분히 일반적이지 않음) 또는 UpDownButton이 연속적으로 나타나는지 여부를 설정하기 위한 속성을 포함해야 합니다. 대 분리?

UWP가 처음 만들어졌을 때 터치가 먼저였다는 것을 알고 있습니다. 따라서 분리된 UpDownButton이 틀림없이 더 나을 것입니다. 그 이후로 터치 우선 요구 사항이 완화되었으며 사용자가 마우스와 같은 정확한 입력 방법(이동 거리가 적음)을 사용할 때 서로 옆에 있는 버튼이 더 좋습니다. 이것은 사용 사례에 따라 다르므로 열거형이 UpDownButton이 표시되는 방식을 지정하는 데 유용하다는 데 동의합니다.

열거형 값의 경우 여러 상태에 대해 논의했으며 일반화하면 몇 가지를 더 추가할 수 있습니다.

SeparatedHorizontal : 왼쪽의 아래쪽 화살표, 오른쪽의 위쪽 화살표
SeparatedVertical : 아래쪽에 아래쪽 화살표, 위쪽에 위쪽 화살표
왼쪽: 왼쪽에서 서로 옆에 있는 아래쪽 및 위쪽 화살표(가로 방향)
오른쪽 : 오른쪽에서 아래쪽 화살표와 위쪽 화살표가 나란히 표시됨(가로 방향)
상단 : 상단에서 서로 옆에 있는 아래쪽 및 위쪽 화살표(수직 방향)
하단 : 하단에서 서로 옆에 있는 아래쪽 및 위쪽 화살표(수직 방향)

이 모든 것이 너무 복잡해지면(빠르게도) XAML의 사용 사례에 대한 컨트롤을 다시 템플릿화할 수 있습니다.

다른 아이디어를 버리자면, 분리된 UpDownButtons의 기호 방향을 변경하는 것도 [<] 123 [>] 에 의미가 있을 수 있습니다. 앱별로 스타일을 변경할 수 있으므로 이 추가된 복잡성을 무시해도 됩니다.

또한 접근성 문제 중 일부는 내가 예제를 가져온 OneNote에서 이미 해결되었을 수 있습니다.

robloo 에 2019년 06월 05일

👍1

@robloo 귀하가 언급한 왼쪽 및 오른쪽 배치는 신중한 설정보다는 RtL 및 LtR 현지화를 위해 유지되어야 한다고 생각합니다.

아래는 제 의견입니다

또한 텍스트 필드 위에 버튼을 배치하는 것이 의미상 의미가 있는지 확신할 수 없습니다. 버튼에 손가락을 대고 있을 때 숫자가 변경되는 것을 보기 어렵게 만들 수도 있습니다.

모든 조합을 컨트롤에 포함하면 혼란스러운 사용이 발생할 수 있으며 긴급한 필요가 있는 경우 템플릿을 다시 작성하여 이러한 모든 작업을 수행할 수 있습니다.

텍스트 필드 아래의 버튼은 공간이 제한된 영역에서 어느 정도 사용할 수 있으며 컨트롤 자체의 옵션으로 탭할 수 있는 버튼이 훨씬 커집니다. 그것이 컨트롤과 함께 번들로 제공되는 스타일인지, 아니면 다음 사이의 열거형 인지 여부:

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

mdtauk 에 2019년 06월 05일

👍1

간단한 질문으로 가능한 제안: 이론적으로 숫자 상자에서는 숫자 상자에만 숫자를 입력할 수 있어야 합니다. 쓰여진 숫자를 구문 분석하고 이 필드의 실제 숫자로 변환하는 것이 얼마나 어려울까요?

예를 들어:
하나 + 둘 = 3
번역하다
1 + 2 = 3

또는
하나 더하기 둘은 셋
번역하다
1 + 2 = 3

그냥 아이디어입니다.

shaheedmalik 에 2019년 06월 05일

👍1

간단한 질문으로 가능한 제안: 이론적으로 숫자 상자에서는 숫자 상자에만 숫자를 입력할 수 있어야 합니다. 쓰여진 숫자를 구문 분석하고 이 필드의 실제 숫자로 변환하는 것이 얼마나 어려울까요?
예를 들어:
하나 + 둘 = 3
번역하다
1 + 2 = 3
또는
하나 더하기 둘은 셋
번역하다
1 + 2 = 3
그냥 아이디어입니다.

그것은 의미가 있습니다. 영어의 경우. 다른 언어로 해당 문자열을 번역하고 구문 분석해야 할 때 문제가 됩니다. 그리고 폴란드어 사용자는 영어 단어를 입력하면 어떻습니까?

현재로서는 숫자 0-9, 소수, 숫자 구분 기호 및 수학 연산자의 형식만 논의되었습니다. 그러나 다른 번호 체계를 수용해야 할 수도 있습니다.

언어 번역을 추가하는 것은 큰 노력이 될 것이며 이점이 무엇인지 명확하지 않습니다.

이제 이 컨트롤이 오디오 입력으로 조작되어야 하므로 숫자나 작업을 말해야 합니다. 여기에는 말하는 언어를 해석하는 작업이 포함될 수 있습니다.

나레이터:
"값이 없는 Pixels NumberBox"

사용자:
"백이십팔 픽셀"

[ 128 ____________ | 픽셀 ]

사용자:
"64픽셀 추가"

[ 192 ____________ | 픽셀 ]

나레이터:
"백구십이 픽셀"

mdtauk 에 2019년 06월 05일

👍1

[1] 질문 시간: 개발자가 이 동작을 취소하고 대신 수행할 작업/오류 표시기 또는 메시지를 표시할 수 있는 이벤트를 노출하면서 허용되지 않는 입력을 자동으로 이전 값으로 되돌리는 유효성 검사 시스템에 반대하는 사람이 있습니까?

입력한 텍스트 가 유효하지 않은 경우 값 이 이전 Value "를 유지하려는 것은 컨트롤이 책임져야 하는 일이라고 생각하지 않습니다. 컨트롤이 단일 현재 값(또는 오류 상태)을 처리하도록 하고 앱이 ValueChanged 이벤트를 통해 필요에 따라 추가 기록 처리를 처리하도록 합니다.

초기 버전의 경우 위/아래 버튼의 단일 위치를 지원하는 것이 필요할 경우 다시 템플릿할 수 있으므로 괜찮을 것이라고 생각합니다.
Up/Down 버튼의 위치를 결정하는 기능이 필수로 간주되는 경우 추가되는 모든 열거형은 UpDownButtonsEnabled 속성을 가질 필요를 제거해야 하며 열거형 값은 Hidden 수 있습니다. 대신 추가했습니다.
또한 Up/Down 버튼의 위치를 조작하기 위한 지원 기능이 내장되어 있으면 제공된 옵션 이외의 항목에 대해 템플릿을 조정해야 하는 사람이 복잡해집니다.

mrlacey 에 2019년 06월 05일

👍1

@shaheedmalik , 훌륭하고 직관적인 아이디어입니다. 스펙은 확인하셨나요? 입력을 가로채서 수동으로 입력된 숫자를 숫자 값으로 구문 분석할 수 있는 ValueChanged 이벤트가 있습니다. 따라서 특히 특정 언어를 염두에 둔 경우 생성할 수 있는 경험이 될 것입니다. 컨트롤의 기본 V1에서 전역 언어 파서를 굽는 경우 - @mdtauk 가 맞습니다. 이는 상당한 정당성을 필요로 하는 복잡성과 오버헤드를 추가할 것입니다. 이러한 컨트롤을 오픈 소싱할 때의 이점은 커뮤니티에서 분기할 수 있다는 것입니다. 이 경우 여기에서 사용자 또는 다른 커뮤니티 구성원이 이 컨트롤의 언어별 변형을 만들 수 있습니다. 이것이 NumberBox의 언어 파싱 버전을 민주화하는 가장 현실적인 방법이라고 생각합니다.

@mrlacey , Windows 전체에서 사용되는 NumberBox와 유사한 컨트롤 에 대한 @robloo 의 비교 분석 을 검토할 기회가 있었습니까? 이 필드를 마지막 유효한 숫자 전용 입력으로 재설정하는 동작은 실제로 시스템 전반에 걸쳐 선례가 있습니다. 즉, 컨트롤 자체 또는 개발자 지침이 이 패턴에 맞게 조정되어야 함을 의미합니다. 내 의도는 이 제어를 표준 Windows 환경과 일관성 있게 정렬하고 생태계의 나머지 부분에서 벗어나는 동작을 표준화하고 후자가 생성할 이 시스템 기본 동작을 생성하기 위한 지침을 주장하는 것과는 반대로 필요한 편차에 대한 길을 만드는 것입니다. 일반적인 경우에 쉽고 효율적입니다. 나는 의견 불일치를 권장합니다. 따라서 이것이 통제에 불필요한 복잡성을 추가한다고 생각하거나 아마도 이 선례를 재평가해야 한다고 생각한다면 알려주십시오.

| 제목 | 그림 | 댓글 |
|---------|-----|------------|
| UWP OneNote 글꼴 크기 항목 | | 모든 값은 키보드에서 입력할 수 있으며 자동으로 유효성이 검사되고 초점을 잃은 경우 마지막 유효한 값으로 재설정됩니다. |
| 데스크탑 단어 글꼴 크기 항목 | | 키보드에서 모든 값을 입력할 수 있으며 초점을 잃으면 자동으로 유효성이 검사되며 유효하지 않은 경우 오류 메시지가 나타납니다. [확인]을 클릭하면 마지막 유효한 값으로 재설정됩니다. |
| UWP OneNote 2D 그래프 | | 어떤 값이든 키보드에서 입력할 수 있습니다. 유효하지 않은 값은 무시되고 계산에 마지막 유효한 입력이 사용됩니다(초점 상실 시 유효성을 검사하지 않음). 증가 +/- 버튼을 누르면 마지막 유효한 입력을 사용하여 증가합니다. |
| 바탕 화면 단어 모양 크기 항목 | | 키보드에서 모든 값을 입력할 수 있으며 초점을 잃으면 자동으로 유효성이 검사되고 초점을 잃으면 마지막 유효한 값으로 재설정됩니다. |

@mdtauk , LTR 및 RTL 언어에 대한 귀하의 의견과 UpDownButtons가 나타나는 컨트롤 측면에 주목하십시오. 현지화 전문가가 이 작업을 실행하여 이것이 고려해야 할 고려 사항인지 확인합니다.

@mrlacey 부울이 열거 형에 중복된다는 것도 맞습니다. 다른 구성이 필요한지 곧 확인하도록 노력하겠습니다.

SavoySchuler 에 2019년 06월 05일

@adriantetar , 당신은 수직 버튼의 주요 고객입니다. 공간 제약을 더 잘 이해하는 데 도움이 될 수 있는 화면 캡처나 컨텍스트가 있습니까? @mdtauk 은 이전에 이 답변으로 생각했습니다.

초기 생각은 컨테이너의 숫자가 수직 방향이 필요한 곳에서 충분히 커질 수 있을까요? AutoCompleteBox는 검색 버튼을 움직이지 않으며 문자열은 일반적으로 숫자보다 깁니다.

SavoySchuler 에 2019년 06월 05일

@SavoySchuler (최종 값으로 재설정하는 것과 관련하여) 사양이 @robloo 검토의 컨트롤보다 오류 처리 및 보고를 위해 NumberBox에 더 많은 기능을 추가할 것이기 때문에 이러한 기능을 더 많이 만들려고 했습니다.

이걸 고려하세요:

AllowsCalculations=True NumberBox
수동으로 1100을 입력하고 다음 컨트롤로 탭
이것이 들어가고자 하는 것이 아님을 깨달아라
컨트롤로 돌아가서 "99 x 12"를 입력하십시오.
탭을 다음 컨트롤로 이동하면 값이 다시 "1100"을 표시하도록 되돌아갑니다('x'는 '*'와 같지 않으므로 계산 단계에서 실패합니다. 또는 'x'가 실패하면 실패하는 다른 유효하지 않은 계산을 고려하십시오. t 누르면 표시됩니다.)
이제 계산 결과가 아닌 값이 표시되고 오류 메시지가 표시되지 않으며 입력된 합계가 손실되어 발생한 일에 대한 기록이 없습니다.

5단계에서 다음 컨트롤로 탭할 때 발생하고 싶은 일은

"99 x 12"는 Text 값으로 유지됩니다.
오류 상태가 표시됩니다.
ValueChanged 이벤트 트리거 및 전달됨(Text='99 x 12', OldValue=1100, NewValue=Double.NaN)
그런 다음 사용자는 문제가 있음을 알 수 있습니다.
사용자는 전체 합계를 다시 입력하지 않고도 문제를 수정할 수 있습니다.
코드/앱 로직은 필요한 경우 적절한 작업을 수행할 수 있습니다.

입력 시 마지막으로 알려진 양호한 값으로 자동으로 되돌리려는 경우:

필수 필드에 값을 입력하지 않은 경우 외에는 오류 상태가 표시됩니까?
ValueChanged 이벤트가 잘못된 상태에 대해 보고하지 않기 때문에 그 가치가 크게 줄어들지 않습니까?

mrlacey 에 2019년 06월 05일

👍1

@SavoySchuler @mrlacey 다른 Microsoft 앱에서 이러한 예를 보면...

모달 팝업은 제외되어야 합니다. 대신 이것은 컨트롤 자체의 유효성 검사 상태에 의해 처리되어야 합니다.

영상

유효하지 않은 값이 있는 경우 내용은 해당 유효하지 않은 상태로 남아 있어야 하지만 컨트롤에 포커스가 있는 동안에만 가능합니다. 포커스가 손실되면 텍스트 필드 값이 되돌려지지만 유효성 확인 알림에는 사용자가 입력한 내용이 표시됩니까?

mdtauk 에 2019년 06월 05일

👍1

InputScope: 숫자 또는 FormulaNumber?

앞서 언급했듯이(PR 의견에서) FormulaNumber 에는 여기와 사양의 모든 계산 예제에 포함된 '공백'이 포함되지 않습니다. FormulaNumber에는 이 컨트롤에서 지원하지 않는 수학 기호도 포함됩니다.

나는 '숫자'에 투표한다

숫자

공식 번호

mrlacey 에 2019년 06월 05일

👍1

@SavoySchuler 내 말은 데스크톱 앱을 만들고 있다는 뜻입니다(내 자신의 Excel 버전이나 다른 것을 만들려고 하지 않음). 나는 화살표를 완전히 비활성화 할 것이라고 생각합니다. 마우스 드래그로 충분하다고 생각합니다. 마우스 끌기가 계획된 경우 사용자가 해당 경우 가능한 변경 범위를 미리 보기를 원하기 때문에 모든 변경 시 값 변경이 실행되어야 합니다. 사이드바:

Btw TextBox 내용은 세로로 중앙에 배치되지 않으며 이는 VerticalContentAlignment="Center"입니다.

adrientetar 에 2019년 06월 05일

👍1

Paint 3D가 사용하는 속성 사이드바와 비슷해 보입니다(이것도 더 얇은 테두리와 접미사 속성처럼 보이는 자체 컨트롤 스타일을 사용함).

드래그가 구현되지 않은 경우 항상 Paint 3D가 수행한 작업을 수행하고 슬라이더를 NumberBox에 바인딩할 수 있습니다.

또한 Adobe가 컨트롤에 드롭다운 슬라이더를 사용하여 수행하는 작업과 유사합니다.

@adrientetar 거기에서 고유한 버전의 NumberBox를 만들고 있는 것 같습니다. 글꼴에는 고려해야 할 디센더가 있으므로 TextBox의 텍스트에는 기준선 정렬이 있습니다.

NumberBox의 경우 문자가 시각적으로 중앙에 배치되는 경우가 있을 수 있지만 이러한 NumberBox는 ComboBox와 같은 표준 TextBox 또는 TextBox 파생 컨트롤 옆에 배치될 때 정렬되지 않습니다.

기본 템플릿 및 스타일을 만들 때 다양한 Windows.UI.Xaml.Documents.Typography 속성을 고려해야 합니다...

Typography.CaseSensitiveForms
Typography.NumeralAlignment + Typography.NumeralStyle(비례보다 표 형식이 더 좋을 수 있음)

mdtauk 에 2019년 06월 05일

👍1

@mrlacey , 당신은 유효한 주장을합니다. @adriantetar 의 응답을 기반으로 다음 시나리오는

값/텍스트 변경 이벤트는 _every_ 변경 시 발생하므로(드래그/스크롤 사용자가 범위를 테스트하는 경우) 따라서 "Enter"를 누르거나 포커스를 잃을 때까지 오류 메시지와 표시기가 표시되는 유효성 검사가 계속 발생할 수 있습니다. 이 경우 유효성 검사 값 재정의가 시작되고 마지막 좋은 값을 덮어씁니다(해당 속성에 의해 해당 동작이 비활성화되지 않는 한).

저는 오늘 오후에 팀과 채팅하여 지속적인 이벤트 발생/검증이 현실적인 아이디어인지 검증할 것입니다. 그렇지 않으면 다른 방식으로 범위를 확장할 수 있습니다.

@mdtauk , 하지만 유효성 검사의 시각적 표현에 대한 귀하의 주장이 옳다고 생각합니다. @LucasHaines , 저를 다시 확인해 주시겠습니까?

@jevansaks , 아래 InputScope 고려 사항에 무게를 실을 수 있습니까?

앞서 언급했듯이(PR 의견에서) FormulaNumber 에는 여기와 사양의 모든 계산 예제에 포함된 '공백'이 포함되지 않습니다. FormulaNumber에는 이 컨트롤에서 지원하지 않는 수학 기호도 포함됩니다.
나는 '숫자'에 투표한다
숫자
공식 번호

SavoySchuler 에 2019년 06월 06일

@SavoySchuler re this

값/텍스트 변경 이벤트는 모든 변경(드래그/스크롤 사용자가 범위를 테스트하는 경우)에서 발생하므로 "Enter"를 누르거나 초점을 잃을 때까지 오류 메시지와 표시기가 표시되는 유효성 검사가 계속 발생할 수 있습니다. 이 경우 유효성 검사 값 재정의가 시작되고 마지막 좋은 값을 덮어씁니다(해당 속성에 의해 해당 동작이 비활성화되지 않는 한).

ValueChanged 이벤트는 Text 변경될 때마다가 아니라 실제 Value 변경될 때만 발생해야 합니다.

해당 동작이 해당 속성에 의해 비활성화되지 않는 한

이 새 속성은 무엇입니까?

마지막으로 알려진 양호한 값으로 되돌릴 때 잘못된 값 및 오류 상태가 손실되는 문제를 얼마나 자주 이벤트가 해결하는지 모르겠습니다.
이것이 실제로 어떤 것인지 이해하려면 여기에서 약간의 실험이 필요하다고 생각합니다. (시간만 구할 수 있다면...)

질문 시간: 16진수 또는 2진수 지원이 필요한 실제 앱 시나리오가 있는 사람이 있습니까? 최대/최소 값을 래핑하시겠습니까?

SavoySchuler 에 2019년 06월 07일

ValueWrap 속성과 같은 것이 여기에서 의미가 있는지 확인하고 싶었습니다.

예, 각도 속성과 같은 경우 359 → 0, 기본적으로 mod 360으로 가고 싶습니다. 재미있는 점은 MaxValue가 포괄적일 수만 있기 때문에 컨트롤(Qt에 있음)을 하위 클래스로 분류해야 했기 때문에 359 또는 360, 그러나 나는 정말로 359.99를 쓸 수 있기를 원했지만 360은 쓸 수 없었습니다(즉, 나는 ≤이 아니라 <를 원했습니다).

QSpinBox에는 해당 목적을 위한 래핑 속성이 있습니다. https://doc.qt.io/qt-5/qabstractspinbox.html#wrapping -prop

adrientetar 에 2019년 06월 07일

👍1

@SavoySchuler 16진수와 관련하여 16진수 편집기가 그것을 원할 수 있다고 생각하지만 정말 틈새 사용 사례처럼 보입니다. 가능한 모든 것을 지원할 필요는 없습니다. 컨트롤이 하위 클래스화하기 쉬운지 확인하기만 하면 됩니다. Qt에서 컨트롤에는 텍스트 상자 문자열을 재정의할 수 있는 숫자 값(int 또는 double)으로 변환하는 메서드가 있습니다.

예를 들어 IsInvalidInputOverwrite가 활성화되고 StepSize=0.2, MaxValue=3.0이고 값 2.9가 증가하면 3.1이 유효하지 않은 것으로 등록되고 2.9로 다시 덮어씁니다.

이 경우 MaxValue로 고정할 수 있습니다.

adrientetar 에 2019년 06월 07일

👍1

@Savoyschler @xyzzer @mrlacey 트위터에서 20H1에 예측 텍스트 입력을 제공하는 무언가가 있다는 것을 보았습니다.

이것은 우리가 이야기한 미리보기 완성 기능을 방해할 수 있으며 NumberBox 컨트롤에서 억제해야 할 수도 있습니다. Win32 및 XAML 컨트롤에 오는 것 같습니다 ...

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

mdtauk 에 2019년 06월 07일

👍1

16진수 또는 2진수를 처리하는 것이 전화 번호 및 우편 번호와 같은 "숫자처럼 보이는 문자열"을 처리하는 것보다 훨씬 더 전문화된 시나리오라고 가정합니다. (그리고 자신의 복잡성을 가져옴)
따라서 NumberBox 컨트롤의 범위를 벗어나야 한다고 생각합니다.

mrlacey 에 2019년 06월 07일

👍1

미리보기 계산 기능에 대해 말하자면, 놓친 경우를 대비하여 사용자에게 켜기/끄기 선택권을 제공하는 것이 좋습니다. 그래서 아마도 다음과 같은 속성을 추가할 것입니다.

public bool ShowPreviewResult { get; set; }

Felix-Dev 에 2019년 06월 07일

👍1

미리보기 결과를 표시하는 이유는 무엇입니까? 🤔 사용자가 결과에 따라 수식을 변경하는 것처럼 원하는 결과를 알면 바로 입력합니다.

adrientetar 에 2019년 06월 07일

미리보기 결과를 표시하는 이유는 무엇입니까? 🤔 결과에 따라 사용자가 입력하는 것과 달리 원하는 것을 안다면 바로 입력합니다.

컨트롤의 기능 중 하나는 128로 해석되는 32 * 4 와 같이 계산에 입력할 수 있다는 것입니다. 미리보기 기능은 컨트롤이 포커스를 잃거나 Enter 키를 눌렀을 때 결과가 무엇인지 보여줍니다.

mdtauk 에 2019년 06월 07일

@adrientetar 미리보기는 현재 잠정적인 기능입니다. 컨트롤의 유효성 검사가 시작되기 전에 값이 부분적으로 사용자 지향 유효성 검사에 있을 것이라고 생각합니다. 예: 기대 확인("더하기 대신 시간을 쳤나요?"). 여기에 이자 및 투자 수익이 아직 명확하지 않습니다.

다시 한 번 피드백 주셔서 감사합니다. 여러분! 현재로서는 2진 또는 16진 지원에 대한 긴급한 필요나 관심이 없는 것처럼 보입니다. 또한 필요에 따라 하위 분류되거나 새로운 컨트롤로 제안되거나 V2에 대해 제안될 수 있습니다.

SavoySchuler 에 2019년 06월 08일

@SavoySchuler 는 "16진수 또는 이진수에 대한 지원이 필요한 것을 정당화하는 실제 앱 시나리오가 있는 사람이 있습니까?"와 관련하여 WinUI의 자체 ColorPicker 컨트롤을 예로 들 수 있습니다. 여기에는 16진수 입력 상자가 포함됩니다. 또한 여러 다른 숫자 입력 TextBox를 포함합니다. 새 컨트롤의 유효성을 검사하는 방법으로 새 NumberBox 컨트롤을 사용하도록 ColorPicker를 업데이트할 가능성을 조사해 볼 가치가 있습니다. NumberBox가 ColorPicker의 현재 구현을 단순화할 수 있다면 그것이 승리가 될 것입니다.

kmahone 에 2019년 06월 08일

👍1

텍스트 상자의 더 얇은 테두리 스타일이 @chigy 및 WinUI 디자인 팀의 의사 결정을 통과하지 못한 경우 - 텍스트 상자 디자인에 대한 현재 제안과 일치하는 디자인 목업을 준비해야 한다고 생각했습니다.

number box - uwp styled

mdtauk 에 2019년 06월 09일

❤1 👍1

@kmahone - 동의합니다. 오늘 아침 정수기에서 언급했듯이 TextBox + 로컬 유효성 검사 논리의 인스턴스를 NumberBox로 교체하여 ColorPicker에서 많은 코드를 제거할 수 있다는 것은 그 자체로 승리가 될 수 있습니다.

@mdtauk - 당신의 목업이 믿을 수 없을 정도로

SavoySchuler 에 2019년 06월 11일

@SavoySchuler Windows 디자인 팀이 Fabric 웹 팀의 편에 서서 2epx 두께의 테두리에서 1epx 테두리로 이동하기로 결정했다면 NumberBox와 가장 잘 작동할 것이라고 생각하지만 실용적이라면 Windows 디자인 팀이 파헤칠 수 있습니다. 그들의 발 뒤꿈치를 넣고 더 두꺼운 테두리를 유지하십시오.

mdtauk 에 2019년 06월 11일

👍2

물론이죠, @mdtauk! 조만간 @KevinTXY에 대한 기능 요구 사항을 @chigy (#524에서 놀라운 일을 하느라 바빴던)와의 디자인 컨버전스 대화로

SavoySchuler 에 2019년 06월 12일

모든 토론에 감사드립니다. 이번 여름에 인턴으로 이 기능을 작업하게 되어 기쁩니다!

누군가와 관련이 있는 경우 다음 저장소에서 컨트롤의 C# 프로토타입을 시작했습니다.
https://github.com/KevinTXY/NumberBox

이것은 본질적으로 처음으로 C#/UWP를 배우는 것이므로 천천히 따라갈 것이고 누군가 그것을 보면 더 잘할 수 있는 것에 대한 피드백을 받게 되어 기쁩니다!

다음과 같은 기능이 대략적으로 구현됩니다.

숫자 입력 유효성 검사(아직 유효성 검사 제안 사양을 따르지 않음, 코드에서 대기함)
가치 저장/결합
제로 트리밍
전체 계산기/수식 입력 지원

현재 스피너 버튼 및 테스트 앱 항목 및 최소/최대 유효성 검사 작업을 하고 있습니다.

건배!

KevinTXY 에 2019년 06월 13일

👍5 🎉2

타임라인 업데이트!

나는 오늘(목요일) WinUI 팀과 함께 검증할 사양에 몇 가지 업데이트, 제안 및 피드백을 통합했습니다. 그렇게 함으로써 V1에 대한 API 및 행동 구성 요소를 어느 정도 마무리하고 싶습니다.

이제 입력 및 접근성, 데이터 및 인텔리전스, 시각적 구성 요소로 이동할 것입니다.

마지막 단계는 문서를 정리하고 지침을 구성하는 것입니다.

SavoySchuler 에 2019년 06월 13일

👍2

Microsoft의 퍼스트 파티 앱/셸 UI가 WPF 또는 Win32에서 수행해야 하는 사용 사례가 없으면 연결되지 않고 연속적인 옵션이 매우 틈새 시장이라고 생각합니다.

포함하고 싶다면 옵션보다는 컨트롤에 적용할 수 있는 포함된 스타일이 되었으면 합니다. 다시 템플릿화된 NumberBox 컨트롤은 새 템플릿에서 해당 속성을 어떻게 처리할까요?

이 모드가 포함되어야 한다는 합의가 있는 경우 SpinButtonPlacementMode 의 일부로 열거형 값이 되도록 제안할 수 있습니다. 이 옵션의 이름이 무엇인지 확실하지 않습니다. _Straddled_는 아마도 충분히 전문적이지 않을 것입니다. 그리고 _Bookended_가 더 나은지 잘 모르겠습니다.

mdtauk 에 2019년 06월 13일

😄1 👍1

Edge의 최신 Canary 빌드를 보고 있었는데 NumberBox 컨트롤에 가장 가까운 <input type="number"/> 의 디자인을 보았습니다.

이 이미지를 공유해야겠다고 생각했습니다.

mdtauk 에 2019년 06월 18일

👍1

@mdtauk - 동의, SpinButtonPlacementMode는 대체 SpinButton 배치 옵션을 추가하기에 적합한 장소입니다.

이름 주제에 대해 @Felix-Dev는 SpinButton이 가장 직관적이거나 잘 알려진 이름이 아닐 수 있다는 사양을 올바르게 나타냈습니다. SpinBox 및 UpDownButtons도 Windows 생태계에서 우선합니다. 곧 더 자세히 살펴보겠지만 이러한 옵션에 반대하는 사람이 있으면 알려주세요.

@mdtauk - 공유해주셔서 감사합니다! 나는 Canary도 실행 중이므로 우리가 배울 수 있는 것이 있는지 또는 개발을 조정하는 것을 제안할 여지가 있는지 살펴보고 확인하겠습니다!

SavoySchuler 에 2019년 06월 19일

@SavoySchuler Fluent Controls 플래그 활성화(실험적 컨트롤 포함)를 사용하고 있습니다.

WinUI 구현은 Fabric Web과 Edge가 살펴보아야 하는 보다 신중한 디자인이 될 것이라고 생각하지만 정렬은 좋은 일입니다.

w3schools 입력 유형 번호

또한 해당 슬라이더는 WinUI가 계획하는 것과 비슷하지만 완전히 같지는 않습니다(채워진 원 썸과 비교하여 윤곽선이 있는 원 썸)

mdtauk 에 2019년 06월 19일

👍1

현지화 기능을 설정하는 방법을 아직 잘 모르겠습니다. 미국에서는 소수점 구분 기호로 점이 사용됩니다. 내가 사는 네덜란드에서는 쉼표를 사용합니다. 미국에서는 그룹화 구분 기호가 쉼표이지만 네덜란드에서는 점입니다.

예시:

Framework 요소의 Language 속성을 사용하여 Digit 및 Grouping 구분 기호를 지정해야 합니까?

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

sonnemaf 에 2019년 06월 19일

Edge의 최신 Canary 빌드를 보고 있었는데 NumberBox 컨트롤에 가장 가까운 <input type="number"/> 의 디자인을 보았습니다.

이 이미지를 공유해야겠다고 생각했습니다.

@mdtauk , @SavoySchuler ,
이 컨트롤이 어디에서 왔는지 모르겠습니다. Edge 팀의 내 연락처에 따르면 다음은 그들이 사용할 컨트롤입니다.

슬라이더: https://explore.fastdna.net/components/slider/
숫자 상자: https://explore.fastdna.net/components/number-field/

그들이 비주얼을 업데이트할 것인지 확실하지 않고 최종 출력이 정확히 이와 같지 않을 수도 있습니다(그렇다고 생각하지만 제 추측입니다).

chigy 에 2019년 06월 19일

@chigy 그 이미지는 Edge의 현재 Canary 빌드에서 가져온 것이지만 언급했듯이 WIP이며 설정하는 선택적 플래그입니다.

이전 호에서 언급한 fastdna 프로젝트가 무엇을 위한 것인지 설명하는 것 같습니다. 🙂

mdtauk 에 2019년 06월 19일

👍2

Framework 요소의 Language 속성을 사용하여 Digit 및 Grouping 구분 기호를 지정해야 합니까?

이러한 설정은 일반적으로 "영역"에서 가져 오므 로

DecimalFormatter API에서 구분 문자를 사용자 정의하는 방법이 표시되지 않으므로 언어 설정에서 가져와야 합니다. 😖

jevansaks 에 2019년 06월 25일

👍1

@jevansaks , 통찰력 주셔서 감사합니다! @sonnemaf 가 답장을 볼 수 있도록 태그를 지정

SavoySchuler 에 2019년 06월 26일

@jevansaks xaml 예제를 NumberBox의 DecimalFormatter에 어떻게 작성할 수 있습니까? 코드 숨김이 아닌 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>

sonnemaf 에 2019년 06월 26일

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

침입해서 죄송합니다. 방금 이 주제를 발견했지만 YES YES YES입니다. 둘 다 숫자 컨트롤에서 자주 누락되며 저와 github의 다른 많은 개발자는 이에 대한 해결 방법을 빌드해야 합니다. 특히 계산기 예제에서는 숫자를 16진수로 형식화할 뿐만 아니라 입력을 완벽하게 지원해야 합니다.

현재로서는 16진수의 접두사를 사용자 정의할 수 있도록 하는 것이 좋습니다. 어떤 시점에서는 접두사가 전혀 없는 것이 더 좋고 다른 시점에서는 항상 0x 가 아닙니다.

Symbai 에 2019년 06월 26일

🎉1 👍1

NumberBox의 DecimalFormatter에 대한 xaml 예제를 작성할 수 있습니까? 코드 숨김이 아닌 XAML에서 정의하고 싶습니다. DecimalSymbol 및 GroupingSymbol 속성을 갖는 것도 저에게 효과적입니다. 하지만 이것은 너무 쉬울 수 있습니다.

@sonnemaf WinRT에서 작업해야 하는 모든 것은 DecimalFormatter이며 불행히도 이러한 설정을 사용자 지정할 수 없습니다. 소수 기호 또는 그룹화 기호를 사용자 정의하는 유일한 방법은 OS의 지역 제어판에서 사용자 설정을 사용하는 것입니다(내가 말할 수 있는 한).

이러한 설정에 대해 사용자 지역을 존중하는 것이 올바른 것처럼 보이지만 이를 재정의해야 하는 시나리오가 있습니까?

jevansaks 에 2019년 06월 26일

👍1

@sonnemaf

16진수 또는 2진수에 대한 지원이 필요한 것을 정당화하는 실제 앱 시나리오가 있는 사람이 있습니까?

이 점을 인지하고 답변이 조금 늦어 죄송합니다. 16진법/2진법 지원이 매우 도움이 될 것이라고 생각합니다. 저는 .NET IoT 프로젝트에 많이 관여하고 있으며 레지스터에 읽고 쓰는 비트/바이트를 조작하고 사물을 제어하기 위해 고정하는 비트/바이트를 조작할 때 주로 16진/2진 세계에서 작업합니다.

16진수/2진수를 지원하면 매우 감사할 것입니다. 😄

shaggygi 에 2019년 07월 04일

👍1

16진수나 바이너리가 필요하지 않습니다. '있으면 좋을 것', 특히 바이너리입니다.

sonnemaf 에 2019년 07월 04일

👍1

개발자 업데이트

안녕하세요 여러분! 우리는 NumberBox 사양에 만족하고 있으며, 컨트롤에 대해 적극적으로 작업하고 있다는 점을 강조하고

몇 가지 참고 사항:

특히 InputValidation과 관련된 몇 가지 디자인 복잡성으로 인해 TextBox를 하위 클래스로 분류하지 않기로 선택했습니다. NumberBox는 TextBox를 포함하는 자체 컨트롤이 됩니다.
- 이것은 모든 TextBox 속성이 노출되지 않음을 의미합니다. 이 중 어떤 것이 NumberBox로 가져오는 데 중요한지 궁금합니다. _Header, PlaceHolderText_ 및 아마도 _Text_에 대한 욕구를 볼 수 있습니까? 내 끝에서 만들 수 있는 매우 쉬운 변경이기 때문에 확실히 이것을 조금 열고 싶었습니다.
사양을 아주 약간 수정했습니다. 지금은 대부분 단어 수정에 불과하지만 값 미리보기와 같은 미해결 질문이 있으며 컨트롤을 작성할 때 저만의 디자인 질문을 생성하고 있습니다. 아직 입력을 추가하기에 좋은 시기입니다 😄

KevinTXY 에 2019년 07월 10일

👍4

@KevinTXY TextBox가 아닌 Slider 기반에서 파생되는 제안이 하나 있습니다. 이것이 선택된 것입니까?

PlaceHolderText
헤더
텍스트
검증 아이콘
검증 메시지
선택전경
선택 배경
포커스 상태/자원 등

이것들은 내가 필요하다고 생각하는 TextBox의 일부입니다. 긴 텍스트 문자열에 더 적합한 "일반 텍스트" 버튼이 확실하지 않습니다.

밸류미리보기 V2 기능인줄 알았는데 바뀌었나요? 슬라이더 컨트롤에는 엄지손가락이 미끄러질 때 값을 표시하는 도구 설명이 있습니다. 나는 이것을 처리하는 한 가지 방법으로 제안했으며 유효성 검사 메시지를 사용하여 처리하거나 인라인으로 표시했습니다.

인라인은 Windows Insider가 도구 설명으로 표시되거나 텍스트 필드 내에 표시되는 예측 텍스트 완성을 실험적으로 구축한다는 사실에 문제가 있습니다. 어떤 미리보기 방법을 선택하든 이 방법과 충돌하거나 이 컨트롤에 대해 해당 예측 기능이 꺼져 있으면 안 됩니다.

mdtauk 에 2019년 07월 10일

👍1

@KevinTXY TextBox가 아닌 Slider 기반에서 파생되는 제안이 하나 있습니다. 이것이 선택된 것입니까?

NumberBox는 현재 TextBox를 확장하는 대신 태그에 TextBox를 포함하는 자체 컨트롤(Windows.UI.Xaml.Controls.Control 확장)입니다. 슬라이더는 흥미롭게 들리지만 구현이 약간 해킹될 수 있다고 생각합니다. 이러한 컨트롤에는 NumberBox에 속하지 않는 속성도 많이 있습니다. 저는 PM은 아니지만 이것을 개발한 경험에 비추어 볼 때 이것이 개발을 단순화하고 향후 확장성을 위한 좋은 방법이라고 생각합니다.

이것들은 내가 필요하다고 생각하는 TextBox의 일부입니다. 긴 텍스트 문자열에 더 적합한 "일반 텍스트" 버튼이 확실하지 않습니다.

이것은 굉장합니다 - 정확히 내가 찾던 것입니다! 이 모든 것에는 가치가 있다는 데 동의합니다. 모두 지우기 버튼은 현재 TextBox의 기본 기능이므로 거기에 있습니다. 아직 비활성화할 생각은 하지 않았지만 큰 항목이나 터치 스크린 사용자에게 가치가 있다고 생각합니다. 나는 적어도 내가 언급한 세 가지(Header, PlaceholderText, Text)를 미리보기로 가져오려고 노력할 것입니다.

가치 미리보기에 관해서는 아무것도 확정되지 않았으며 사양에 공개 질문으로만 있습니다. 가장 쉬운 임시 솔루션은 개발자가 원하는 대로 표시할 미리 보기 값을 노출하는 것이라고 생각합니다. 이는 미리 보기 버전의 범위에 쉽게 포함될 수 있지만 @SavoySchuler & Co.가 호출하도록 남겨 두겠습니다. 내가 수학 엔진을 연구하는 동안 최소한 며칠 동안은 계산이 내 PR에 포함되지 않을 것이므로 긴급한 세부 사항은 아닙니다. 연구에 감사드립니다. 여기에 흥미로운 아이디어가 많이 있습니다!

KevinTXY 에 2019년 07월 11일

👍1

@KevinTXY 이상적으로는 내장될 수 있는 기본 계산 엔진을 만들고 이 컨트롤과 함께 논의된 CalculatorPicker 아이디어와 함께 향후 사용을 위해 Calculator 팀과 협력하는 것입니다. (표준 계산기로 플라이아웃을 표시하는 계산기 버튼이 있는 컨트롤)

mdtauk 에 2019년 07월 11일

👍2

사실, Calculator 메인테이너와의 협업은 좋은 아이디어처럼 들립니다. 계산기에서 수학 계산을 수행하는 앱 서비스를 노출할 수 있으므로 WinUI 바이너리를 로드할 필요도 없습니다. 앱이 설치되어 있으면 앱 서비스에 알리고 그렇지 않으면 조용히 실패합니다.

Slider에서 파생에 관해서 - 나는 실제로 RangeBase 라고

xyzzer 에 2019년 07월 11일

👍3

아 예, RangeBase, 그게 전부였습니다.

계산기는 최근에 항상 맨 위에 있는 CompactOverlay 모드를 지원하는 작업을 완료했습니다. 따라서 CalendarFlyout과 비슷한 크기의 플라이아웃에 더 작은 키패드를 가져오는 것이 더 쉽게 달성할 수 있습니다. (CalculatorBox 컨트롤이 포함되도록 승인된 경우.

앱 서비스(WinUI 업데이트를 연결하는 계산기 저장소 업데이트에 반 의존적)인지 또는 WinUI에 추가되고 계산기의 엔진에서 파생될 수 있는 서비스 바이너리인지 확실하지 않습니다.

mdtauk 에 2019년 07월 11일

👍2

업데이트: 이제 코드 PR 이 존재합니다 🎆!

나는 거기에서 몇 가지 문제를 추적하고 있지만 대부분은 디자인과 관련이 없습니다.

KevinTXY 에 2019년 07월 12일

👍1

@xyzzer 와 @mdtauk 감사합니다! RangeBase를 확인했으며 TextBox를 서브클래싱하는 것만큼 많은 짐을 운반하는 것으로 보입니다. 지금으로서는 컨트롤에 TextBox를 포함하고 필요한 속성과 접근성 기능만 추가하는 방식을 고수할 것입니다. 이것은 여전히 가치 있는 고려 사항이었고 현재 진행 중인 접근성 대화를 알리는 데 도움이 되었습니다.

@mdtauk , 시작 목록에 감사드립니다! @KevinTXY 는 귀하가 나열한 API를 공개하기 시작했으며 나머지는 곧 검토하겠습니다.

언급된 @KevinTXY 와 같은 미리보기 및 팝업 계산기(여기서 v1 보장 없음). 우리는 정렬 및 활용 가능한 작업에 대해 계산기와 적극적으로 대화하고 있습니다. 당신들은 멋진데! 이 컨트롤에 대한 혁신을 계속 추진해 주셔서 감사합니다. 그것은 굉장. @KevinTXY 는 위에 자신의 코드 PR을 게시했습니다. 지침 및 문서 초안 작성으로 넘어가기 직전에 사양에 나머지 느슨한 부분을 모두 묶을 것입니다.

SavoySchuler 에 2019년 07월 13일

네이밍

사양이 저에게서 멀어졌다는 의견이 너무 많아서 상황이 진정 된 후 살펴보기 시작했습니다. 먼저 C# 규칙을 따르지 않는 이름 지정을 발견했습니다. 예, 이러한 컨트롤이 C++로 작성된 것을 알고 있지만 여전히 플랫폼의 다른 이름 지정과 일치하지 않는다고 생각합니다.

| 유형 | 현재 이름 | 제안된 이름 |
|---------|----------------|-------------------|
| 부울 | 수락계산 | IsCalculationAccepted |
| 부울 | HyperDrag 활성화 | IsHyperDragEnabled |
| 부울 | 하이퍼스크롤 가능 | IsHyperScrollEnabled |

단계 주파수

또한 StepFrequency는 무엇입니까? 이것은 사양에 정의되어 있지 않으며 "XAML Toolkit의 NumericUpDown"에 대한 경험이 없습니다. 이것이 수행하는 작업에 따라 Frequency라는 단어를 추가하는 것이 의미가 없을 수 있습니다. 그것은 아마도 "단계"일 것입니다. 슬라이더 컨트롤에서 TickFrequency는 전체 최대-최소 범위의 계수에 틱이 표시되기 때문에 의미가 있습니다. 그러나 이 컨트롤에서는 이것이 단지 최소 증분/단계 크기라고 생각합니다. 기본적으로 사용자가 단계 외부의 값을 입력할 수 있습니까?

예를 들어 MinValue = 0, MaxValue = 6, StepFrequency = 2입니다. 위쪽 화살표 값을 사용하면 {2, 4, 6}이 충분히 공정합니다. 사용자가 유효한 값으로 0.5를 입력할 수 있습니까? 아니면 RoundingMode에 따라 0 또는 2로 반올림됩니까?

최소/최대값

아래 두 속성의 경우 다른 컨트롤(Slider, RangeBase)에서와 같이 최소값과 최대값이어야 한다고 생각합니다. API는 일관성이 있어야 합니다.
이중 최소값;
더블 MaxValue;

위아래 반복 버튼

내가 아는 한 논의되지 않은 또 다른 기능은 위/아래 버튼을 실제로 RepeatButton으로 만들지 여부입니다(그래야 한다고 생각합니다). 반복 버튼인 경우 Slider 컨트롤처럼 Delay/Interval 속성을 추가해야 합니다. Slider.Interval Slider.Delay

숫자

IntegerDigits 및 FractionDigits가 나타내는 것에 대한 설명을 추가할 수 있습니까? 내 생각에 그들은 숫자의 각 부분에 대한 자릿수를 제한합니다. IntegerDigits = 2는 최대값이 99가 될 수 있음을 의미합니다. FractionDigits = 3은 MaxValue가 0.999가 될 수 있음을 의미합니다. 또한 SignificantDigits는 이 두 속성을 어떻게 재정의합니까?

네거티브 제로?

이 속성이 필요한 이유는 무엇입니까? 로컬라이제이션 그 자체인가요? "-0.0" 또는 "-0"을 본 적이 없습니다. 항상 "0"입니다.
부울 IsZeroSigned;

현지화

UI 현지화 및 숫자 형식 재정의를 지원하려면 이 컨트롤이 필요합니다. 다르게 표시되어야 하는 현지 및 해외 금액이 필요한 여러 용도(금융 앱)가 있습니다. 스펙 어디에서도 볼 수 없습니다.

robloo 에 2019년 07월 15일

👍3

이중에서 텍스트로 변환하는 것은 Slider.ThumbToolTipValueConverter의 정신에 따라 ValueConverter를 통해 사용자 정의할 수 있어야 합니다. 이러한 방식으로 가장 복잡한 부분은 아래의 실제 사례와 같이 모든 요구에 맞게 사용자 정의할 수 있습니다.

숫자와 돈에 대한 소수 구분 기호가 다를 수 있고 음수의 지정도 다를 수 있으므로 ValueConverter가 없는 NumericBox에 대한 가장 안전한 접근 방식은 정수 모드에서 작동하는 것입니다. 계산기도 ValueConverter로 구현할 수 있으므로 이 작업으로 컨트롤에 과부하가 걸릴 필요가 없습니다.

eugenegff 에 2019년 07월 15일

👍3

@eugenegff 숫자를 문자열로의 변환을 일반화하는 좋은 아이디어가 있습니다. 이렇게 하면 현지화를 처리할 수 있을 뿐만 아니라 개발자가 단위 추가와 같이 원하는 모든 작업을 수행할 수 있습니다.

내가 볼 수있는 유일한 복잡성은 컨트롤과 관련된 Culture/NumberFormatInfo를 유지하는 것입니다. 사용자 지정 IValueConverter로 이동하는 XAML의 변환기 매개 변수일 수 있지만 컨트롤 자체에서 이를 처리하는 더 깨끗한 방법이 있어야 합니다.

robloo 에 2019년 07월 15일

이 속성이 필요한 이유는 무엇입니까? 로컬라이제이션 그 자체인가요? "-0.0" 또는 "-0"을 본 적이 없습니다. 항상 "0"입니다.

Windows의 DecimalFormatter 클래스 속성입니다. 이상해? 아마. 우리가 생략한 IsGrouped 및 지역화 속성과 같은 일부 속성이 있으므로 이 속성도 필요하지 않을 수 있습니다. 동시에 이미 구현되어 있으므로 제거하는 것은 3줄의 코드를 부풀리는 것 외에 다른 목적이 없습니다. 흥미롭게도 부호 있는 0을 갖기 위한 용도와 IEEE 전제 조건이 있습니다.

UI 현지화 및 숫자 형식 재정의를 지원하려면 이 컨트롤이 필요합니다. 다르게 표시되어야 하는 현지 및 해외 금액이 필요한 여러 용도(금융 앱)가 있습니다. 스펙 어디에서도 볼 수 없습니다.

@SavoySchuler 아마도 DecimalFormatter 클래스에서 언어 설정 지원을 살펴봐야 할까요? 나는 그것이 어떻게 행동하는지 잘 모릅니다.

KevinTXY 에 2019년 07월 16일

👍1

좋아, 나는 여기서 근본적인 문제를 이해하고 있다고 생각한다. C++ 세계에서는 DecimalFormatter에 액세스할 수 있지만 C# 세계에서는(WinUI를 사용하는 경우) 일반적으로 IFormatProvider(지정된 Culture의 NumberFormatInfo)를 사용합니다. NumberFormatInfo에는 이미 대부분의 속성이 있으므로(동시에 IsZeroSigned가 누락됨) 개발자가 해당 또는 IFormatProvider를 지정할 수 있도록 허용하는 것으로 생각했습니다. 음, 문제가 있습니다. C++는 .net 세계의 IFormatProvider를 사용할 수 없습니다.

그렇다면 이 컨트롤은 두 가지 다른 방법이 있다는 점을 고려할 때 C# 및 C++에서 현지화를 어떻게 완벽하게 지원할까요? 글쎄요, 마이크로소프트가 영리한 솔루션을 가지고 있지 않다면 저는 두 가지 가능성만 생각할 수 있습니다.

숫자 서식에 대한 모든 속성을 완전히 추가합니다(NumberFormatInfo 및 DecimalFormatter를 효과적으로 다시 구현). IsZeroSigned, IntegerDigits, FractionalDigits 등만 추가해도 해결되지 않습니다. NumberNegativePattern, NumberGroupSeparator, NumberGroupSizes 등도 모두 필요합니다.
@eugenegff가 제안한 대로

이 컨트롤에서 현지화가 어떻게 형성되고 있는지 약간 걱정됩니다. 저는 처음부터 현지화를 제기했습니다(이 주제에 대한 세 번째 의견!). 컨트롤이 문자열로 변환될 때 숫자 형식을 완전히 사용자 지정하는 방법이 있어야 합니다. 그것이 없으면 이 제어는 실제 사용에서 상당히 제한될 것입니다.

robloo 에 2019년 07월 17일

👍2

그렇다면 이 컨트롤은 두 가지 다른 방법이 있다는 점을 고려할 때 C# 및 C++에서 현지화를 어떻게 완벽하게 지원할까요?

우리는 당신을 듣고! 그것은 우리가 오프라인에서 조사해 왔지만 근본적으로 .NET은 플랫폼과 별개로 자체 현지화를 수행합니다. 무시하기 위한 콜백은 훌륭한 탈출구라고 생각하지만 귀하의 옵션 1이 우리가 갈 수 있는 경로가 되기를 바랍니다. 현재 서식 지정 및 구문 분석을 위한 WinRT API에는 필요한 모든 사용자 지정 노브가 없습니다. 아직 조사 중입니다.

jevansaks 에 2019년 07월 17일

👍2

이것이 이미 논의되었는지 확인하지 않았지만 누구든지 다음 중 하나 이상을 의미하는 계산을 위한 함수 지원에 대한 큰 필요성이나 더 중요한 선례를 보는지 빨리 묻고 싶었습니다.
cos(), sin(), tan(), asin(), acos(), atan(), sqrt(), log(), abs(), ceil(), floor(), degree equivalents of trig functions, hyperbolic functions, etc

저는 우리의 필요에 맞게 수학 파서를 꿰매고 있으며 기능은 RPN으로 변환하는 과정을 복잡하게 만듭니다. 문제 또는 부풀어 오르는 것처럼 보이는 경우. 개인적으로 너무 잘 맞는다고는 생각하지 않지만, 전례가 많다면 크게 문제될 정도는 아니다.

KevinTXY 에 2019년 07월 23일

대부분의 경우 이러한 기능을 검색하기가 쉽지 않으며 더 복잡한 기능에 대한 지원이 필요한 경우 사용자가 자신의 구문 분석 또는 사전 처리 논리를 구현할 수 있도록 콜백 이벤트에 대한 구문 분석을 시작하는 것이 좋습니다.

더 가치있는 것은 연산자로 텍스트 입력을 시작할 수 있다는 것입니다. 따라서 텍스트를 클릭하면 기본적으로 모두 선택되며 이전 값을 삭제하기 위해 먼저 삭제를 누르지 않고 새 값을 입력하거나 단순히 "*1.2" 또는 "x1.2" [Enter] 와 같은 것을 입력하고 입력한 텍스트에 더 이상 입력된 값이 포함되지 않더라도 현재 값에 1.2를 곱합니다. "+2", "-5", "/3", "%120" 등에 대해서도 동일한 작업이 수행됩니다.

일부 전문 응용 프로그램에서 사용됩니다.

xyzzer 에 2019년 07월 23일

👍2

우리(BeLight Software, Live Home 3D 프로젝트)는 값 <=> 텍스트 변환을 위해 플러그형 ValueConverter가 필요합니다. 그렇지 않으면 NumberBox가 적합하지 않습니다.

eugenegff 에 2019년 07월 23일

👍2

이러한 기능을 사용하는 경우는 매우 드물다고 생각합니다. 앱에 각도 입력이 있지만 각도 값일 뿐입니다. 저에게 가장 중요한 용도는 기존에 값을 추가하거나 기존을 숫자로 나눌 수 있다는 것입니다. 시간을 절약하고 정신적으로 계산을 하지 않도록 하는 것입니다. (Btw 내 생각에 Adobe 앱에는 4개의 산술 연산자가 있습니다. https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/suggestions/12992463-support-math-operators-in-number -필드)

또한 cos()와 같은 기능은 일종의 Excel 앱을 만들지 않는 한 이해가 되지 않는 곳에 사용하고 싶지 않을 것입니다.

adrientetar 에 2019년 07월 23일

👍1

나에게 가장 중요한 용도는 기존에 값을 추가하거나 기존을 숫자로 나눌 수 있다는 것입니다. 시간을 절약하고 정신적으로 그 계산을 하지 않도록 하는 것입니다.

큰 확인! @xyzzer가 제안한 것과 비슷합니다. 비슷한 구현을 살펴보고 자연스럽고 직관적인 방식으로 이를 수행할 여지가 있는지 확인하겠습니다.

우리(BeLight Software, Live Home 3D 프로젝트)는 값 <=> 텍스트 변환을 위해 플러그형 ValueConverter가 필요합니다. 그렇지 않으면 NumberBox가 적합하지 않습니다.

나는 당신이 제공한 Slider 예제를 살펴보았고 매우 합리적으로 들렸습니다. NumBox에 대한 IValueConverter의 가치를 볼 수 있었습니다. 곧 살펴보고 사양에 적절하게 맞는지 결정하도록 노력하겠습니다. 아직 아무것도 약속이 없습니다!

KevinTXY 에 2019년 07월 23일

👍2

@KevinTXY 위에서 언급
또한 "숫자 상자는 숫자 전용 텍스트 컨트롤입니다 ..." 사양의 시작 부분에서 설명의 첫 번째 줄을 중단합니다.

mrlacey 에 2019년 07월 25일

👍1

아직 현지화에 대한 질문이 있다는 사실에 놀랐습니다. 컨트롤이 FrameworkElement 에서 상속하므로(반드시?) Language 속성에 액세스할 수 있으므로 다른 모든 FrameworkElement와 마찬가지로 시스템 로캘 UI 설정에 의존하지 않고 로캘 설정을 직접 지원합니다.
즉, 십진수 및 그룹화 문자와 같은 항목을 인스턴스별로 설정할 수 있습니다.

mrlacey 에 2019년 07월 25일

아직 현지화에 대한 질문이 있다는 사실에 놀랐습니다.

문제는 언어가 서식을 제어하는 것이 아니라 지역/문화 설정이라는 것입니다. 현지화는 숫자/통화/날짜/시간 형식이 지역별로 제어되는 반면 올바른 언어로 표시되도록 업데이트된 UI 문자열을 가져오는 것입니다. 추가 정보: https://docs.microsoft.com/en-us/globalization/locale/locale-and-culture. 그리고 문제를 복잡하게 하기 위해 Windows에서는 기본값을 재정의하여 UI에서 로캘 설정을 사용자 지정할 수 있습니다. 따라서 소수점 구분 기호를 기본값 대신 임의의 문자로 지정하고 싶다고 말할 수 있습니다. 그리고 무엇보다도 .NET을 사용하면 앱에서 이를 사용자 지정할 수도 있으므로 개발자는 여기에서 해당 수준의 사용자 지정을 기대합니다.

jevansaks 에 2019년 07월 25일

👍2

문제는 언어가 서식을 제어하는 것이 아니라 지역/문화 설정이라는 것입니다. 현지화는 숫자/통화/날짜/시간 형식이 지역별로 제어되는 반면 올바른 언어로 표시되도록 업데이트된 UI 문자열을 가져오는 것입니다. 추가 정보: https://docs.microsoft.com/en-us/globalization/locale/locale-and-culture. 그리고 문제를 복잡하게 하기 위해 Windows에서는 기본값을 재정의하여 UI에서 로캘 설정을 사용자 지정할 수 있습니다. 따라서 소수점 구분 기호를 기본값 대신 임의의 문자로 지정하고 싶다고 말할 수 있습니다. 그리고 무엇보다도 .NET을 사용하면 앱에서 이를 사용자 지정할 수도 있으므로 개발자는 여기에서 해당 수준의 사용자 지정을 기대합니다.

Language 는 CultureInfo 로 변환되는 값을 사용합니다. 비관리 코드 개발에서는 문화권을 로케일이라고 합니다. 여기에는 소수점, 그룹화, 음수 기호 등에 대한 속성이 포함된 NumberFormatInfo 유형인 NumberFormat 속성이 포함됩니다.

내 이해는 시스템 설정에 의존하지 않고 컨트롤에 특정 형식 지정 또는 기타 현지화 세부 사항을 적용하려는 경우 Language 를 지정하는 것입니다.

속성에 대한 설명은 "FrameworkElement에 적용되는 현지화/세계화 언어 정보를 설정합니다"라고 명확하게 명시합니다.

또는 내가 참조하는 문서를 잘못 이해했지만 링크된 페이지에서 다룬 내용을 모두 뒷받침하는 것 같습니다.
다른 용어를 사용하는 C++ 및 C#의 용어 문제일 수 있습니다.
내가 아는 것은 XAML에서 언어를 설정하는 것이 다른 앱과 다른 컨트롤에서 문화권/로케일을 강제 실행하는 방법이라는 것입니다.

현지화에 관해 내가 본 질문은 특정 숫자 형식 또는 그룹 및 소수점 구분 기호를 강제하는 것에 관한 것입니다. 아니면 컨트롤의 텍스트 기반 속성(Header, PlaceholderText 등)의 현지화에 영향을 주지 않고 이러한 컨트롤을 제어하는 진짜 문제입니까?

mrlacey 에 2019년 07월 25일

Language 는 CultureInfo 로 변환되는 값을 취합니다.

네이티브/WinRT에는 없고 BCP-47 langs 문자열만 얻습니다. 그리고 그것이 문제입니다. .NET에서는 언어 설정 과 형식 설정이 있는 CultureInfo를 묶습니다. WinRT에서는 별개이며 CultureInfo 개체에 해당하는 것이 없습니다.

ICU API 가 우리가 찾고 있는 것을 가능하게 할 수 있다고 들었지만 아직 조사할 기회가 없었습니다.

jevansaks 에 2019년 07월 25일

나는 마이크로소프트가 이것에 대한 총알을 깨고 .net 문화/현지화(CultureInfo)와 네이티브/WinRT 간의 변환 메커니즘을 완전히 구현하는 것을 고려해야 한다고 생각합니다. 이상적으로는 일을 하는 새로운 방식을 고려하지 않을 것입니다.

관리 코드는 대부분의 LOB 앱이 작성되는 것으로 처음부터 올바르게 수행되어야 한다고 생각합니다. WinRT는 .net과 동일한 현지화 메커니즘/기술을 가져와야 하며 변환은 자동이어야 합니다.

훨씬 더 많은 작업이 될까요? 단기: 예, 장기: 아니오. 그러면 NumberBox 컨트롤의 릴리스가 지연될 수 있습니까? 콜백이 단기간에 사용되지 않는 한 아마도.

이것은 올바르게 수행되어야 합니다. 그렇지 않으면 다른 곳에서 문제가 발생할 것입니다. 편집 가능한 CalendarDatePicker 등과 같은 다른 시나리오에서 이미 유사한 문제를 예상할 수 있습니다. (#735)

robloo 에 2019년 07월 27일

👍1

@savoySchuler @jevansaks @chigy @mrlacey @KevinTXY
분명히 FastDNA 팀은 입력 번호 필드 디자인을 위한 Spinner 컨트롤에 대한 작업을 수행하고 있으며 고려할 가치가 있는 제안을 내놓았습니다.

또한 Arrow가 아닌 Chevron을 사용하는 이유에 대해서도 질문했습니다.

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

버튼을 나란히 놓고 스택 확장 디자인을 호버로 사용하면 컨트롤 너비가 너무 좁을 때 아이디어가 될 수 있습니까? 모든 Microsoft UI 프레임워크에서 작동하는 레이아웃에 대한 합의가 있을 수 있습니까?

mdtauk 에 2019년 08월 30일

😕1

@mdtauk , 알려주셔서 감사합니다.
이것이 테스트하고 유용성을 검증하는 디자인인지 FastDNA 사람들과 함께 확인하십시오.

chigy 에 2019년 09월 04일

NumberBox로 돌아가기

좋아 팀,

예상치 못한 휴식에 대해 사과드립니다. 저는 NumberBox 풀 스로틀로 돌아 갔고 @teaP 가 저와 함께 기능 개발자로 합류했습니다! 우리는 이 컨트롤의 미리 보기를 위해 여전히 11월 말을 목표로 하고 있으며 WinUI 2.4가 포함된 안정적인 릴리스를 보게 될 것입니다.

이전 워크플로에는 많은 짐이 있으므로 미해결 질문이나 답변된 질문을 보존하고 @teaP 와 내가 다음에 관한 나머지 미해결 주제 해결을 마치는 새로운 사양 PR로 포팅할 것입니다.

현지화
디자인(특히 위/아래 버튼과 관련하여)
하이퍼스크롤/하이퍼드래그

유효성 검사 항목이 해결되었습니다. @LucasHaines ' 입력 유효성 검사 작업이 WinUI 3.0 및 그 전에 NumberBox 계획 릴리스에 대해 예정되어 있으므로 NumberBox V1에서 지원되는 유효성 검사 모드를 다음과 같이 줄였습니다.

열거형 NumberBoxBasicValidationMode
{
장애가있는,
InvalidInput덮어쓰기,
};

WinUI 3.0 및 필수 입력 유효성 검사 작업이 시작되면 NumberBox V2에서 원래 계획된 IconMessage 및 TextBlockMessage 유효성 검사 모드로 해당 열거형을 확장하려고 합니다.

이제 이전 진행 상황을 모두 정리하고 관련 질문을 게시하고 피드백을 요청할 것입니다. 함께해주셔서 감사합니다. 😄

SavoySchuler 에 2019년 10월 22일

👍4 ❤2 🎉2

휴. 이 일을 스스로 하려고 하는 것이 나에게 가까워지고 있었다.

mrlacey 에 2019년 10월 22일

👍1

ㅎㅎ 수동적으로 계속 했으면 좋았을텐데 이번 학기가 저를 지치게 하네요. 완결이 난거 보니 다행이네요 계속 지켜봐야겠습니다!

KevinTXY 에 2019년 10월 25일

👍2

지금 NumberBox의 초기 커밋이 시작되었습니다!

제발 - 이것은 여전히 dev 및 PM 측 모두에서 활성 문제 추적과 함께 진행 중인 작업임을 명심하십시오. 적절한 링크에서 아직 언급되지 않은 기능에 대한 버그나 일반적인 느슨한 끝을 발견하면 저희에게 알려주십시오. 😊

SavoySchuler 에 2019년 10월 30일

👍3 🎉1

@SavoySchuler , 사양에 대한 새 PR을 열겠습니까? 또한, 특히 NaN 디스플레이와 관련하여 이 댓글 에서 제가 쓴 내용을 확인하셨습니까? 감사 해요.

adrientetar 에 2019년 11월 14일

👍1

@SavoySchuler 지금까지 사양/NumberBox 코드에 대한 몇 가지 의견. 바라건대, 이것에 대한 의견은 사양/문서에도 포함될 수 있습니다. 전반적으로, 이것이 함께 오는 것을 보는 것이 좋습니다!

단계 주파수

여기서 '빈도'라는 단어를 사용하는 것은 저와 어울리지 않습니다. 슬라이더 컨트롤에서 TickFrequency는 틱이 전체 최대-최소 범위의 계수로 계산되고 표시되기 때문에 의미가 있습니다. 그러나 이 컨트롤에서는 증분/단계 크기일 뿐입니다. 'StepAmount' 또는 'StepValue'에 가깝습니다. 'MinimumValue' 대신 'Minimum'과 유사한 'Step'이 더 낫습니다.

또한 사용자가 정의된 단계를 벗어난 값을 입력할 수 있습니까?
예를 들어 Minimum = 0, Maximum = 6, StepFrequency = 2입니다. 위쪽 화살표 값을 사용하면 {2, 4, 6}이 충분히 공정합니다. 사용자가 유효한 값으로 0.5를 입력할 수 있습니까? 아니면 0 또는 2로 반올림됩니까?

반올림

수학적 반올림은 어떻게 처리됩니까? 이는 표현식을 사용하여 통화 값을 입력할 때 특히 중요합니다. 표현식이 계산된 후 사용자 지정 반올림을 지정하거나 제공할 수 있어야 합니다. HalfAwayFromZero는 시작하려고 하는 것이지만 다른 반올림 모드도 허용되어야 합니다.

현지화

NumberBox가 모든 INumberFormatter/ INumberFormatter2 구현을 허용하는지 확인하고 앞으로도 계속 그렇게 할 것입니다(코드에서 구현되는 방식이므로 사양에서도 호출하는지 확인하고 싶습니다). 이를 통해 기존 CurrencyFormatter/DecimalFormatter를 사용하는 것과 비교하여 텍스트 현지화를 완전히 제어할 수 있습니다. 우리가 이에 대한 솔루션을 가지고 있다는 것이 좋습니다!

텍스트 줄 바꿈

편집: 다음 번에 전체 사양을 읽어야 합니다.

~~새 'IsWrapEnabled' 속성을 만든 이유는 무엇입니까?~~ ~~NumberBox에 '텍스트'라는 용어가 잘 적용되지 않는다고 느끼기 때문인가요?~~

~~또한 Wrap과 WrapWithOverflow가 모두 동일하게 구현되지만 두 열거형 값이 동일하도록 허용하고 설명서의 기능을 설명할 수 있다는 것을 이해합니다.~~

KeyboardAccelerator를 올바르게 처리

이 컨트롤이 TextBox보다 키보드 가속기 사용을 더 잘 지원하는지 확인하십시오. 아마도 TextBox가 수정될 때까지/만일 수 없을 것입니다. 하지만 #1435는 정말 많은 추악한 해결 방법을 유발하는 문제입니다. TextBox는 'Ctrl+V' 붙여넣기 자체를 처리한 다음 모든 KeyboardAccelerator가 발생합니다. 그러나 KeyboardAccelerator 내에서는 TextBox가 자체 작업을 수행했음을 알 수 있는 방법이 없습니다.

robloo 에 2019년 11월 26일

👍2

빠른 생각. 값에 각도 글리프를 추가하는 각도 모드 가 있어야 합니다(360° 랩 어라운드에 대한 논리).

°

아니면 이 부록이 TextBox #784에 대한 내 접미사 제안으로 앞으로 더 잘 처리될 것입니까?

mdtauk 에 2019년 11월 26일

👍1

@mdtauk ,

래핑의 경우 실제로 IsWrapEnabled 속성의 용도입니다... 다음에 문서의 끝 부분을 읽어야 합니다.

결론은 기존 API로 원하는 모든 작업을 수행할 수 있다고 생각합니다.

robloo 에 2019년 11월 26일

👍1

@mdtauk ,
래핑의 경우 실제로 IsWrapEnabled 속성의 용도입니다... 다음에 문서의 끝 부분을 읽어야 합니다.
결론은 기존 API로 원하는 모든 작업을 수행할 수 있다고 생각합니다.

나는 Min, Max, Wrap이 그것을 처리한다는 것을 알고 있지만, Degrees는 상자에 대한 명시적인 Angle 모드를 가질 만큼 충분히 일반적입니까? 그리고 내부 값은 숫자일 뿐이고 TextBox 텍스트에 기호를 표시해야 합니다.

mdtauk 에 2019년 11월 26일

@teaP 새로운 Compact SpinButtonMode를 보면 오버레이된 스핀 버튼에 표시 및 숨기기 애니메이션을 추가할 수 있습니까?

또한 ComboBox 및 기타 양식 필드를 플라이아웃 요소와 더 잘 일치시키기 위해 여기에 아크릴을 추가하는 것을 고려하셨습니까?

편집: 다크 테마에서 이 가시성 문제를 수정합니다. TextBox의 초점 색상과 일치시키려는 의도입니까, 아니면 현재 테마 색상과 일치시키려는 의도입니까? 어쨌든 아크릴은 이것을 해결합니다.

mdtauk 에 2019년 11월 26일

@SavoySchuler , 사양에 대한 새 PR을 열겠습니까? 또한, 특히 NaN 디스플레이와 관련하여 이 댓글 에서 제가 쓴 내용을 확인하셨습니까? 감사 해요.

@adrientetar 확실합니다. NumberBox가 비어 있으면 Value 가 NaN(요청한 대로)으로 설정되고 PlaceholderText 가 표시됩니다.

SavoySchuler 에 2019년 11월 26일

🚀1

@SavoySchuler 지금까지 사양/NumberBox 코드에 대한 몇 가지 의견. 바라건대, 이것에 대한 의견은 사양/문서에도 포함될 수 있습니다. 전반적으로, 이것이 함께 오는 것을 보는 것이 좋습니다!
단계 주파수
여기서 '빈도'라는 단어를 사용하는 것은 저와 어울리지 않습니다. 슬라이더 컨트롤에서 TickFrequency는 틱이 전체 최대-최소 범위의 계수로 계산되고 표시되기 때문에 의미가 있습니다. 그러나 이 컨트롤에서는 증분/단계 크기일 뿐입니다. 'StepAmount' 또는 'StepValue'에 가깝습니다. 'MinimumValue' 대신 'Minimum'과 유사한 'Step'이 더 낫습니다.

나는 이 피드백을 @MikeHillberg 와 공유했으며 우리는 지금 그것에 대해 이야기하고 있습니다. 여기의 다른 모든 속성 중에서 자체 문서화하기 위해 우리는 이 추론이 일탈할 만큼 충분히 정당화되어야 하는 "SpinButtonStep" 라인을 따라 무언가를 고려하고 있습니다. 내가 알려 주마. 지적해주셔서 감사합니다!

또한 사용자가 정의된 단계를 벗어난 값을 입력할 수 있습니까?
예를 들어 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' 속성을 만든 이유는 무엇입니까? 이것은 TextBlock.TextWrapping 및 TextWrapping Enum을 사용하는 TextBox/XAML 규칙에 위배됩니다. NumberBox에 '텍스트'라는 용어가 잘 어울리지 않는다고 느끼기 때문인가요?~
~또한 Wrap과 WrapWithOverflow가 모두 동일하게 구현되었지만 두 열거형 값이 동일하도록 허용하고 설명서의 기능을 설명할 수 있다는 것을 이해합니다. 여기에 새 속성을 생성하면 새로운 값 변환기 등이 필요하다는 것을 의미합니다. 기존 규칙을 깨뜨릴 이유가 없다고 생각합니다.~
KeyboardAccelerator를 올바르게 처리
이 컨트롤이 TextBox보다 키보드 가속기 사용을 더 잘 지원하는지 확인하십시오. 아마도 TextBox가 수정될 때까지/만일 수 없을 것입니다. 하지만 #1435는 정말 많은 추악한 해결 방법을 유발하는 문제입니다. TextBox는 'Ctrl+V' 붙여넣기 자체를 처리한 다음 모든 KeyboardAccelerator가 발생합니다. 그러나 KeyboardAccelerator 내에서는 TextBox가 자체 작업을 수행했음을 알 수 있는 방법이 없습니다.

NumberBox는 TextBox를 포함하고 그 위에 속성과 구성을 추가합니다. 더 포괄적인 이해가 있을 수 있으므로 @jevan에 태그를 지정

결국, 멋진 피드백 @roblo! V1 NumberBox가 가능한 한 포괄적이고 완전한지 확인하는 데 시간을 할애해 주셔서 감사합니다! 더 궁금한 점이 있으면 알려주세요. 😊

SavoySchuler 에 2019년 11월 26일

@mdtauk

빠른 생각. 값에 각도 글리프를 추가하는 각도 모드 가 있어야 합니다(360° 랩 어라운드에 대한 논리).
°
아니면 이 부록이 TextBox #784에 대한 내 접미사 제안으로 앞으로 더 잘 처리될 것입니까?

지금까지 NumberBox는 숫자가 아닌 문자의 표시를 지원하지 않습니다(표현식 평가 시 공식 문자도 제거됨).

#784에 대한 귀하의 제안은 지금까지 우리 플랫폼에서 가장 포괄적이라고 생각합니다. 그 제안이 실행되지 않으면 적절한 V2 기능인 NumberBox를 대체 수단으로 생각합니다.

우리는 이미 WinUI 3.0이 필요할 때 NumberBox에 대해 많이 요청된 두 가지 입력 유효성 검사 모드가 차단되었기 때문에 WinUI 3.0과 함께 또는 그 직후에 V2를 출시할 계획입니다. 그래서 V1이 출시된 후에 V2 문제를 열 것이고, 거기에도 이것을 기록해 두도록 노력할 것입니다.

SavoySchuler 에 2019년 11월 26일

여기의 다른 모든 속성 중에서 자체 문서화하기 위해 "SpinButtonStep" 라인을 따라 이 추론이 이탈할 만큼 충분히 정당화되어야 하는 것을 고려하고 있습니다.

나는 StepFrequency가 Slider가 사용하는 것을 보았으므로 우리는 그 용어와 일관성을 유지하려고 노력했다고 생각합니다. 스핀 버튼뿐만 아니라 드래그 및 UIAutomation 공급자 변경 값에도 적용된다는 점을 잊지 마십시오.

jevansaks 에 2019년 11월 26일

@robloo 및 @mdtauk , °에 대해 회신하기 전에 스레드를 더 자세히 읽어야 합니다. NumberBox가 Text 와 Value 긴밀하게 동기화하여 개발자가 잡을 수 있도록 하기 때문에 Text 안에 이 기호를 표시하는 것이 현재 지원되지 않는다고 생각합니다 Text 변환 오버헤드 없이 필요한 유형입니다. 사용 가능한 서식 속성을 통해 이것을 달성하는 방법을 보지 못했지만 방법을 알고 있다면 알려주세요!

우리는 지금 V1 릴리스에 맞서고 있지만 V2의 경우 접두사/접미사/특수 문자를 다시 살펴보겠습니다. 그 사이에 #784에 대한 @mdtauk 의 제안은 지금까지 플랫폼에 대해 제안된 가장 포괄적인 솔루션이라고 생각합니다. 이 제안이 필요한 기능이라면 엄지손가락을 치켜세우고 댓글을 달아주세요.

SavoySchuler 에 2019년 11월 26일

@adrientetar , scroll-to-change는 V1에 적용되었지만 드래그

이 기능을 사용할 시나리오에 대해 더 자세히 설명해 주시겠습니까? 사용자가 이것이 사용 가능하다는 것을 어떻게 알 수 있습니까? 솔루션에서 로컬로 구현된 것과 비교하여 모든 NumberBox에서 이것이 기본(또는 최소한 사용 가능)이어야 하는 이유를 이해하는 데 도움을 줄 수 있습니까?

SavoySchuler 에 2019년 11월 26일

👍1

@SavoySchuler

귀하의 의견에 감사드립니다.

여기의 다른 모든 속성 중에서 자체 문서화하기 위해 "SpinButtonStep" 라인을 따라 이 추론이 이탈할 만큼 충분히 정당화되어야 하는 것을 고려하고 있습니다.

나는 그 용어를 많이 좋아하지만 Slider에 이미 StepFrequency 속성이 있다는 것을 놓쳤습니다. 그것이 사실이기 때문에 @jevansaks가 언급한 것처럼

반올림은 서식을 통해 처리됩니다. 다음은 DecimalFormatter에 대해 설정할 수 있는 반올림 속성의 예입니다.

사용자가 NumberBox에 "1 / 3"을 입력한다고 가정해 보겠습니다. 그렇다면 다음 순서가 맞습니까?

초점을 잃거나 입력하면 표현식이 평가되고 0.33333333...34의 이중 값이 계산됩니다.
0.33333333...34가 DecimalFormatter에 전달됩니다.
0.33333333...34는 설정에 따라 "0.30"으로 반올림될 수 있습니다.
해당 "0.30" 값은 사용자에게 표시하기 위해 TextBox에 입력됩니다.
이중 Value 는 이제 {0.33333333...34}이고 Text 값은 이제 "0.30"입니다.
이중 Value 를 읽으면 Text 표시된 반올림된 숫자가 반환되지 않습니다.
(또는 10진수 형식의 값이 문자열로 변환된 후 어떻게 든 다시 구문 분석된 다음 전체가 다시 평가됩니까?)

또한 Value 및 Text 속성이 내부적으로 너무 밀접하게 결합되어 있다는 점에 대해서도 우려하고 있습니다. 문서는 이 결합을 정의하지 않으며 고도로 구조화된 양방향 종속성이 아니라면 결코 재미가 없습니다.

이것이 내부적으로 어떻게 구현되는지는 확실하지 않지만 이를 수행하는 올바른 방법은 double Value를 유일한 부동산으로 취급하는 것 같습니다. 텍스트는 값의 형식화된 버전일 뿐입니다. 그런 다음 개발자는 원하는 대로 값을 TextBox 및 Text 속성에 표시할 수 있습니다(이전에 요청한 도 기호 또는 피트/인치 기호를 얻음). 모든 것이 이미 Value 속성에 의해 내부적으로 구동된다면 전혀 어렵지 않을 것입니다. 사용자의 텍스트 입력은 어쨌든 유지되지 않으며 표시를 위해 다시 형식이 지정되는 값을 다시 계산하는 데만 사용됩니다.

순서는 다음과 같아야 합니다.

사용자 텍스트 입력 -> 파서 -> 이중 값 -> 서식 -> 텍스트

코드에서 Text 값을 변경하는 것은 사용자가 일부 텍스트를 입력한 것과 같습니다. 값을 직접 변경하면 서식 및 텍스트 단계를 거치게 됩니다.

값과 텍스트 시퀀스 사이의 정확한 반올림을 유지하려면 다음과 같습니다.

사용자 텍스트 입력 -> 파서 -> 값 -> 반올림 -> 값 -> 서식 -> 텍스트

편집: 표현식/입력 파서 및 평가 엔진에서 반올림을 구현하려면(무엇이든 호출됨) RoundingAlgorithm 과 같은 알고리즘을 정의하기 위해 새 속성을 추가해야 할 것입니다. 해당 열거형은 지적한 대로 Windows.Globalization.NumberFormatting에 이미 정의되어 있습니다. INumberFormatter2는 형식화에 사용해야 하며 다른 것은 사용하지 않아야 합니다. 다시 계산과 최종적으로 표시되는 텍스트 간에 단계를 분리된 상태로 유지합니다.

robloo 에 2019년 11월 27일

@adrientetar , scroll-to-change는 V1에 적용되었지만 드래그
이 기능을 사용할 시나리오에 대해 더 자세히 설명해 주시겠습니까? 사용자가 이것이 사용 가능하다는 것을 어떻게 알 수 있습니까? 솔루션에서 로컬로 구현된 것과 비교하여 모든 NumberBox에서 이것이 기본(또는 최소한 사용 가능)이어야 하는 이유를 이해하는 데 도움을 줄 수 있습니까?

하나는 더 크게 증가해야 하고 다른 하나는 더 작아야 합니다 - Adobe 앱에서 선택한 영역/개체를 조금씩 이동하는 것과 유사합니다.

mdtauk 에 2019년 11월 27일

이 기능을 사용할 시나리오에 대해 더 자세히 설명해 주시겠습니까?

시각적 의미(예: 개체 회전)로 값을 변경하고 싶지만 어디까지 가고 싶은지 잘 모를 때 유용합니다. 따라서 시각 디자인에 좋습니다.

사용자가 이것이 사용 가능하다는 것을 어떻게 알 수 있습니까?

Adobe XD, Framer 등 최신 도구에 있는 기능일 뿐입니다.

솔루션에서 로컬로 구현된 것과 비교하여 모든 NumberBox에서 이것이 기본(또는 최소한 사용 가능)이어야 하는 이유를 이해하는 데 도움을 줄 수 있습니까?

터치 장치에 있을 때 이것을 갖는 것이 좋다고 생각합니다. 탭-드래그는 주어진 값을 조정하는 편리한 방법입니다(탭-드래그로 값을 스크롤하는 전화 시간 선택기 위젯과 유사).

adrientetar 에 2019년 11월 27일

하나는 더 크게 증가해야 하고 다른 하나는 더 작아야 합니다 - Adobe 앱에서 선택한 영역/개체를 조금씩 이동하는 것과 유사합니다.

RangeBase에는 SmallChange 및 LargeChange 속성이 있습니다. 우리 BeLight Software의 NumericUpDown 버전은 RangeBase에서 파생되고 ArrowUp 및 ArrowDown 단축키를 사용하는 SmallChange와 PageUp 및 PageDown 단축키를 사용하는 LargeChange에 의해 값을 변경합니다.

그리고 우리는 여기에 혼자가 아닙니다.
https://help.syncfusion.com/uwp/numeric-updown/gestures
https://docs.telerik.com/devtools/wpf/controls/radnumericupdown/features/navigation

eugenegff 에 2019년 11월 27일

커뮤니티 콜 중 떠오른 키보드 숫자 키패드에 대한 한마디...

대부분의 앱에서 "." 키패드 버튼은 여전히 "." 영어가 아닌 언어를 사용할 때 소수점 구분 기호와 다른 문자입니다(예: 프랑스어의 ","). 따라서 "."를 누를 때 메모장에서 키를 누르면 "." 캐릭터.

일부 앱(Excel이 이에 대해 가장 잘 알려져 있음)은 키패드 "."의 키 누름을 재해석하기 위해 이 키 동작을 변경합니다. 소수점 구분 기호 입력으로. 키패드의 "계산기" 디자인과 더 잘 호환됩니다.

계산기 앱은 "." 소수 구분 기호로 해석하려면 를 누르십시오.

numberbox는 "계산기"로 더 많이 작동할 수 있기 때문에 컨트롤에서 "." 키패드의 키를 소수점 구분 기호로 사용합니까? 아니면 최소한 개발자가 주요 필터 및 이벤트와 싸울 필요 없이 이 기능을 추가할 수 있는 방법을 제공해야 합니까?

속성이 기능을 활성화(옵트인인 경우) 또는 비활성화(옵트아웃인 경우)하도록 허용할 수 있습니다. 예를 들어 KeyPadDotAsDecimalSeparator="false" ?

tbolon 에 2019년 11월 27일

V2 NumberBox 제안: https://github.com/microsoft/microsoft-ui-xaml/issues/1736

안녕하세요 멋진 WinUI 커뮤니티입니다! 릴리스를 보기 위해 커뮤니티에서 제안한 첫 번째 제어 기능을 집으로 가져갈 수 있도록 도와주셔서 진심으로 감사드립니다. 우리는 이것이 엄청난 작업이었고 여러분 모두가 함께 디자인할 수 있는 최고의 V1 기능 모음을 만드는 데 상당한 시간을 투자했다는 것을 알고 있습니다.

우리는 또한 모든 것이 V1 릴리스에 포함되지 않았다는 것을 알고 있습니다. 매우 원하는 일부 입력 유효성 검사 구성은 WinUI 3.0 기능 작업에 따라 달라지며, 일부 원하는 기능은 유효성 검사/적용 후반부에 표면화되어야 하며, 우리가 알고 있는 일부 기능은 V1 릴리스 이후에 더 잘 탐색될 것입니다.

WinUI 3 릴리스에서 의도한 NumberBox 기능 작업을 완료하려고 합니다. V1에서 누락된 필수 기능에 대한 피드백을 수집하기 위한 문제를 열었습니다. NumberBox에 필요한 것이 없으면 여기에 의견을 남겨주세요: https://github.com/microsoft/microsoft-ui-xaml/issues/1736

SavoySchuler 에 2019년 12월 06일

🎉1

Microsoft-ui-xaml: 제안: NumberBox 컨트롤

WinUI 팀은 이 기능에 대한 사양 과 PR 을 공개했습니다.

제안: NumberBox 컨트롤

요약

이론적 해석

범위

중요 참고 사항

접근성 및 입력

열린 질문

가장 유용한 댓글

NumberBox로 돌아가기

모든 185 댓글

모두에게 더 높은 우선순위 질문이 있습니다.

모두에게 질문이 하나 더 있습니다. 입력 유효성 검사 또는 마스킹이 필요/선호합니까?

멋진 피드백, 여러분! 세부 사항을 망치기 시작하기 위해 사양 및 PR 을 열었습니다.

확인해 보시고 문제가 해결되지 않거나 추가 또는 개선할 수 있는 사항이 있으면 알려주시기 바랍니다. 여기에서 요구하는 사양에 기여하는 풀 리퀘스트를 수락하겠습니다.

정수

언어

가치 속성

SW1A 2AA

저는 여기에서 팀과 동기화했으며 일부 공개 질문에 대한 업데이트를 공유하고 싶었습니다.

"임베디드 계산기가 있는 NumberBox의 컨셉 아트." WinUI 커뮤니티, 2019년 5월. (색상)

사례 1: 축을 조정할 수 있는 2D 그래프용 설정 편집기가 있습니다.

사례 2: 아래와 같이 통화 값에 대한 입력 필드가 있습니다. 이것은 사용자 정의 컨트롤 "CurrencyBox"입니다.

마지막 댓글 몇 개(너무 길어서 죄송합니다!)

검증/마스킹

값 형식

나는 3개의 공개 질문으로 제안을 업데이트했습니다.

질문 시간: 16진수 또는 2진수 지원이 필요한 실제 앱 시나리오가 있는 사람이 있습니까? 최대/최소 값을 래핑하시겠습니까?

타임라인 업데이트!

개발자 업데이트

네이밍

단계 주파수

최소/최대값

위아래 반복 버튼

숫자

네거티브 제로?

현지화

NumberBox로 돌아가기

지금 NumberBox의 초기 커밋이 시작되었습니다!

단계 주파수

반올림

현지화

텍스트 줄 바꿈

KeyboardAccelerator를 올바르게 처리

°

단계 주파수

반올림

현지화

텍스트 줄 바꿈

KeyboardAccelerator를 올바르게 처리

°

V2 NumberBox 제안: https://github.com/microsoft/microsoft-ui-xaml/issues/1736

관련 문제