더 많은 보기 모드. 파일 탐색기와 아이콘 보기를 살펴보십시오. DataGrid는 표제 행과 열뿐만 아니라 그룹화로 그리드에 아이콘/항목을 표시할 수 있어야 합니다.

이것이 가능하지 않거나 범위를 벗어날 수 있다는 것을 알고 있습니다. 그러나 WinUI 대 Win32의 측면은 1:1만큼 쉽지 않으며 최신 버전의 파일 탐색기 또는 공통 파일 대화 상자에는 필요할 수 있습니다. 그러한 통제의. 이것은 내부 사용자 지정 컨트롤이 아니라 해당 컨트롤일 수 있습니다.

내 위시리스트 : 나에게 좋은 데이터 그리드에는 기본적으로 다음 기능이 모두 포함되어 있습니다. html 세계에서 일부 스크린샷을 빌리고 있습니다.

선호하는 행 수로 전체 페이지를 쉽게 필터링합니다.

보이는 열 선택/선택 해제 , 열 정렬 , 복사 , 인쇄

데이터를 특정 형식으로 내보냅니다.

열을 드래그하여 열 재정렬.

열 필터링

고정 헤더 - 스크롤할 때도 헤더가 맨 위에 유지됨

자세한 내용은 XAML 템플릿이 있는 행 세부정보를 참조하세요.

행 그룹화

드래그 앤 드롭 행 순서

내 생각에 위의 기능은 모든 데이터 그리드에서 표준이어야 합니다.

DataGrid를 html 세계에서 돋보이게 만들고 싶다면 다음도 포함하겠습니다. 나는 여러 번 데이터 그리드를 보고 데이터 그리드에 이러한 기능이 없기 때문에 목록 보기에 정착하는 것을 발견했습니다.

행을 옆으로 스와이프하여 편집 , 삭제 , 플래그 등과 같은 기능을 포함합니다.

위의 기능은 주로 "데이터 표시"를 처리하며 WinUI에서 여전히 부족한 것은 Microsoft Pivot Control 과 같은 기본 WinUI 기능(control)이어야 한다고 생각합니다

MS는 이미 이에 대한 소스 코드를 가지고 있으며 당시에는 절대적으로 멋진 컨트롤이었습니다.

https://www.youtube.com/watch?v=ZJIkQ9nebKY

이제 WinUI를 모든 기본 기능과 구별하기 위해 최소한으로 해야 하는 데이터의 표시 및 시각화 에 대해 설명합니다.

가장 중요한 것은 멋진 애니메이션과 강력하고 멋지게 보이는 시각적으로 매력적인 컨트롤을 포함해야 하는 "네이티브 앱"의 힘을 실제로 보여줍니다.

한 단계 더 나아가 위의 기능(시각화) 후에 데이터에 깊이 개념을 생성하고 우리를 다른 성층권으로 안내하는 2D/3D 애니메이션을 포함할 수 있다고 말할 수 있습니다. 하지만 그건 다른 날을 위한 것입니다. ))

좋은 출발점은 RadDataGrid(UWP 오픈 소스)가 있는 파트너 Telerik를 살펴보는 것입니다. 내 고객 중 한 명과 함께 사용했는데 실제로 잘 작동합니다. 그것은 매우 빠르고 다재다능합니다. 어려운 점은 코드뿐입니다. 아키텍처를 잘 이해하지 않고는 엔진에서 아무 것도 수정할 수 없습니다.

나는 새로운 DataGrid가 Telerik만큼 성능이 좋을 것으로 기대합니다.

WinUI 팀이 DataGrid 컨트롤을 고려하고 있다는 사실을 알게 되어 매우 기쁩니다.

Toolkit DataGrid를 대체하기 위해 새 컨트롤에서 보고 싶은 가장 실질적인 개선 사항은 다음과 같습니다.

• 인덱스로 DataGridRow를 검색하는 기능
• DataGridRows 자체에 특정한 이벤트입니다. 예를 들어 DoubleTapped 및 RightTapped.
• 부드러운 스크롤
• 셀 이름 변경에 대한 입력 유효성 검사
• 행 아이콘을 위해 특별히 설계된 DataGridColumn
• 색상 등을 쉽게 사용자 정의할 수 있습니다.

순서를 이동하기 위해 각 행 옆에 드래그 가능한 아이콘을 배치하는 편집 버튼을 갖는 옵션은 유용한 기능이 될 것입니다. (Fluent의 주요 속성 중 하나가 깊이이기 때문에) 들어 올려지고 이동되는 행 뒤의 일부 그림자를 보는 것도 좋습니다. 드래그 아이콘 옆에 작은 위아래 화살표가 있으면 마우스 입력으로 행을 더 쉽게 이동할 수 있습니다. 화살표를 사용하여 행을 이동하면 미묘한 슬라이딩 애니메이션이 좋은 터치가 될 것입니다. 터치 입력을 사용하면 편집 버튼을 누를 필요 없이 행을 잡고 이동하는 옵션도 잘 작동할 수 있습니다. 이것이 이미 지원되는지 확실하지 않지만 파일 탐색기에서와 같은 선택 확인란이 표시되어 어떤 DataGrid가 행 선택을 지원하고 전체 UX를 개선하는지 명확히 알 수 있습니다. iOS 미리 알림 앱에는 이러한 아이디어 중 일부가 포함되어 있습니다(아래 그림의 예). iOS 주식 앱도 이동 가능한 행과 유사한 종류의 거래를 제공합니다. 이러한 아이디어의 대부분은 기둥에도 효과적입니다.

@NoahFeller 그러한 유형의 작업은 목록 보기에 더 적합합니다. 그리드 보기를 사용하면 순서를 재정렬하지 않고 정렬 옵션이 있어야 하지만 사용자가 물건을 끌지 않습니다.

*편집하다
조금 더 생각해 보니 그러한 옵션이 어떻게 유용할 수 있는지 알 수 있습니다. 그러나 이것이 기본 동작이 되어서는 안 된다고 생각합니다.

@NoahFeller 그러한 유형의 작업은 목록 보기에 더 적합합니다. 그리드 보기를 사용하면 순서를 재정렬하지 않고 정렬 옵션이 있어야 하지만 사용자가 물건을 끌지 않습니다.

*편집하다
조금 더 생각해 보니 그러한 옵션이 어떻게 유용할 수 있는지 알 수 있습니다. 그러나 이것이 기본 동작이 되어서는 안 된다고 생각합니다.

네 맞습니다 @yaichenbaum. 저는 이러한 제안을 사용자 정의 정렬을 수행할 수 있는 기능으로 구상하고 있었고 드래그가 유용할 수 있다고 생각했습니다. 그래서 동의합니다. 확실히 기본값은 아니지만 옵션으로 꽤 유용할 수 있습니다. 피드백을 주셔서 감사합니다!

WPF 데이터 테이블에서 데이터 그리드 기능으로의 단순성. 저는 실제로 지난 주 동안 UWP 데이터 그리드가 WPF에서 작동하는 방식으로 작동하도록 하려고 노력해 왔습니다. 여기서 Datagrid를 Dataview에 바인딩한 다음 SQL의 Dataview를 datatable.defaultview로 채울 수 있습니다. 그런 다음 그리드는 데이터 테이블을 표시했습니다. 그것은 놀라울 정도로 간단했고 지금까지 UWP는 이것을 엄청나게 복잡하게 만들었습니다.

크로스 플랫폼으로 만들다

단일 셀 선택 모드, 엑셀 스타일을 요청하고 싶습니다.
궁극적인 목표는 WinForms DataGridView와 같은 정확한 동작을 하는 모드입니다.

다양한 사용 사례를 지원할 수 있는 다양한 가상화 옵션 보유(재활용과 같은 일반 스크롤 가상화 옵션에서 데이터 페이징과 같은 다른 개념까지)
종종(이를 지원하는 유사한 데스크톱 컨트롤에서) 이러한 옵션 중 일부는 고유한 데이터가 있는 열에 대한 사용자 지정 템플릿과 함께 사용될 때 실패하기 시작합니다. 이러한 경우 더 많이 지원할 수 있습니다.

가능하면 Paging Control #268 제안을 동기화하고 필요한 모든 후크를 DataGrid 컨트롤에 추가해야 합니다.

이것은 좋은 소식입니다! 저는 커뮤니티 툴킷에 등장한 이래로 DataGrid 전면에서 공식적으로 무언가를 기다리고 있었습니다. 이것은 커뮤니티 툴킷에 좋은 대안이 없는 WinUI 3.0에서 누락된 마지막 컨트롤입니다.

첫째, 바퀴를 재발명하지 마십시오. 기본적으로 DataGrid의 WPF 구현(코드를 사용할 수 없다는 것을 알고 있지만 API를 100% 사용하십시오) -- Silverlight가 아닙니다. WPF DataGrid는 기능이 훨씬 더 완벽했고 테스트에서 버그가 적었습니다.

커뮤니티 툴킷 DataGrid를 사용하면서 다양한 사용 사례에 대해 다음과 같은 API 추가를 요청했습니다. 토론 :

• RowPressed : 위에서 논의한 바와 같습니다. 추가 처리 또는 컨텍스트 메뉴가 발생할 수 있도록 행을 눌렀음을 나타냅니다.
• RowDoublePressed : RowPressed와 동일하며 더블 클릭 버전입니다.
• ColumnHeaderPressed : 열 머리글을 누를 때마다 발생합니다. 정렬 방향 내부 업데이트보다 우선해야 합니다. 이렇게 하면 사용자 정의 필터링 메뉴 또는 오른쪽 클릭 옵션을 통해 열을 켜거나 끌 수 있습니다.
• ColumnHeaderDoublePressed : ColumnHeaderPressed와 동일하며 더블 클릭 버전일 뿐입니다.
• ColumnHeaderWidthChanged : 사용자가 열 머리글 너비의 크기를 조정할 때마다 발생합니다. 이렇게 하면 이 정보를 깔끔하게 저장할 수 있습니다. 이는 일반적으로 UI 상태를 복원할 때 필요합니다.

또한 ItemsSource가 변경된 후 스크롤 위치를 맨 위로 재설정하는 DataGrid 커뮤니티에서 많은 문제가 계속 발생합니다. 오프셋이 WPF에서처럼 유지되도록 수정해야 합니다. 그러나 이것을 제어할 수 있어야 하기 때문에 다음 API도 제안합니다.

• FirstRowInView() : 상태를 복원하는 데 사용되는 DataGrid에 표시되는 첫 번째 행을 반환합니다.
• VerticalOffset : 스크롤바의 상태를 복원하기 위해 다시 Get/Set
• HorizontalOffset : 스크롤바의 상태를 복원하기 위한 Get/Set

@RBrid 또한 여기 에서 일부 분석을 도왔습니다.

제안된 새로운 이벤트 및 기존 이벤트에 대한 몇 가지 개선 사항:

| 이벤트 | 댓글 |
| :--- | :--- |
| ContextRequestedForColumnHeader | 열 머리글을 마우스 오른쪽 버튼으로 클릭할 때 상황에 맞는 메뉴(또는 기타 플라이아웃) 표시를 지원합니다. Windows.UI.Xaml.UIElement.ContextRequested 와 동일하지만 전체 DataGrid 대신 열 헤더용입니다. |
| ContextCanceledForColumnHeader | Windows.UI.Xaml.UIElement.ContextCanceled 와 동일하지만 전체 DataGrid 대신 열 헤더용입니다. |
| ContextRequestedForRow | 행을 마우스 오른쪽 버튼으로 클릭할 때 상황에 맞는 메뉴(또는 기타 플라이아웃) 표시를 지원합니다. Windows.UI.Xaml.UIElement.ContextRequested 와 동일하지만 전체 DataGrid 대신 행에 대한 것입니다. |
| ContextCanceledForRow | Windows.UI.Xaml.UIElement.ContextCanceled 와 동일하지만 전체 DataGrid 대신 행에 대한 것입니다. |
| RowTapped | 이미 선택된 행을 탭하는 경우에도 주의하십시오. |
| RowDoubleTapped | Windows.UI.Xaml.UIElement.DoubleTapped 와 동일하지만 전체 DataGrid 대신 행에 대한 것입니다. |
| RowRightTapped | Windows.UI.Xaml.UIElement.RightTapped 와 동일하지만 전체 DataGrid 대신 행에 대한 것입니다. ContextRequestedForRow 도 참조하십시오. |
| PointerPressedInRow | Windows.UI.Xaml.UIElement.PointerPressed 와 동일하지만 전체 DataGrid 대신 행에 대한 것입니다. |
| PointerReleasedInRow | Windows.UI.Xaml.UIElement.PointerReleased 와 동일하지만 전체 DataGrid 대신 행에 대한 것입니다. |
| PointerMovedInRow | Windows.UI.Xaml.UIElement.PointerMoved 와 동일하지만 전체 DataGrid 대신 행에 대한 것입니다. PointerMovedInRow 는 포인터가 캡처되는 동안에만 트리거될 수 있습니다. |
| ColumnHeaderTapped | 이미 선택된 열 머리글을 탭하는 경우에도 유의하십시오. |
| ColumnHeaderDoubleTapped | Windows.UI.Xaml.UIElement.DoubleTapped 와 동일하지만 전체 DataGrid 대신 열 헤더용입니다. |
| ColumnHeaderRightTapped | Windows.UI.Xaml.UIElement.RightTapped 와 동일하지만 전체 DataGrid 대신 열 머리글용입니다. ContextRequestedForColumnHeader 도 참조하십시오. |
| ColumnHeaderWidthChanged | 또는 ColumnHeaderResized 로 이름을 지정할 수 있습니다. 이벤트 인수에 사용자가 변경했는지 또는 프로그래밍 방식으로 변경했는지를 지정하는 부울 속성을 포함합니다. 분명히 이벤트 인수는 크기가 조정/변경된 열 헤더도 지정해야 합니다. |
| SortOrderChanged | 선택한 열 헤더 목록이 변경될 때 트리거되어야 합니다. 또한 선택한 열이 오름차순과 내림차순 사이에서 전환될 때 트리거됩니다. 이벤트 args에 정렬 순서가 사용자에 의해 변경되었는지 또는 프로그래밍 방식으로 변경되었는지를 지정하는 부울 속성을 포함합니다. 기존 이벤트 Sorting 도 참조하십시오. 정렬이 취소되지 않으면 Sorting 이벤트가 트리거된 후 새 이벤트 SortOrderChanged 가 트리거될 것이라고 생각합니다. |
| Sorting | 이미 존재하지만 정렬 요청을 취소할 수 있는 설정 가능한 부울 속성을 이벤트 인수에 추가하는 것을 고려하십시오. 예를 들어, 정렬이 잘못되었거나 수행할 수 없어 취소해야 할 수 있습니다. 또한 부울 속성을 추가하여 사용자가 정렬을 요청했는지 프로그래밍 방식으로 요청했는지 지정합니다. |
| ColumnSortDirectionChanged | 이 이벤트는 생성될 수 있지만 앞서 언급한 SortOrderChanged 이벤트가 생성되면, 정렬 방향이 변경될 때 SortOrderChanged 도 함께 트리거되면 불필요할 수 있습니다. |
| ColumnDisplayIndexChanged | 이미 존재하지만 사용자에 의해 변경되었는지 또는 프로그래밍 방식으로 변경되었는지를 지정하는 부울 속성(이벤트 인수에서)을 추가하는 것을 고려하십시오. 또한 ColumnDisplayIndexChanged 및 ColumnReordered 이벤트가 모두 필요한 이유를 문서화하십시오. 또는 이러한 이벤트 중 하나를 제거하십시오. |
| ColumnReordered | 이미 존재하지만 사용자에 의해 변경되었는지 또는 프로그래밍 방식으로 변경되었는지를 지정하는 부울 속성을 추가하는 것을 고려하십시오. |
| SelectionChanged | 이미 존재하지만 사용자에 의해 변경되었는지 또는 프로그래밍 방식으로 변경되었는지를 지정하는 부울 속성(이벤트 인수에서)을 추가하는 것을 고려하십시오. |
| CopyingRowClipboardContent | 이미 존재하지만 복사 대신 작업을 잘라낼지 여부를 지정하는 부울 속성을 이벤트 인수에 추가하는 것을 고려하십시오. 또는 컷을 위해 별도의 이벤트를 만드십시오. |
| CuttingRowClipboardContent | 존재하지 않습니다. 사용자가 행을 자르려고 할 때 트리거되는 이벤트를 만드는 것을 고려하십시오(control-X 핫키, 컨텍스트 메뉴 등을 통해). 또는 CopyingRowClipboardContent 가 복사 및 잘라내기 연산 모두에 대해 트리거되도록 하는 앞서 언급한 부울 속성을 만드십시오. |
| PastingRowClipboardContent | 존재하지 않습니다. 사용자가 붙여넣기를 시도할 때 트리거되는 이벤트를 만드는 것을 고려하십시오(control-V 단축키, 컨텍스트 메뉴 등을 통해). |

나에게 가장 중요한 기능은 수백만 개의 행을 메모리에 로드하지 않고도 백만 개 이상의 행을 쉽게 처리할 수 있는 기능이라고 생각합니다. ISupportIncrementalLoading 인터페이스는 이에 충분하지 않습니다. 스크롤 막대는 지금까지 로드한 행의 수(총 카운트가 아님)만 반영하고 100만 행에 도달하려면 끝까지 스크롤해야 하기 때문입니다. 그리고 점점 더 많은 데이터를 로드하고 메모리가 부족하지 않기를 바랍니다. 하지만 100만 개의 데이터 레코드가 있다는 것을 알고 있다면 데이터 그리드에 이를 알리고 빠르게 스크롤하거나 끝까지 이동하면 마지막 몇 행만 제공하라는 메시지가 표시될 수 있습니다.
내가 동적으로 가져올 데이터베이스의 행 목록을 스크롤하는 것을 생각해 보십시오.

나에게 가장 중요한 기능은 수백만 개의 행을 메모리에 로드하지 않고도 백만 개 이상의 행을 쉽게 처리할 수 있는 기능이라고 생각합니다. ISupportIncrementalLoading 인터페이스는 이에 충분하지 않습니다. 스크롤 막대는 지금까지 로드한 행의 수(총 카운트가 아님)만 반영하고 100만 행에 도달하려면 끝까지 스크롤해야 하기 때문입니다. 그리고 점점 더 많은 데이터를 로드하고 메모리가 부족하지 않기를 바랍니다. 하지만 100만 개의 데이터 레코드가 있다는 것을 알고 있다면 데이터 그리드에 이를 알리고 빠르게 스크롤하거나 끝까지 이동하면 마지막 몇 행만 제공하라는 메시지가 표시될 수 있습니다.
내가 동적으로 가져올 데이터베이스의 행 목록을 스크롤하는 것을 생각해 보십시오.

이것.

'현대적'은 가볍고 빠르다는 의미이며, 엔터프라이즈 앱은 일반적으로 수많은 내부 데이터를 정렬하여 적절한 레코드를 찾고 탐색하는 것입니다. 페이징, 정렬, 비동기 증분 로딩, 끝없는 스크롤 - 이 모든 것이 데이터 그리드를 활용하는 데스크탑 앱의 필수 요소입니다.

MS는 새로운 그리드에서 이러한 기능을 강조하는 샘플 앱을 제작하고 이러한 경험을 개선하기 위해 시간이 지남에 따라 엔터프라이즈 개발자로부터 피드백을 수집해야 합니다. 그 효과를 입증하기 위해 World Wide Importers와 같은 대규모 데이터 세트에서 실행하도록 합니다.

@dotMorten

나에게 가장 중요한 기능은 수백만 개의 행을 메모리에 로드하지 않고도 백만 개 이상의 행을 쉽게 처리할 수 있는 기능이라고 생각합니다.

저도 그러기를 바랍니다. 백만 개의 행을 지원하는 데 도움이 되도록(즉, 완전한 솔루션이 아닐 수도 있음) DataGrid에서 현재 데이터 바인딩 기술을 선택 사항으로 만들어야 한다고 제안합니다. 나는 현재 데이터 바인딩이 필수라고 생각합니다(내 지식이 최신 버전의 DataGrid에 대해 더 이상 최신 정보가 아닌 경우 제외). DataGrid는 표시되는 각 행의 각 셀/열에 대한 값을 검색하는 유일한 지원 방법으로 Windows.UI.Xaml.Data.Binding 를 사용할 필요가 없습니다.

DataGrid에서 DataGrid가 행의 셀/열 값을 검색해야 할 때마다 DataGrid가 호출할 대리자 또는 인터페이스 인스턴스를 DataGrid에 제공할 수 있도록 허용하는 것이 좋습니다. 지정된 행에 대해).

이상적으로(가능한 경우) DataGrid는 이 대리자 또는 인터페이스가 비동기적 으로 작동하도록 허용합니다. 예를 들어 대리자 또는 인터페이스는 요청된 값을 즉시 반환하는 대신 Task 또는 IAsyncOperation<TResult> 를 반환할 수 있습니다.

또는 DataGrid가 다음 절차와 유사하게 작동하는 경우 Task 및 IAsyncOperation<TResult> 없이 비동기식 지원도 가능합니다.

1. DataGrid는 행 ID 50001에서 셀/열 5의 값을 검색해야 한다고 결정합니다. 또는 DataGrid는 행 ID 50001에 대한 모든 열 값을 검색하기로 결정합니다.
2. DataGrid는 DataGrid가 지정된 열/행 또는 전체 행의 데이터 값 로드를 요청했음을 앱에 알리는 대리자 또는 인터페이스 인스턴스 또는 이벤트 처리기를 호출합니다.
3. 앱은 요청된 행 데이터를 비동기적으로 검색합니다. 예를 들어 SQL 데이터베이스 쿼리를 비동기적으로 수행할 수 있습니다.
4. 앱이 요청된 행 데이터 검색을 완료합니다. 앱은 DataGrid에 행 데이터를 제공하는 DataGrid의 메서드를 호출합니다.
5. DataGrid는 행 데이터를 표시하거나 데이터로 수행하는 데 필요한 모든 작업을 수행합니다.

우선 와우!! 아이디어를 제공해주신 모든 분들께 진심으로 감사드립니다. 아래에 몇 가지 구체적인 답변이 있지만 전반적으로 저는 이러한 의견을 많이 저장하고 있으며 멋진 현대식 DataGrid를 구축하는 방법을 듣는 것을 정말 즐기고 있다고 말하고 싶습니다. 계속 오세요!

@Pinox 자세한 답변과 스크린샷에 감사드립니다. 귀하의 위시리스트는 훌륭합니다(특히 멋진 애니메이션!) - html에 있는 이러한 기능이 좋은 영감을 주고 단순하지만 삶의 질을 크게 향상시킬 것이라는 데 동의합니다. 나중에 참조할 수 있도록 이 의견을 확실히 저장할 것입니다!

@verelpode , @robloo , @duke7553 DataGrid 관련 이벤트에 예입니다! 당신이 이것들에 넣은 세부 사항에 대해 모두 감사합니다. 터치 우선 및 다양한 입력을 위해 디자인할 때 이와 같은 이벤트는 반드시 구현되어야 합니다!

@dotMorten , @jkewley , @verelpode 성능은 확실히 이 프로젝트의 주요 동기 중 하나이며 새로운 데이터 가상화 스토리와 ItemsRepeater와 같은 최신 컨트롤의 사용을 통해 구현하려는 주요 개선 사항 중 하나입니다. 세부 사항이 추가되면 계속 업데이트하겠습니다. 하지만 제안하신 세부 정보에 다시 한 번 감사드립니다.

@Laz3rPanth3r , @robloo , @keeganatorr WPF 및 기타 UI 프레임워크에 속하는 DataGrid를 좋아한다는 귀하의 소리를 분명히 들었습니다. 이번 새로 고침에서 이를 확실히 고려하고 있습니다!

DataGrid에 대한 훌륭한 작업과 피드백 요청에 감사드립니다! 다음은 몇 가지 제안된 개선 사항입니다.

DataGridColumn의 더 많은 하위 클래스가 필요합니다.

DataGridColumn 의 현재 하위 클래스/구현이 충분하지 않습니다. DataGridColumn 의 다음 새 하위 클래스를 만드는 것이 좋습니다.

| 제안된 하위 클래스 | 설명 |
| :--- | :--- |
| 데이터 그리드 아이콘 열 ​​| 일반적인 요구 때문에 I이 제작 제안리스트의 각 행의 아이콘을 표시하는 DataGridColumn 서브라는 DataGridIconColumn 에 타입 변환이 검색된 셀 값 Windows.UI.Xaml.Controls.IconSource 및 렌더링 IconSource 인스턴스(각 셀에서 다른 IconSource 인스턴스가 렌더링됨). |
| 데이터 그리드 이미지 열 | DataGridImageColumn (가) 제안과 동일하게 작동해야 DataGridIconColumn 이 렌더링해야하는 것을 제외하고 Windows.UI.Xaml.Media.ImageSource 대신 Windows.UI.Xaml.Controls.IconSource . |
| 데이터 그리드 날짜 시간 열 | 설정에 따라 날짜 및/또는 시간을 표시합니다. 셀 값을 System.DateTimeOffset 또는 System.DateTime (둘 다 지원됨)로 Typecast하고 셀에 표시할 텍스트로 변환합니다. 텍스트로의 변환은 DataGridDateTimeColumn 클래스의 서식 설정/속성으로 제어해야 합니다. 분명히 날짜/시간별 정렬도 지원되어야 합니다. |
| 데이터그리드타임스팬컬럼 | 셀 값을 System.TimeSpan 로 Typecast하고 셀에 표시할 텍스트로 변환합니다. 텍스트로의 변환은 DataGridTimeSpanColumn 클래스의 서식 설정/속성에 의해 제어되어야 합니다. 분명히 정렬도 지원되어야 하며 표시된 텍스트가 아닌 TimeSpan 인스턴스를 정렬해야 합니다. |
| 데이터 그리드 데이터 크기 열 | 셀 값을 System.Int64 , UInt64 , Int32 또는 UInt32 (모두 지원됨)로 유형 변환하고 바이트 크기로 변환합니다(텍스트 ) 표시됩니다. 예를 들어, 1572864/1024/1024 = 1.5이므로 1572864는 "1.5MB"로 표시됩니다. 텍스트로의 변환은 DataGridDataSizeColumn 클래스의 설정/속성에 의해 제어되어야 합니다. 표시된 텍스트가 아닌 원래 정수 값을 사용하여 정렬을 수행해야 합니다. |
| 데이터 그리드 사용자 정의 열 | 이는 기존의 유사 작동해야 DataGridTemplateColumn 포함하지 않는 제외하고 Windows.UI.Xaml.DataTemplate . 표시된 GUI 요소 하위 트리를 생성 및/또는 업데이트하려면 대리자/콜백 또는 이벤트를 호출해야 합니다. |
| 데이터 그리드 텍스트 열 | 이미 존재하지만 앱이 개체에서 텍스트로의 변환 및 정렬을 위한 비교 기능을 재정의할 수 있도록 하는 속성이나 이벤트를 추가하는 것을 고려하십시오. 나중에 내 메시지에서 더 자세히 설명합니다. |

DataGridCustomColumn 는 다음과 같습니다.

public class DataGridCustomColumn : DataGridColumn
{
    public event EventHandler<DataGridDisplayingCellEventArgs> DisplayingCell;
}

public class DataGridDisplayingCellEventArgs : EventArgs
{
    public DataGridColumn Column { get; }
    public object CellValue { get; }
    public Windows.UI.Xaml.UIElement CellUIElement { get; set; } // settable
}

때 이벤트 DataGridCustomColumn.DisplayingCell 트리거, 생성하거나 자체 업데이트해야 이벤트 처리기 UIElement 하위 트리가 표시 DataGridDisplayingCellEventArgs.CellValue 하고 속성 설정 DataGridDisplayingCellEventArgs.CellUIElement 이에 UIElement 하위 트리를 클릭하면 DataGrid가 이를 표시합니다.

다음에 DataGrid가 이 이벤트를 트리거할 때 DataGrid는 이벤트 처리기가 재사용/재활용 및 업데이트할 수 있도록 DataGridDisplayingCellEventArgs.CellUIElement 속성을 이벤트 처리기에 의해 이전에 생성된 UIElement 인스턴스로 설정해야 합니다. 동일한 UIElement 하위 트리( DataGridDisplayingCellEventArgs.CellValue 다른 값이 있을 수 있음). 이벤트 핸들러는 동일한 UIElement 하위 트리를 재활용하거나 DataGridDisplayingCellEventArgs.CellUIElement 속성을 새로 생성된 UIElement 하위 트리로 설정할 수 있습니다.

또한 하위 클래스 DataGridCustomColumn 를 만드는 대신 기본 클래스 DataGridColumn 에서 직접 새로운 DisplayingCell 이벤트를 만드는 가능성을 고려하십시오. 따라서 DataGridColumn.DisplayingCell 이벤트는 DataGridColumn 의 모든 하위 클래스에 대해 생성된 UIElement 의 사용자 정의 또는 재정의를 허용할 수 있습니다.

기존 DataGridTextColumn 에서 현재 셀 값/개체는 System.Object.ToString 를 호출하여 표시할 텍스트로 변환됩니다. 앱이 이 값에서 텍스트로의 변환을 재정의할 수 있도록 위임/콜백 또는 이벤트를 만드는 것을 고려하십시오. 앱이 System.Collections.IComparer 인스턴스를 지정하여 정렬 동작을 재정의하도록 허용하는 속성도 고려하십시오.

public class DataGridTextColumn : DataGridColumn
{
    public System.Collections.IComparer Comparer { get; set; }
    public DataGridCellValueToToStringConverter CellValueToToStringConverter { get; set; }
}

public delegate string DataGridCellValueToToStringConverter(object sourceObject);

대신 만드는 다른 방법으로, Comparer 재산을 DataGridTextColumn , 제작의 가능성을 고려 Comparer 기본 클래스에서 직접 속성을 DataGridColumn 수 있도록하기 위해, DataGridColumn 의 모든 하위 클래스에 대한 정렬 동작을 제어하는 ​​앱.

마찬가지로 CellValueToToStringConverter 속성은 기본 클래스 DataGridColumn 에서도 만들 수 있습니다. DataGridColumn 하위 클래스에 관계없이 모든 셀 값을 텍스트로 변환하는 기능을 갖는 것이 유용하기 때문입니다. 사용. 예를 들어 행을 클립보드에 복사할 때 각 셀 값을 텍스트로 변환할 수 있습니다. (텍스트 형식과 텍스트가 아닌 형식 모두 클립보드에 동시에 배치할 수 있습니다. 앱은 일반적으로 다른 앱과의 호환성을 높이기 위해 이 작업을 수행합니다.)

DataGridIconColumn 또는 DataGridImageColumn 선택 시 다시 정렬: 분명히 DataGrid는 아이콘이나 이미지를 정렬할 수 없으므로 다음 솔루션 중 하나를 사용할 수 있습니다.

• 최종 사용자가 DataGridIconColumn 또는 DataGridImageColumn 유형의 열 헤더를 선택(정렬 기준)하지 못하도록 하면 됩니다.
• IconSource 클래스에서 AlternativeText 속성을 만듭니다. DataGridIconColumn 가 행을 정렬하거나 클립보드/복사본을 위해 셀을 텍스트로 변환할 때 AlternativeText 속성을 사용합니다.
• DataGridColumn 또는 DataGridIconColumn 에서 설정 가능한 Comparer 속성( System.Collections.IComparer 유형)을 만듭니다.

선택한 행/항목에 대한 액세스

현재 기능이 충분하지 않으므로 선택한 행/항목을 가져오고 설정하는 기능을 개선하는 것을 고려하십시오. 현재 다음 속성이 있습니다.

public int SelectedIndex { get; set; }
public object SelectedItem { get; set; }
public System.Collections.IList SelectedItems { get; }

선택한 행의 DataGridRow 인스턴스에 액세스해야 하는 경우가 있으므로 DataGrid에 다음 속성을 추가할 수 있기를 바랍니다.

public DataGridRow SelectedRow { get; set; }
public IList<DataGridRow> SelectedRows { get; }

또는 위의 내용을 구현하기가 너무 어려운 경우 다음 읽기 전용 변형이 덜 강력하지만 여전히 유용합니다.

public DataGridRow SelectedRow { get; }
public IReadOnlyCollection<DataGridRow> SelectedRows { get; }

DataGridRow 인스턴스가 재활용 될 수 있는 경우 위 속성에 대한 문서는 반환된 정보가 일시적으로만 유효하므로 즉시 읽고/사용해야 하며 더 오랜 기간 동안 유지하지 않아야 한다고 경고해야 합니다.

또한 기존의 SelectedIndex 속성은 하나의 선택된 인덱스에 대한 액세스를 제공하지만 선택한 모든 항목에 대한 액세스를 얻는 것은 어떻습니까? 따라서 다음 SelectedIndexes 속성을 만드는 것이 좋습니다.

public IList<int> SelectedIndexes { get; } // Suggestion.
public int SelectedIndex { get; set; } // Already exists.

개인적으로 DataGrid는 데이터베이스와 함께 사용되는 경우가 많고 "인덱스"라는 용어는 데이터베이스에서 완전히 다른 의미를 갖기 때문에 "SelectedIndex"라는 이름이 혼란스럽다고 생각합니다. 따라서 다음과 같이 속성 이름을 바꾸는 것이 좋습니다. 거부됩니다:

public IList<int> SelectedOrdinals { get; }
public int SelectedOrdinal { get; set; }

또한 지정된 DataGridRow 및/또는 DataGridColumn을 보기로 스크롤하는 기능을 원합니다. 현재 이 방법이 존재합니다:

public void ScrollIntoView(object item, DataGridColumn column);

기존 ScrollIntoView 방법을 다음 두 가지 방법으로 교체하는 것이 좋습니다.

public void ScrollIntoView(DataGridRow row, DataGridColumn column);
public void ScrollItemIntoView(object item, DataGridColumn column);

한 번에 정렬 순서 가져오기 및 설정

앱을 열고 닫을 때 정렬 순서 및 기타 설정을 포함하여 최종 사용자의 DataGrid 구성을 저장하고 복원하는 기능이 필요합니다. 사용자가 선택한 열의 목록을 의미하는 정렬 순서입니다. 이것은 단일 열이 아닌 목록입니다. 하나 이상의 열이 동시에 선택될 수 있습니다. 즉, 정렬을 위한 기본 열, 정렬을 위한 두 번째 열, 정렬을 위한 세 번째 열 등을 의미합니다.

따라서 DataGrid에서 다음 속성을 만들 수 있지만 실제로 이것은 첫 번째 아이디어일 뿐이며 이상적이지 않습니다.

public IReadOnlyList<DataGridColumn> SortOrder { get; set; }

위의 방법은 한 번의 히트에서 각 열의 DataGridColumn.SortDirection 저장 및 복원을 지원하지 않기 때문에 이상적이지 않습니다. 앱이 여러 단계로 수행할 수 있다는 것을 알고 있습니다.

1. 제안된 SortOrder 속성을 선택한 열 목록으로 설정합니다.
2. 선택한 각 열의 SortDirection 속성을 설정합니다(각 열에 대해 이 단계 반복).

이는 여러 히트가 발생하기 때문에 여전히 문제가 됩니다. 즉, DataGrid의 여러 시간 소모적인 리조트가 발생합니다. 최종 사용자는 DataGrid가 불필요하게 여러 번 재정렬될 때 많은 수의 행을 포함하는 DataGrid에서 상당한 지연을 인지하고 겪을 수 있습니다. 이 문제를 제거하기 위해 앱이 한 번의 히트로 완전한 정렬 순서를 복원하고 단일 리조트 이상을 발생시키지 않도록 하는 다음 솔루션을 제안합니다.

public class DataGrid
{
    public IReadOnlyList<DataGridColumnAndDirection> SortOrder { get; set; }
    ...
}

public struct DataGridColumnAndDirection
{
    public readonly DataGridColumn Column;
    public readonly DataGridSortDirection SortDirection;
    public DataGridColumnAndDirection(DataGridColumn, DataGridSortDirection) { ... }
}

참고 나는 의도적으로 쓴 IReadOnlyList<DataGridColumnAndDirection> 하지 IList<DataGridColumnAndDirection> 애플 리케이션에 의해 반환 된 목록을 수정할 수 없습니다해야하기 때문에 위의 SortOrder 속성을. 목록을 수정하는 대신 앱은 SortOrder 속성을 DataGrid에서 복사하여 전체 정렬 순서 목록을 완전히 바꾸는 데 사용할 목록으로 설정해야 합니다. 따라서 한 번에 작동하고 여러 값비싼 리조트를 피할 수 있습니다.

DataGrid.SortOrder 가 새 목록으로 설정되면 DataGrid는 새 SortOrder 목록의 각 열에 해당 DataGridColumn.SortDirection 속성도 설정하지만 여러 리조트가 발생하지 않습니다. 따라서 DataGrid.SortOrder[i].SortDirection 는 DataGridColumn.SortDirection .

한 번의 히트로 표시된 열 순서 가져오기 및 설정

앱을 열고 닫을 때, 가급적이면 한 번의 히트로 최종 사용자의 열 순서를 저장하고 복원하는 기능이 필요합니다. 기존 속성 DataGridColumn.DisplayIndex 을 설정할 수 있다는 것을 알고 있으므로 이론적으로 앱은 DataGrid.Columns 모든 열을 반복하고 각각의 DisplayIndex 를 설정하여 최종 사용자의 구성을 복원할 수 있지만 버그가 발생할 수 있습니다. 예를 들어 앱이 일시적으로 한 열의 DisplayIndex 를 다른 열의 동일한 DisplayIndex 로 설정해야 하는 경우 DisplayIndex 가 실패하거나 예기치 않은 방식으로 작동할 수 있습니다. 또한 한 번의 히트로 수행되지 않으면 값비싼 다시 그리기 및/또는 재계산이 여러 번 발생할 수 있습니다.

따라서 DataGrid에서 ColumnDisplayOrder 속성을 만드는 것이 좋습니다.

public IReadOnlyList<DataGridColumn> ColumnDisplayOrder { get; set; }

이전에 SortOrder 에 대해 언급한 것과 동일하게 ColumnDisplayOrder 은 한 번의 히트로 작동해야 하기 때문에 IList<DataGridColumn> 아닌 의도적으로 IReadOnlyList<DataGridColumn> 입니다.
DataGrid.ColumnDisplayOrder 가 새 목록으로 설정되면 DataGrid는 일치하도록 각 열의 DataGridColumn.DisplayIndex 를 업데이트합니다.

최종 사용자가 열을 숨기거나 표시하도록 허용

기존 속성 DataGridColumn.CanUserReorder 등과 일관되게 DataGridColumn CanUserChangeVisibility 속성을 만드는 것이 좋습니다. DataGridColumn.CanUserChangeVisibility 가 true이면 최종 사용자는 DataGridColumn.Visibility 속성을 변경할 수 있습니다.

런타임에 동적으로 생성되는 GUI 요소 지원

DataGrid.RowDetailsTemplate ( Windows.UI.Xaml.DataTemplate )를 사용하지 않고도 행 세부 정보 GUI를 생성할 수 있습니다. 이를 달성하기 위해 몇 가지 생각을 API에 넣어야 하지만 이를 수행하는 방법에 대한 첫 번째 아이디어는 다음과 같습니다. DataGridRowDetailsEventArgs.DetailsElement 속성을 변경하여 기존 이벤트 DataGrid.LoadingRow 를 통해 수행할 수 있습니다. 이벤트 핸들러가 UIElement를 자체적으로 생성(또는 업데이트)하고 DetailsElement 속성을 설정하여 DataGrid에 제공할 수 있도록 설정할 수 있습니다.

Windows.UI.Xaml.DataTemplate 의 필수 사용이 문제인 이유: 템플릿은 좋은 기능이지만 템플릿 개념은 개발자가 미리 작성한 변경되지 않는 미리 생성된 XAML 스니펫/문서를 기대합니다. 따라서 템플릿은 앱이 런타임에 GUI를 동적으로 생성해야 할 때 문제가 됩니다. 따라서 나는 DataTemplate 에 대해 앞서 언급한 대안을 원합니다.

행을 안쪽과 바깥쪽으로 끌어서 놓기

행의 나가는 끌어서 놓기를 선택적으로 활성화하는 기능을 만드는 것이 좋습니다. DataGrid는 드래그를 구현하지만 드롭은 구현하지 않습니다. 드롭이 발생하면 DataGrid는 이벤트를 트리거하고 앱은 행이 DataGrid 외부에 드롭될 때 원하는 작업을 수행하기 위해 이벤트에 응답합니다.

또한 행 또는 항목/개체의 들어오는 끌어서 놓기를 선택적으로 활성화하는 기능도 있습니다. DataGrid는 들어오는 끌어서 놓기를 허용하지만 놓기를 구현하지 않습니다. DataGrid는 행/항목/개체를 놓을 때 이벤트를 트리거하고, DataGrid 내부에 행을 놓을 때 원하는 작업을 수행하기 위해 앱이 이벤트에 응답합니다.

개별 세포 배경

특정 시간(예: 앱에서 변경 사항이나 중요한 값 또는 안전 한계를 초과하는 위험한 값을 감지하는 경우 등)에 개별 셀을 강조하기(셀 배경색/브러시 변경)를 원하는 고객의 기능 요청이 있습니다.

따라서 DataGridCell.Background 속성( Brush 유형)을 제안할 수 있지만 DataGrid가 DataGridCell 인스턴스를 재활용하기 때문에 이 방법은 아마도 결함이 있다고 생각합니다. 그렇죠? 따라서 DataGridCell.Background 속성을 설정하여 개별 셀을 강조하는 것은 신뢰할 수 없는 솔루션이라고 생각합니다.

더 나은 방법은 이전 메시지에서 제안한 DataGridColumn.DisplayingCell 이벤트를 통하는 것입니다. 이벤트 핸들러는 DataGridDisplayingCellEventArgs CellBackgroundBrush 속성을 설정할 수 있습니다.

덤다운 DataGrid의 데이터 검색(셀 값)

"멍청한" 소리가 아주 나쁘게 들린다는 것을 알고 있지만 실제로 DataGrid가 데이터 검색(DataGrid에서 표시할 셀 값 검색) 영역에서 멍청하게 만들어졌다면 정말 좋았을 것입니다.

현재 DataGrid는 DataGrid.ItemsSource 속성과 데이터 바인딩 기술( DataGridBoundColumn.Binding 속성) 및 System.ComponentModel.INotifyPropertyChanged 와 같은 인터페이스를 통해 편리한 자동 방식으로 데이터 검색을 수행하려고 합니다.

네, 데이터 바인딩은 편리한 기능이지만 사실 저는 DataGrid가 그 부서에서 _less_ 하는 것을 훨씬 선호합니다! 여러 Microsoft 구성 요소는 실제로 똑똑하려고 하지만 실제로는 너무 똑똑해 지는 행동을 통해 나에게 큰 어려움을 줍니다. 전반적으로 이러한 구성 요소가 스마트/자동/편리한 시도를 중단한다면 실제로 어려움과 작업량이 줄어들 것입니다. 자동 동작을 설계할 때 자동은 훌륭하게 들리지만 역효과가 날 수 있다는 점을 염두에 두는 것이 좋습니다.

_"저 혼자 하게 해주세요."_
때때로 가장 좋은 해결책은 DataGrid와 같은 구성 요소 내에서 "자동으로" 수행하려고 시도하고 실패하는 대신 앱이 스스로 작업을 수행하도록 허용하는 것입니다. DataGrid를 사용하면 DataGridBoundColumn.Binding 및 DataGrid.ItemsSource 속성을 통해 데이터를 자동으로 검색하는 대신 스스로 데이터 검색을 완전히 수행할 수 있기를 바랍니다.

이상적으로는 DataGrid.ItemsSource 속성을 사용하여 항목을 공급해야 하는 요구 사항을 제거하고 싶습니다. @dotMorten 은 백만 개의 행을 언급했습니다. 현재 DataGrid는 앱이 DataGrid.ItemsSource 를 설정하는 것을 의무화하지만 백만 항목을 포함하는 목록 개체를 만드는 것은 비현실적입니다. 따라서 DataGrid가 데이터 검색 부서에서 똑똑하지 않기를 바랍니다. 대신 DataGridBoundColumn.Binding 및 DataGrid.ItemsSource 를 사용하지 않고 데이터 검색을 완전히 수행할 수 있습니다.

@anawishnoff 는 다음

성능은 확실히 이 프로젝트의 주요 동기 중 하나이며 새로운 데이터 가상화 스토리와 ItemsRepeater와 같은 최신 컨트롤의 사용을 통해 구현하려는 주요 개선 사항 중 하나입니다.

새로운 데이터 가상화 스토리가 성능을 향상시킬 것이라고 말한 것을 보니 좋은 소식이기는 하지만 DataGrid가 표시하는 셀 값을 제공하기 위해 DataGridBoundColumn.Binding 속성을 사용해야 하는 요구 사항도 없앨까요?

전체 데이터 검색 작업이 DataGrid를 사용하는 앱에 아웃소싱 되는 경우 앱은 필요한 모든 방식으로 데이터 검색을 수행할 수 있는 완전한 유연성을 갖습니다. 이것은 @dotMorten이 언급한 백만 개의 행을 포함하여 다양한 데이터 검색 시나리오를 가능하게 합니다. 덤덤하게, 제발 :스마일:

WPF DataGrid에 몇 가지 불필요한 기능이 있습니까?

WPF 버전의 DataGrid에는 불필요하거나 비실용적인 몇 가지 기능이 있으며 이러한 기능은 WinUI DataGrid에서 건너뛸 수 있지만 일부 사람들은 이러한 기능에 대해 다른 의견을 가질 것으로 예상합니다.

WinUI DataGrid가 최종 사용자가 DataGrid 내부에서 인라인/직접적으로 셀 값을 편집할 수 있는 기능을 포기한다면 얼마나 많은 사람들이 이의를 제기할 것입니까? 우리의 경우 DataGrid를 사용하는 모든 곳에서 인라인/직접 편집 기능을 비활성화하기 위해 항상 DataGrid.IsReadOnly 를 true로 설정합니다. 사용자가 별도의 창이나 패널 또는 RowDetails( DataGrid.RowDetailsTemplate )에서 선택한 행을 편집할 수 있지만 DataGrid 자체 내부에서는 직접 편집할 수 없습니다.

WPF DataGrid에 CanUserAddRows 및 CanUserDeleteRows 있었지만 WinUI DataGrid에는 이러한 속성이 더 이상 존재하지 않기 때문에 WinUI DataGrid가 이미 인라인/직접 편집 지원을 중단하는 방향으로 이동한 것 같습니다. 인라인/직접 편집 기능을 완전히 삭제하지 않는 이유는 무엇입니까? 얼마나 많은 사람들이 이 아이디어에 반대합니까?

개별 셀 선택: WPF DataGrid에는 Cell , FullRow 또는 CellOrRowHeader 설정할 수 있는 SelectionUnit 속성이 있습니다. 우리의 경우 항상 FullRow 로 설정하고 Cell 로 설정할 필요를 찾지 못했습니다. 그러나 여기 한 사람이 이미 단일 셀 선택 모드를 요청한 것을 봅니다. 제 질문은 셀 선택 모드가 일반적인 요청인지 또는 드문 요청인지입니다.

반면에 개별 셀 선택은 사용자가 행/셀을 클립보드에 복사할 때 유용할 수 있습니다. 이를 통해 사용자는 전체 행을 복사하는 대신 개별 셀(또는 여러 인접 셀)을 클립보드에 복사할 수 있습니다. 그러나 이 기능이 정말 가치가 있는지 없는지 확신할 수 없습니다.

| WPF의 모호한 기능 | 댓글 |
| :--- | :--- |
| DataGrid.IsReadOnly | IsReadOnly를 false로 설정할 필요가 없을까요? |
| DataGrid.CanUserAddRows | WinUI DataGrid에 존재하지 않습니다. 이미 포기했거나 아직 구현되지 않았을 수도 있습니다(계획을 모르겠습니다). |
| DataGrid.CanUserDeleteRows | WinUI DataGrid에 존재하지 않습니다. 이미 포기했거나 아직 구현되지 않았을 수도 있습니다(계획을 모르겠습니다). |
| DataGrid.SelectionUnit | WinUI DataGrid에 존재하지 않습니다. |

와우, 여기에 놀라운 토론이 있습니다. ❤️

또한 WPF DataGrid API에 동의합니다. WPF DataGrid는 실제로 내가 WinUI 3.0에 원하는 DataGrid입니다.

그러나 WPF DataGrid에도 몇 가지 기능이 없습니다. 과거에는 대부분의 고객이 더 강력한 타사 DataGrid를 사용하여 다음 기능을 사용했습니다.

• 열 헤더의 필터
• DataGrid 상단의 완전한 필터 행
• 계층적 데이터의 강력한 표시. 일부 타사 DataGrid는 실제로 중첩 DataGrid가 있는 강력한 TreeView처럼 작동합니다. WPF DataGrid는 이와 같은 것을 빌드할 수 있지만 기본적으로 지원하지는 않습니다.
• 다양한 데이터 유형을 지원합니다. 예를 들어 DateTime 열과 같습니다. WPF의 DataGrid에서는 DataGridTemplateColumn을 사용해야 합니다.

그러나 어쨌든, 무엇을 하든지 DataGrid를 구축하는 것은 WinUI 3.0에 대한 강력한 선언이자 약속이라고 생각합니다. LOB 애플리케이션의 경우 내장 DataGrid가 포함되지 않은 UI 프레임워크를 진지하게 받아들일 수 없습니다. 그리고 WinUI를 위한 이러한 투자를 보니 정말 좋습니다!

@thomasclaudiushuber

LOB 애플리케이션의 경우 내장 DataGrid가 포함되지 않은 UI 프레임워크를 진지하게 받아들일 수 없습니다. 그리고 WinUI를 위한 이러한 투자를 보니 정말 좋습니다!

동의! 우리의 경우 DataGrid는 우리가 여러 곳에서 사용하고 없이는 살 수 없는 매우 필수적인 구성 요소입니다.

계층적 데이터의 강력한 표시. 일부 타사 DataGrid는 실제로 중첩 DataGrid가 있는 강력한 TreeView처럼 작동합니다.

나는 그 주제에 대해 고민하고 있습니다. 왜냐하면 -- 당신처럼 -- 저는 계층적 DataGrid가 어떤 상황에서는 유용하다는 것을 알았지만 제 걱정은 DataGrid가 계층적 기능을 구현하면 지나치게 복잡하고 어려워질 수 있다는 것입니다. DataGrid는 상당히 지연될 가능성이 높습니다. 계층적 기능과 비계층적 기능 모두와 호환되는 새 기능을 만드는 복잡성 때문에 새 기능을 추가하기 어려울 것입니다.

앞서 언급한 복잡성/지연 문제를 제거하려면 다음 솔루션을 제안합니다. DataGrid 의 인스턴스를 내부적으로 사용/래핑하는 HierarchicalDataGrid 라는 별도의 클래스를 만듭니다. 또는 HierarchicalDataGrid 가 공개적으로 DataGrid 상속할 수 있지만 이 상속이 비실용적이라고 생각합니다. 따라서 HierarchicalDataGrid Control 상속하고 내부적으로 DataGrid 합니다. 따라서 계층적 기능은 내부 비계층적 DataGrid 인스턴스를 지시하는 HierarchicalDataGrid 계층에서 구현됩니다.

위 솔루션의 주요 이점은 DataGrid DataGrid 너무 복잡해서 관리할 수 없고 개발 속도가 느려지는 일 없이 DataGrid _없는_ 원하는 계층적 기능을 제공할 수 있다는 것입니다.

다양한 데이터 유형을 지원합니다. 예를 들어 DateTime 열과 같습니다.

나는 동의한다. 이전 메시지에서 제안한 DataGridDateTimeColumn 및 DataGridTimeSpanColumn 를 확인하십시오.

@피녹스

전체 페이지를 쉽게 필터링

@thomasclaudiushuber

열 헤더의 필터 DataGrid 상단의 완전한 필터 행.

필터는 원하는 것을 찾기 위해 많은 수의 행을 수동으로 살펴보아야 하는 현재 상황 대신 최종 사용자가 행 또는 행을 빠르게 찾는 데 유용할 것입니다.

그러나 사용자의 필터 텍스트를 텍스트가 아닌 열과 일치시키는 문제는 어떻습니까? DataGridTemplateColumn 등으로 필터링하는 것과 같이 DataGridTextColumn 이외의 열을 의미합니까? DataGridColumn (및 하위 클래스)에 셀 값을 검색/필터링/매칭에 사용할 키워드로 변환하는 기능을 제공하는 다음 솔루션과 비슷한 것으로 이 문제를 해결하는 것이 좋습니다.

public delegate void DataGridCellValueToKeywordsConverter(object cellValue, ICollection<string> outputKeywords);

public class DataGridColumn
{
    ...
    public DataGridCellValueToKeywordsConverter CellValueToKeywordsConverter { get; set; }

    /// <param name="cellValue">The input/source value of the cell, to be converted to keywords.</param>
    /// <param name="outputKeywords">A collection that the method will add the keywords to.  The method invokes ICollection.Add for each keyword.</param>
    public virtual void ConvertCellValueToKeywords(object cellValue, ICollection<string> outputKeywords)
    {
        // Subclasses can override this method.  The default behavior is to invoke the delegate to do the job.
        DataGridCellValueToKeywordsConverter d = this.CellValueToKeywordsConverter;
        if (!(d is null)) d(cellValue, outputKeywords);
    }
}

다음은 ConvertCellValueToKeywords 메서드를 사용하는 방법의 예입니다.

void TestKeywords(DataGridColumn column)
{
    var keywords = new System.Collections.Generic.HashSet<string>();
    foreach (object cellValue in someCellValueList)
    {
        keywords.Clear();
        column.ConvertCellValueToKeywords(cellValue, keywords);
        CheckIfFilterTextMatchesAnyKeyword(keywords);
    }
}

또는 셀 값을 키워드 모음이 아닌 단일 문자열로 변환할 수도 있지만 키워드 모음을 제안한 이유는 키워드를 사용하면 행의 개수가 많아도 고속으로 실행되는 검색 알고리즘을 사용할 수 있기 때문입니다. 매우 큰.

엑셀에서 과거 복사하기
이제 ctrl+v를 사용하여 Excel 셀 내용을 DataGrid에 복사할 수 있는 방법이 없습니다. 이제 모든 셀 내용을 데이터 그리드의 한 셀에 복사합니다.

선택한 행을 관리할 때 데이터 바인딩을 사용할 수 있도록 SelectedItems를 종속성 속성으로 만들어 적절한 다중 선택 항목 지원을 제공하십시오.

@verelpode 개별 셀 선택이 모든 스프레드시트 유형 응용 프로그램에 유용

@anawishnoff 저는 @Laz3rPanth3r 이 동의할 것이며 DataGrid로 데이터를 쉽고 간단하게 수집할 수 있는 것이 중요한 기능이라는 툴킷의 여기 저기 몇 가지 문제에 동의할 것입니다. 목록의 개체 또는 확장 개체 컬렉션에 바인딩하여 그리드를 부트스트랩할 수 있어야 합니다. 숫자와 문자열, 기본 데이터 유형에 대한 열을 지능적으로 선택할 수 있다면 정말 좋을 것입니다. 개발자는 그 이상으로 개별 열을 사용자 지정하기 위해 항상 더 많은 작업을 수행할 수 있습니다.

개별 셀 선택이 모든 스프레드시트 유형 응용 프로그램에 유용하다는 것을 알 수 있습니다. 그렇지 않습니까?

스프레드 시트, 열 헤더 알파벳 오름차순 문자로 명명 된, A, B, C, D ... 모든 항목에서 사용하는 경우로서 각 컬럼의 유형은 동일 DataGridTextColumn 와 다른 열의 유형이 필요하고 열 이름은 알파벳에서 자동으로 생성되기 때문에 실제로 필요하지 않습니다.
DataGrid와 스프레드시트의 또 다른 차이점은 열 머리글을 클릭할 때 스프레드시트가 행을 정렬하지 않는다는 것입니다.

요점은 DataGrid와 스프레드시트 사이에 피상적인 유사성(대부분 시각적 유사성)만 존재한다는 것입니다. DataGrid는 실제로 스프레드시트처럼 작동하지 않습니다. DataGrid의 셀 데이터 검색 기술은 스프레드시트에도 적합하지 않습니다.

DataGrid를 좋아하지만 스프레드시트를 구현하는 데 사용하려고 하면 제대로 작동하지 않습니다. 스프레드시트를 구현하려는 사람에게는 DataGrid가 올바른 선택이 아니라고 생각합니다.

DataGrid의 기존 디자인은 스프레드시트보다 SQL 데이터베이스에 훨씬 더 잘 맞으며, 누군가 데이터베이스가 "그냥 스프레드시트"라고 주장하려고 하면 SQL 데이터베이스 개발자는 큰 소리로 외칠 것입니다.

@verelpode 귀하의 기여는 매우 상세하고

현재 DataGrid는 앱이 DataGrid.ItemsSource를 설정하는 것을 의무화하지만 백만 개의 항목이 포함된 목록 개체를 만드는 것은 비현실적입니다. 따라서 DataGrid가 데이터 검색 부서에서 똑똑해지는 것을 멈추고 대신 DataGridBoundColumn.Binding 및 DataGrid.ItemsSource를 사용하지 않고 스스로 데이터 검색을 완전히 수행할 수 있기를 바랍니다.

이것은 흥미롭고 우리가 성능에 정말로 관심이 있기 때문에 더 자세히 살펴보고 싶습니다. 구체적으로 어떤 종류의 데이터 상황/시나리오를 찾고 있습니까? DataGrid를 SQL 쿼리 결과, 데이터베이스 또는 해당 라인에 따라 바로 연결하시겠습니까?

@khoshroomahdi 복사하여 붙여 넣기는 실행중인 앱의 DataGrid에 Excel 셀을 복사하고 그런 식으로 채우려는 것을 의미합니까? 흥미로운 사용 사례입니다. 더 듣고 싶습니다.

@alexyak , 조금 더 확장할 수 있습니까? SelectedItems 속성을 사용하면 현재 DataGrid에서 선택한 모든 항목을 가져올 수 있습니다(정확히 다중 선택 모드가 아니라 확장 선택 모드를 통해). DataGrid 내에서 선택하려면 확실히 작업이 필요하지만 귀하의 요청을 더 잘 이해하고 싶습니다.

@anawishnoff 네 맞습니다.
Excel 셀에 일부 데이터가 있고 실행 중인 앱에서 복사하고 싶습니다.

데이터 바인딩되지 않은 시나리오의 경우 몇 년 전에 작성한 WinForms DataGridView 컨트롤이 가상 모드( https://docs.microsoft.com/en-us/dotnet/api/system)를 지원하는 방법을 살펴봐야 합니다

현재 DataGrid는 앱이 DataGrid.ItemsSource를 설정하는 것을 의무화하지만 백만 개의 항목이 포함된 목록 개체를 만드는 것은 비현실적입니다. 따라서 DataGrid가 데이터 검색 부서에서 똑똑해지는 것을 멈추고 대신 DataGridBoundColumn.Binding 및 DataGrid.ItemsSource를 사용하지 않고 스스로 데이터 검색을 완전히 수행할 수 있기를 바랍니다.

그것도 좋을 것이라는 데 동의합니다. 항목을 수동으로 추가하거나 ItemsSource를 설정할 수 있는 ListBox와 같은 것을 생각하고 있습니다. 즉, 과거에는 페이징을 구현하기 위해 전체 데이터베이스의 부분 보기를 나타내는 새 DataTable을 생성했습니다(이것이 좋은 사용 사례임). 그런 다음 해당 DataTable의 보기를 ItemsSource로 설정할 수 있습니다. 그래서 나는 이것이 고성능을 위해 필수적인 것처럼 보이지 않는 것이 좋은 것이라고 확실히 생각합니다.

컨트롤을 Excel(r)의 하위 집합으로 바꾸는 모든 주석과 관련하여 DataGrid는 기본적으로 셀 선택 및 셀별 편집을 지원해야 한다고 생각합니다. 단, 외부 애플리케이션 간의 복사/붙여넣기 등은 개발자가 처리해야 합니다.

@alexyak SelectedItems를 실제 바인딩 가능한 DependencyProperty로 만들기 위한 요청과 관련하여 이것은 상태를 복원하는 데도 좋습니다(지금까지 내 기능 요청의 대부분은 보기 상태를 복원하는 것입니다). 내가 알고 있는 WinUI/UWP 컨트롤에서 지원되지 않기 때문에 이것이 프레임워크 전체의 문제라고 생각합니다. 이것은 아마도 일반적인 기능 요청일 것입니다. 여기에서 토론 보기

@anawishnoff 는 다음

귀하의 기여는 매우 상세하고 사려깊습니다. 모든 것에 대해 대단히 감사합니다!

감사합니다. 제 기여가 DataGrid를 더욱 개선하는 데 유용하다는 소식을 들으니 기쁩니다. :)

구체적으로 어떤 종류의 데이터 상황/시나리오를 찾고 있습니까? DataGrid를 SQL 쿼리 결과, 데이터베이스 또는 해당 라인에 따라 바로 연결하시겠습니까?

여전히 너무 똑똑합니다. 이 스마트한 동작은 다른 앱이 다른 방식으로 데이터 검색을 수행하는 것을 방지합니다. 앱마다 환경이 매우 다르기 때문에 "최상의" 데이터 검색 시스템은 앱마다 다릅니다. 단일 "최고"는 존재하지 않습니다. 예를 들어, 일부 앱은 200개 이상의 행을 표시하지 않는 반면, 일부 다른 앱은 언급된 @dotMorten 과 같은 백만 개의 행으로 작동할 수 있으므로 하나의 신발 사이즈가 모든 사람에게 맞지 않습니다.

나는 정말로 그것을 이 수준으로 낮추는 것이 좋습니다.

1. DataGrid는 외부 데이터 저장 시스템에서 9001행의 5열에 있는 값을 표시(또는 사용)해야 한다고 결정합니다.
2. DataGrid는 9001행의 5열에 대한 값이 필요하다고 앱에 알립니다.
3. 앱은 9001행의 5열에 대한 값을 검색합니다. 여기에는 비동기 SQL 쿼리, 비동기 C# 작업 또는 기타 데이터 시스템이 포함될 수 있습니다. 이상적으로 DataGrid는 이 단계를 비동기식으로 허용해야 합니다.
4. 앱은 9001행의 5열에 대한 값 검색을 완료했음을 DataGrid에 알립니다. 앱은 이 값을 DataGrid에 제공합니다.
5. DataGrid는 1단계에서 언급한 값을 표시하는 것과 같이 필요한 방식으로 값을 사용합니다.

@RBrid 는 다음

데이터 바인딩되지 않은 시나리오의 경우 몇 년 전에 작성한 WinForms DataGridView 컨트롤이 가상 모드를 지원하는 방법을 살펴봐야 합니다.

네 네 네! 나는 WinForms DataGridView를 사용한 적이 없지만 지금 막 문서를 읽었고 당신이 머리에 못을 박았다고 생각합니다. 링크 한
_"가상 모드는 매우 큰 데이터 저장소와 함께 사용하도록 설계되었습니다."_

WinForms DataGridViewCellValueEventArgs 에는 다음 속성이 포함되어 있습니다.

public int RowIndex { get; }      // DataGrid sets RowIndex.
public int ColumnIndex { get; }   // DataGrid sets ColumnIndex.
public object Value { get; set; } // The app sets Value.

이상적으로는 최신 C# async 및 await 키워드 또는 이에 상응하는 UWP( IAsyncOperation<TResult> ) 또는 모든 종류의 시간 지연을 지원하도록 업데이트해야 한다는 점을 제외하고는 훌륭합니다. 셀 값을 요청하는 DataGrid와 셀 값을 DataGrid에 전달하는 앱 사이. 따라서 비동기를 지원하도록 업데이트하려면 다음을 수행하십시오.

1. 이벤트 CellValueNeeded를 유지합니다.
2. DataGridViewCellValueEventArgs.Value 속성을 제거합니다.
3. DataGridViewCellValueEventArgs.Value 속성을 즉시/동기적으로 설정해야 하는 대신 앱이 호출할 SupplyCellValue 와 같은 이름의 DataGrid 메서드를 만듭니다.

SupplyCellValue 메서드는 다음과 같이 정의할 수 있습니다.

class DataGrid
{
    public void SupplyCellValue(int rowIndex, int columnIndex, object value);
    // Alternatively:
    public void SupplyCellValue(int rowIndex, DataGridColumn column, object value);
}

따라서 런타임 시 절차는 다음과 같습니다.

1. DataGrid는 외부 데이터 저장 시스템에서 9001행의 5열에 있는 값을 표시(또는 사용)해야 한다고 결정합니다.
2. DataGrid는 CellValueNeeded 이벤트를 트리거하고 DataGridViewCellValueEventArgs.RowIndex 를 9001로, DataGridViewCellValueEventArgs.ColumnIndex 를 5로 설정합니다.
3. 이벤트 처리기(앱)는 9001행의 5열에 대한 값을 검색하는 비동기 작업 실행을 시작합니다.
4. 비동기 작업 실행이 완료되면 앱이 값을 검색한 경우 앱이 DataGrid.SupplyCellValue 메서드를 호출합니다.

이 멍청한 기술은 DataGridBoundColumn.Binding 및 DataGrid.ItemsSource 의 스마트 자동화 기술보다 더 강력하고 유연합니다.

@alexyak , 조금 더 확장할 수 있습니까? SelectedItems 속성을 사용하면 현재 DataGrid에서 선택한 모든 항목을 가져올 수 있습니다(정확히 다중 선택 모드가 아니라 확장 선택 모드를 통해). DataGrid 내에서 선택하려면 확실히 작업이 필요하지만 귀하의 요청을 더 잘 이해하고 싶습니다.

다중 선택을 관리하기 위해 뷰 모델에 대한 적절한 양방향 데이터 바인딩이 필요합니다.

@verelpode , 우리는 더 오래된 Win32 ComCtl32 컨트롤을 따라 WinForms DataGridView 모델을 모델링했습니다. 특히 목록 보기 컨트롤이 가상 모드에서 LVN_GETDISPINFO 메시지를 어떻게 사용했는지 생각하고 있습니다(https://docs.microsoft.com/en-us/windows/win32/controls/list-view-controls-overview 참조). #handling-virtual-list-view-control-notification-codes 및 https://docs.microsoft.com/en-us/windows/win32/controls/lvn-getdispinfo). 90년대 옛날 물건들.

어쨌든 비동기식 데이터 검색 측면이 처리되어야 하는 방식은 '지연된 이벤트'를 통해서라고 생각합니다.
WinUI 컨트롤은 이미 지연된 이벤트를 두 번 사용합니다.

runtimeclass RefreshRequestedEventArgs
{
    Windows.Foundation.Deferral GetDeferral();
}

runtimeclass TeachingTipClosingEventArgs
{
    TeachingTipCloseReason Reason{ get; };
    Boolean Cancel;
    Windows.Foundation.Deferral GetDeferral();
}

새로운 DataGrid의 CellValueNeeded 이벤트가 채택하려는 패턴입니다. 이를 통해 이벤트 처리기가 데이터를 비동기적으로 제공하고 완료되면 컨트롤에 알릴 수 있습니다. https://docs.microsoft.com/en-us/uwp/api/windows.foundation.deferral을 참조

@RBrid
GetDeferral() 가 새로운 표준 패턴이라는 점은 좋은 점입니다. CellValueNeeded 의 이 특별한 경우에는 다른 경우/이벤트보다 Deferral 를 사용하는 것이 훨씬 더 어려워 보입니다. 내가 틀렸다면 정정해 주세요. 하지만 이 특별한 경우에 GetDeferral() 를 사용할 때의 문제는 GetDeferral() 가 호출될 때마다 새 객체를 생성한다는 것입니다. 잠재적으로 많은 수의 행에 있는 모든 행의 모든 ​​셀에 대해 엄청난 양의 객체 생성 및 정리가 반복됩니다. 다양한 GetDeferral() 구현의 소스 코드를 본 적이 없으므로 이에 대해 오해할 수 있습니다.

다시 말해 Deferral 가 재활용을 지원하거나 GetDeferral() 훨씬 더 효율적으로 만드는 방법이 없다면 여전히 너무 똑똑합니다. SupplyCellValue 방법을 사용한 내 제안은 적용 가능한 모든 행의 모든 ​​셀에 대해 새로운 Deferral 인스턴스를 생성, 완료 및 폐기하는 오버헤드가 발생하는 것을 방지합니다.

1. GetDeferral()
2. 연기.완료
3. 연기.처분
4. 위의 단계를 여러 번 반복하십시오.

셀 값을 검색하는 작업은 앱에 아웃소싱할 수 있는 유일한 데이터 관리 작업이 아닙니다. 정렬을 아웃소싱할 수도 있습니다. 따라서 단일 이벤트 CellValueNeeded 대신 인터페이스 를 고려하는 것이 좋습니다. 앱은 특정 인터페이스를 구현하는 개체 형태로 DataGrid에 데이터 관리 모듈을 제공합니다. DataGrid는 셀 값을 검색하기 위해 이 인터페이스를 호출하지만 잠재적으로 정렬과 같은 다른 작업도 수행할 수 있습니다.

@dotMorten이 언급한 백만 개의 행을 지원하기 위해 CellValueNeeded 만으로는 사용자가 열 헤더를 클릭하고 DataGrid가 백만 개의 행을 정렬하려고 할 때 발생하는 다른 문제를 해결할 수 없습니다. 따라서 셀 검색 및 정렬은 앞서 언급한 모듈/인터페이스를 통해 앱에 아웃소싱될 수 있습니다.

앱이 DataGrid에 데이터 관리 모듈/개체를 제공하지 않는 경우 이상적으로 DataGrid는 기본 데이터 관리 모듈을 사용합니다. 따라서 DataGrid의 기존 데이터 바인딩 코드는 모두 DataGrid에서 별도의 새 클래스로 이동됩니다. DataGridBoundColumn.Binding 등으로 작업하여 기본 데이터 관리 모듈을 구현하는 클래스입니다.

즉, 정렬이 앱 또는 해당 데이터 관리 모듈에도 아웃소싱되는 경우 시도하는 대신 SQL 서버에 정렬을 수행하도록 지시하는 데이터 관리 모듈을 작성하는 것과 같이 백만 행을 지원하는 다양한 솔루션의 문을 엽니다. 사용자가 정렬을 시작하기 위해 열 머리글을 클릭한 후 10시간 또는 20시간 이내에 DataGrid 내부의 백만 행 정렬을 수행하는 데 실패합니다.

@verelpode , 네, 그것은 유효한 우려입니다. DataGrid가 재활용 가능한 Windows.Foundation.Deferral 개체 풀을 소유할 것으로 예상합니다. 우리는 타당성과 성능을 확실히 확인해야 합니다.

Row Details가 기능으로 포함된 Windows Community Toolkit DataGrid에 대한 종속성을 가져왔기 때문에(심각한 성능 버그가 있지만 해결 방법이 있음) 이 새로운 DataGrid에 동일한 옵션을 포함하는 기능도 포함되기를 정말로 원합니다. 여러 행 세부 정보를 동시에 가질 수 있습니다. 서버에서 클라이언트로 스트리밍 데이터 시나리오에 사용합니다.

페이징 GUI에 비해 백만 개의 행에 대해 @roblo 는 다음과

[백만 행 지원]도 좋을 것이라는 데 동의합니다. .... 즉, 과거에는 페이징을 구현하기 위해 전체 데이터베이스의 부분 보기를 나타내는 새 DataTable을 생성했습니다(이것이 좋은 사용 사례임). 그런 다음 해당 DataTable의 보기를 ItemsSource로 설정할 수 있습니다. 그래서 나는 이것이 고성능을 위해 필수적인 것처럼 보이지 않는 것이 좋은 것이라고 확실히 생각합니다.

페이징은 유용한 기술이며 언급할 가치가 있지만 상당한 단점이 있습니다. 즉, DataGrid의 정렬 기능을 거의 쓸모 없게 만듭니다. DataGrid의 다음 버전의 필터링 기능도 마찬가지입니다. 페이징은 정렬과 필터링을 쓸모없게 만들거나 최소한 덜 유용하게 만듭니다.

예를 들어, 2개 또는 3개의 열이 날짜 열이고 사용자가 두 번째 날짜 열에서 가장 최근(또는 가장 오래된) 날짜가 있는 행을 보려고 한다고 가정합니다. 따라서 사용자는 두 번째 날짜 열 머리글을 클릭하여 해당 열을 기준으로 DataGrid를 정렬하고, 클릭하여 정렬 방향을 내림차순에서 오름차순으로 또는 그 반대로 변경합니다. 이것은 사용 중인 페이징이 없거나 총 행 수가 단일 페이지를 초과하지 않을 만큼 충분히 작은 경우에 훌륭하게 작동하지만 여러 페이지가 존재하는 경우에는 중단됩니다.

사용자는 모든 행 에서 가장 최근(또는 가장 오래된) 날짜를 찾아야 하지만 페이징된 DataGrid GUI는

이것은 어떤 행이 어떤 페이지에 도착하는지에 대한 질문을 제기합니다. 대답은 ORDER BY 사용하지 않는 SQL SELECT 쿼리를 통해 페이지/행을 얻을 때 각 페이지에 일반적으로 행의 실질적으로 임의의 하위 집합이 포함된다는 것입니다. (사용자의 관점에서 무작위가 아닌 무작위를 의미합니다.)

의사 난수는 최종 사용자에게 도움이 되지 않습니다. 이 문제가 있는 임의성을 제거하기 위해 SQL ORDER BY (정렬 방향을 제어하기 위해 ASC 또는 DESC 키워드와 함께 사용)을 사용할 수 있습니다. 그러면 페이지는 아니오입니다. 더 긴 무작위이지만 ORDER BY 항상 동일한 열과 동일한 정렬 방향으로 정렬되기 때문에 여전히 깨졌습니다

이를 수정하려면 사용자가 다른 열 헤더를 클릭할 때마다 다른 SQL 쿼리를 사용해야 합니다. SQL ORDER BY ... ASC/DESC 는 DataGrid의 최종 사용자가 선택한 정렬 순서와 동일하게 유지해야 합니다. DataGrid는 현재 이것을 지원하지 않습니다.

제안된 솔루션은 이전 메시지에 있습니다 . 저는 DataGrid에서 정렬을 앱(또는 "데이터 관리 모듈")에 아웃소싱하도록 허용해야 한다고 제안했습니다. 이 아이디어를 통해 최종 사용자가 열 헤더 등을 클릭하여 DataGrid의 정렬 순서를 변경할 때마다 앱(또는 "데이터 관리 모듈")이 SQL ORDER BY ... ASC/DESC 변경할 수 있습니다.

앱(이벤트 핸들러)이 정렬을 취소 하고 인계하도록 허용하는 이벤트 인수의 설정 가능한 속성을 기존 이벤트 DataGrid.Sorting 에 제공하는 것도 가치가 있습니다. 이상적으로 이벤트 인수는 정렬 순서 변경이 프로그래밍 방식으로 요청되었는지 여부와 최종 사용자가 열 헤더 등을 클릭하여 요청했는지 여부도 지정합니다. 이 경우 DataGrid.Sorting 이벤트의 이름을 덜 모호한 것으로 바꾸는 것도 도움이 될 수 있습니다. 현재 Sorting 이벤트의 의도와 목적이 불분명하기 때문입니다. 내 다른 메시지에서 제안된

Row가 있는 Windows Community Toolkit DataGrid에 대한 종속성
기능으로서의 세부사항(심각한 성능 버그가 있지만 해결 방법이 있음)
이 새로운 DataGrid를 기능으로 포함하는 것이 정말 좋습니다.
여러 행 세부 정보를 동시에. 서버에서 클라이언트로 스트리밍 데이터 시나리오에 사용합니다.

행 세부 정보 성능 문제에 대한 링크: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/2842
재현: https://github.com/observito/DataGridRowDetailsPerfTest

좋은 출발점은 RadDataGrid(UWP 오픈 소스)가 있는 파트너 Telerik를 살펴보는 것입니다. 내 고객 중 한 명과 함께 사용했는데 실제로 잘 작동합니다. 그것은 매우 빠르고 다재다능합니다. 어려운 점은 코드뿐입니다. 아키텍처를 잘 이해하지 않고는 엔진에서 아무 것도 수정할 수 없습니다.

나는 새로운 DataGrid가 Telerik만큼 성능이 좋을 것으로 기대합니다.

syncfusion 그리드 기능은 훌륭하지만 mvvm 친화적이지 않습니다. 그래서 당신은 더 잘할 수 있습니다.

안녕 다시 모두! 이 대화를 계속합시다. 현재 존재하는 DataGrid 문서에 대해 어떻게 생각하십니까?

여기의 링크 주요 문서 페이지에 그 기타 관련 모든 페이지에 대한 링크.

새로운 DataGrid를 생성하는 경우 수반되는 문서가 최고 수준이고 이해하기 쉬우며 개발자에게 중요한 모든 문제와 시나리오를 해결하도록 하고 싶습니다.

_우리가 했으면 하는 주제는 무엇입니까? 명확히 할 수 있는 주제는 무엇입니까?_

안녕 다시 모두! 이 대화를 계속합시다. 현재 존재하는 DataGrid 문서에 대해 어떻게 생각하십니까?

여기의 링크 주요 문서 페이지에 그 기타 관련 모든 페이지에 대한 링크.

새로운 DataGrid를 생성하는 경우 수반되는 문서가 최고 수준이고 이해하기 쉬우며 개발자에게 중요한 모든 문제와 시나리오를 해결하도록 하고 싶습니다.

_우리가 했으면 하는 주제는 무엇입니까? 명확히 할 수 있는 주제는 무엇입니까?_

xaml 및 코드와 함께 일반적인 DataGrid 설정을 보여주는 이미지가 유용할 것입니다.

xaml 및 코드와 함께 일반적인 DataGrid 설정을 보여주는 이미지가 유용할 것입니다.

@mdtauk "일반적인" 것으로 확인되는 특정 DataGrid 설정이 있습니까? 또는 DataGrid가 사용하기에 가장 적합한 선택이라고 일관되게 찾는 사용 사례가 있습니까?

xaml 및 코드와 함께 일반적인 DataGrid 설정을 보여주는 이미지가 유용할 것입니다.

@mdtauk "일반적인" 것으로 확인되는 특정 DataGrid 설정이 있습니까? 또는 DataGrid가 사용하기에 가장 적합한 선택이라고 일관되게 찾는 사용 사례가 있습니까?

일반적인 WPF, Win32 데이터 그리드/아이콘 보기 시나리오를 보여주는 WinUI 3.0 기간에 대해 생각합니다. 뿐만 아니라 Microsoft가 Fluent/Modern DataGrid UI 디자인을 고려하는 것입니다.

즉, 컨트롤 이면의 아이디어가 이전 UI에서 WinUI 3으로 이동하도록 권장하는 것입니다.

@anawishnoff 사람들이 이러한 시나리오에 대한 문서를 찾고 있다는 점에서 툴킷에서 얻은 몇 가지 질문은 다음과 같습니다.

• 테마/재템플릿/정렬
• 데이터 바인딩(일반적으로 XAML에서)
• 이벤트/선택 처리/케이스
• 행동 수정(특히 클릭 시 수정)
• 다중 페이징(#60 및 #268과 잘 짝을 이루어야 함)
  
  
  
  • 데이터가 로드되는 동안 애니메이션 조정 로드
  
  
• 복사/붙여넣기/서식
• 다른 열 데이터 유형(및 사용자 정의 데이터 유형)(예: 열거형)
• 컨텍스트 메뉴
• 접근성

기존 Toolkit DataGrid에는 ItemsSource 속성에 대해 IEnumerable이 필요하다는 것을 알았습니다. 이것은 논리적인 결정처럼 보이지만 Windows.Storage.BulkAccess.FileInformationFactory.GetVirtualizedItemsVector()에서 반환된 개체를 이 속성으로 설정하는 것은 불가능합니다. (반환된 개체를 캐스팅하는 방법이 없는 한) 또한 ListView 및 GridView와 같은 다른 컨트롤은 ItemsSource 속성을 개체 유형 값으로 설정하는 것을 지원합니다. 확실하지 않지만 이를 지원하면 스토리지 작업 중에 더 응답성이 뛰어난 사용자 인터페이스가 가능할 것입니다.

@mdtauk "일반적인" 것으로 확인되는 특정 DataGrid 설정이 있습니까? 또는 DataGrid가 사용하기에 가장 적합한 선택이라고 일관되게 찾는 사용 사례가 있습니까?

일반적인 WPF, Win32 데이터 그리드/아이콘 보기 시나리오를 보여주는 WinUI 3.0 기간에 대해 생각합니다. 뿐만 아니라 Microsoft가 Fluent/Modern DataGrid UI 디자인을 고려하는 것입니다.

즉, 컨트롤 이면의 아이디어가 이전 UI에서 WinUI 3으로 이동하도록 권장하는 것입니다.

Win32 예제(파일 탐색기)

WPF 예제

패브릭 웹 예제

UWP 예제

@mdtauk 스크린샷 감사합니다! 확실히 이전 버전의 컨트롤에서 작동했던 핵심 요소를 강조하고 새 컨트롤로 달성할 수 있는 방법을 문서화하는 것이 중요하다고 생각합니다.

@michael-hawker 굉장합니다. 나는 이미 이 스레드에서 여러 번 언급된 몇 가지 주제를 보고 있으므로 시작하기에 좋은 곳입니다.

@duke7553 나는 그것에 대한 해결책에 대해 100% 확신하지 못하거나 객체 유형을 지원하는 것이 현명한 것인지 확신하지 못합니다. @RBrid 가 차임벨을

@anawishnoff & @duke7553 , 새 WinUI ItemsRepeater 컨트롤 위에 새 DataGrid 컨트롤을 빌드합니다. 그리고 해당 컨트롤은 ItemsSource를 개체로 노출합니다.
Object ItemsSource { get; set; };

Telerik에서와 같이 CellDecorationStyleSelector를 지원하기를 바랍니다.

@anawishnoff

기본 WinUI 컨트롤로 전환하는 데 관심이 있습니다.

흠 "졸업 중"이라고 하면 C++로 다운그레이드하는 것도 포함되나요? 현재 WinUI의 DataGrid는 C#으로 작성되어 있습니다. "졸업"이 "다운그레이드"를 의미하지 않기를 바랍니다. 중요하게도, WinUI는 WinUI 팀이 WinUI가 중요한 모든 면에서 WPF보다 낫다고 말할 수 있는 지점에 도달해야 하지만 이 목표는 너무 늦었습니다. C#에서 C++로의 DataGrid와 같은 불필요한 코드 다운그레이드에 시간/자원이 낭비된다면 이 목표는 훨씬 더 늦어질 것입니다.

원래 C++로 WinRT/UWP/WinUI를 작성하는 이유가 있었지만 안타깝게도 그 이유는 실현되지 않았고, 구글/안드로이드가 스마트폰 시장 점유율의 대부분을 차지했기 때문에 C++를 사용하는 원래의 이유는 더 이상 적용되지 않습니다(쉽게 뒤늦게 말했지만 더 일찍 말하기는 쉽지 않음). WinUI가 처음부터 C#으로 작성되었다면 WPF보다 더 나은 목표는 3년 전에 달성했을 것이지만 지금은 8년이 지났지만 여전히 달성되지 않았으며 아무도 목표를 달성할 때 정확하게 말할 수 없습니다. WPF보다 나은 목표와 WinUI DataGrid "졸업" 목표가 더 오래되고 덜 생산적인 프로그래밍 언어로의 불필요한 변환으로 인해 지연되지 않기를 바랍니다.

저는 C#이 존재하기도 전에 C++로 프로그래밍을 시작했고 사람들은 원래 배운 것을 고수하고 _"좋은 옛날"_을 기억하는 것을 선호하기 때문에 C++에 편향되어 있습니다. C++에 대한 편견에도 불구하고 C++ 작성을 중단했고 DataGrid를 C++로 다운그레이드하여 지연해서는 안 된다고 생각합니다. C#은 그대로 두고 이 문제에서 사람들이 제안한 다양한 개선 사항을 만들고 10년이 되기 전에 WPF보다 나은 목표를 달성하는 것과 같은 더 중요한 일에 집중하십시오.

저는 WinUI의 여러 측면을 사랑하고, WinUI의 많은 영리한 개선 사항에 감사하며, WinUI용 앱 코드를 작성하고 있습니다. 하지만 솔직한 진실을 알고 싶으십니까? 진실은, 슬프게도 아직 어느 사용자에 대한 WinUI 응용 프로그램을 해제되지 것입니다. 사용자에게 출시된 소프트웨어는 WPF로 작성되었으며 소프트웨어가 잘 작동하고 GUI 현대화를 포함하기 때문에 사용자는 신경 쓰지 않습니다. WinUI용 앱 코드를 많이 작성했지만, 모두 준비, 계획, 테스트, 대기이며 사용자가 실제로 사용하지 않습니다. 바라건대 내년에는 첫 번째 WinUI 구성 요소가 사용자에게 출시되지만 저는 이 전환을 사용자보다 훨씬 더 높이 평가할 것입니다. 모든 것이 계획대로 진행된다면 사용자는 전환을 거의 눈치채지 못할 것입니다.

Microsoft의 관점에서 WinRT/UWP는 2012년부터 사용자에게 게시된 릴리스 품질의 소프트웨어이지만 내 관점에서 UWP는 여전히 큰 실험입니다. 저에게 UWP(WinUI 포함)는 모두 제가 수년간 가지고 놀아온

UWP의 처음 몇 년 동안 매년 저는 생각했습니다. _"에러... 내년까지 기다리겠습니다. WPF에는 아직 UWP에 없는 것이 너무 많습니다. 내년에는 확실히 더 나아질 것입니다."_
그리고 이듬해가 왔고 나는 같은 생각을 반복했다. 그리고 이듬해가 왔고 나는 같은 생각을 반복했다. 바라건대 올해는 그 말의 마지막 해이거나 적어도 그것이 내 의도입니다.

WinUI는 더 이상 지연을 허용할 수 없습니다. WinUI의 DataGrid를 C# 코드로 둡니다. 생산성을 높이려면 C#에서 더 많은 WinUI 코드를 작성하십시오. 이제 8년이 지났고 Android는 엄청난 시장 점유율을 차지했습니다. 심각한 상황입니다.

그건 그렇고, 기술적으로 UWP는 베타가 아닌 알파 버전의 정의와 일치하기 때문에 UWP가 여전히 베타 버전이라고 말할 때 나는 실제로 친절하고 관대했습니다. 진정한 베타 버전이 되려면 기능이 완전해야 하지만 UWP는 아직 기능이 완성된 상태에 도달하지 않았으므로 UWP는 여전히 알파입니다. 예를 들어 Wikipedia의 "소프트웨어 릴리스 수명 주기" 기사 에는 다음과 같이 나와 있습니다.

"베타 단계는 일반적으로 소프트웨어의 기능이 완전하지만 알려지거나 알려지지 않은 버그가 많이 포함될 가능성이 있을 때 시작됩니다."
"알파 소프트웨어에는 최종 버전에 대해 계획된 모든 기능이 포함되어 있지 않을 수 있습니다."

Wikipedia는 "기능 완료" 를 다음과 같이

"소프트웨어의 완전한 기능 버전은 계획된 또는 주요 기능을 모두 구현했지만 버그, 성능 또는 안정성 문제로 인해 아직 최종 버전이 아닙니다. 이는 개발 알파 테스트가 끝날 때 발생합니다."

UWP가 완전한 기능이라면 UWP에는 Windows 95 이상의 모든 기능이 있어야 하지만 그렇지 않습니다. UWP는 아직 모든 영역에서 Windows 95를 초과하지 않습니다. . Windows 95는 25년 전에 출시되었습니다. UWP/WinRT가 7~8년 전에 출시되었을 때 Microsoft는 9억 달러의 손실과 Windows 스토어에서 심각한 앱 부족을 겪었습니다. 릴리스 버전이라고 표시된 알파 버전이므로 앱 개발자는 기다렸다가 보았습니다. 거의 8년이 지난 오늘, 그것은 여전히 ​​알파 버전이고 매우 기한이 지났으며 여전히 기다리고 보고 기다리고 있습니다.

Microsoft가 UWP의 진정한 베타 버전 생산에 우선 순위를 두고 진정한 릴리스 후보 버전이 신속하게 뒤따를 수 있도록 진지한 결정/약속을 내린다면 Microsoft와 개발자에게 매우 유익할 것입니다. 이것은 매우 권장되며 매우 합리적인 조치입니다. 모두에게 탁월할 것입니다.

UWP는 여러 가지 이유로 여전히 알파/불완전합니다. 예를 들어: 25년 전에는 Windows 95에서 "MoveFile" 기능을 사용하여 파일이나 폴더를 이동하는 것이 쉬웠습니다(함수 이름이 "MoveFile"이었지만 두 파일을 모두 지원했습니다. 및 폴더). UWP에서 폴더를 이동할 수 있나요? 아니, 아직. 분명히 폴더를 이동하는 기능은 기본적인 기본 필수 기능 중 하나이지만 UWP에는 여전히 이 필수 기능 및 기타 기능이 누락되어 있으므로 UWP를 완전한 기능으로 설명하는 것은 비합리적입니다. 따라서 UWP는 아직 베타 상태에 도달하지 않았습니다. 7-8년 전에 출시되었습니다. Microsoft는 UWP의 진정한 베타 버전을 우선시해야 합니다.

내가 아는 한 UWP 문제(UI 문제 제외)를 추적하기 위한 공개 GitHub 리포지토리는 아직 존재하지 않습니다(또는 UWP 리포지토리가 존재하는 경우 찾을 수 없음). 다시 말하지만 이는 공개 문제 추적 저장소가 알파 단계에서 바람직하지 않은 경우가 많기 때문에 알파 버전의 정의와 일치합니다. 그것이 진정한 베타 또는 릴리스 버전이었다면 공개 문제 추적 리포지토리가 이미 열렸을 것이고 UWP에는 Windows 95 및 Windows 7 등의 모든 기능이 포함되었을 것입니다.

이 상황은 DataGrid에 어떤 영향을 줍니까? 기능이 완비된 UWP 베타 버전이 너무 늦게 출시되었다는 점과 이 상황의 심각성과 결과적으로 Microsoft가 입은 수십억 달러의 손실을 고려할 때 더 많은 시간을 낭비하는 것은 정당화되고 합리적이지 않습니다. WinUI DataGrid를 비관리 코드 및 이전 프로그래밍 언어로 변환합니다. Microsoft는 C# 및 "관리 코드"의 큰 이점이 생산성 향상이라고 반복해서 말했습니다. "관리 코드"에 대한 Microsoft의 주장은 C++ 및 C#에 대한 제 경험에서 확실히 사실이었습니다. UWP는 버전 1.0부터 시작하는 관리 코드를 사용하여 주로 작성된 경우 몇 년 전에 진정한 베타 상태에 도달했을 것입니다. 따라서 관리 코드에서 비관리 코드로 이러한 불필요한 다운그레이드를 더 많이 수행하여 상황이 더 악화되지 않기를 바랍니다.

비교를 위해 2006년부터 2010년까지 4년 동안 대부분의 WPF가 성공적으로 완료되었습니다. WPF는 UWP와 달리 주로 관리되는 코드입니다. UWP는 비관리 코드이며 8년의 개발 후에도 Windows 95는 몇 가지 영역에서 여전히 UWP를 능가합니다. 따라서 Microsoft가 관리 코드가 생산성을 향상시킨다고 주장했을 때 Microsoft는 분명히 옳았습니다. 이 문제는 최대한 빨리 해결해야 합니다. 두 프로젝트 모두 소유자(Microsoft)가 동일하므로 WinUI가 WPF에서 코드를 자유롭게 복사할 수 있기 때문에 WinUI는 WPF보다 훨씬 쉽고 빠르게 작성할 수 있어야 합니다. 따라서 WinUI는 WPF 개발 시간의 약 절반이 필요했습니다. 실제로 WinUI는 시작되지 않았어야 했으며 Microsoft는 WPF의 새 버전에서 WinUI의 기능을 개발해야 했습니다. WinUI는 WPF 5.0이어야 합니다. 따라서 상황은 큰 혼란이었고 Microsoft가 이 혼란의 나머지 정리를 우선시하고 수십억 달러의 실수를 이미보다 더 악화시키는 일을 중단하는 것이 매우 유익할 것입니다. 오늘날의 스마트폰 시장 점유율 상황에서).

즉, 더 많은 손실을 방지하기 위해 Microsoft는 Microsoft가 과거에 이미 말한/알고 있던 내용을 기억함으로써 이익을 얻을 수 있습니다.

• Microsoft의 자체 주장에 따르면 관리 코드는 생산성을 높입니다. WPF의 4년과 비교하여 UWP의 8년을 볼 때 결론은 관리 코드의 이점에 대해 Microsoft가 옳았다는 것입니다.
• 스크립팅 언어는 스크립팅용이고 프로그래밍 언어는 프로그래밍용입니다. JavaScript와 PowerShell은 의도한 목적(스크립팅)에는 적합하지만 앱 프로그래밍에는 분명히 부적합한 선택입니다.
• 성공하려면 Microsoft는 알파에서 베타로, 릴리스로 진행해야 하며 이는 "릴리스"라는 레이블이 붙은 불완전한 알파가 아니라 진정한 릴리스 버전인 경우에만 성공합니다. 따라서 Microsoft Store는 지나치게 오랫동안 비어 있었습니다.
• 소프트웨어 엔지니어와 기타 직원은 합당한 보수, 합당한 근무 시간, 건강한 근무 환경을 대가로 일할 때 가장 잘 일합니다. 분명히, Microsoft의 수십억 달러 손실은 무급 광신자/광신도와 소위 "주간 작업" 및 "야간 작업"과 지속 가능하지 않거나 건강에 해로운 작업 조건을 사용하여 되돌릴 수 없습니다.
• Android의 거대한 시장 점유율 승리는 무보수 광신도 덕분이 아닙니다. 무보수 광신도가 승리의 이유였다면 Linux는 실패하지 않았을 것입니다. 설명은 훨씬 간단합니다. Android 태블릿 및 스마트폰의 가격은 Windows 태블릿 및 스마트폰보다 훨씬 저렴합니다. 분명히 최종 사용자는 "오픈 소스" 종교/이데올로기에 관심이 없으며(사용자는 그것이 무엇인지조차 모릅니다), 그저 Android 기기의 저렴한 가격을 좋아할 뿐입니다.
• Win16은 매우 구식입니다. 20-30년 전, 프로그래밍의 초기 "Wild West" 시절부터의 기술입니다. 따라서 Win16 기반의 새 코드 작성을 중지하십시오. 그것을 "Win32"라고 부르는 것은 그것이 여전히 근본적으로 Win16이라는 사실을 실제로 바꾸지 않습니다. Win32는 포인터 크기가 16비트에서 32비트로 확장되었다는 점을 제외하고는 Win16과 동일합니다. Microsoft의 너무 많은 그룹이 Win16/32를 기반으로 새 코드를 계속 작성하고 있습니다. 이것은 매우 비효율적이며 큰 자원 낭비입니다.

@anawishnoff

기본 WinUI 컨트롤로 전환하는 데 관심이 있습니다.

Wikipedia의 "매몰 비용" 도 참조하십시오.

매몰 비용 효과(또는 콩코드 효과)는 행동이 종종 매몰 비용 오류를 따른다는 사실입니다. 사람들은 "돈, 노력 또는 시간에 대한 투자가 이루어지면 노력을 계속하는 경향이 더 커집니다." 이 행동은 "좋은 돈을 나쁜 데로 던지는 것"으로 설명할 수 있으며 그것에 굴복하지 않는 것은 "손실을 줄이는 것"으로 설명할 수 있습니다.

그리고 유사하게 "계획 지속 편향" :

계획 지속 편향, get-the-itis 또는 press-on-itis는 실패한 계획을 지속하려는 현명하지 못한 경향입니다. 이것은 치명적인 재난으로 이어질 때 계획된 코스를 고수할 수 있고 대신 중단해야 하는 선장이나 항공기 조종사에게 위험한 위험입니다. ..... 프로젝트는 과도한 낙관주의, 실패를 인정하지 않는 태도, 집단 사고, 매몰 비용 손실에 대한 혐오를 포함하는 계획 오류 및 관련 요인으로 인해 종종 비용 초과 및 지연을 겪습니다.

WinRT/UWP로 인해 Microsoft는 첫 해 또는 두 번째 해에 9억 달러의 손실을 보았고 너무 오랫동안 비어 있는 앱 스토어를 겪었습니다. WinRT/UWP는 치명적인 실패였으므로 두 번째 해에 중단되어야 했지만 "계획 지속 편향"과 매몰 비용 손실에 대한 혐오 때문에 계속되었습니다. 이 내용은 관리 과정에서 가르칩니다. 계획 지속이 결국 WinRT/UWP의 치명적인 오류를 지우거나 되돌렸습니까? 아니요, 스마트폰 시장 점유율 측면에서 보면 오늘날에도 여전히 치명적인 실패입니다. Wikipedia의 이러한 설명은 UWP의 상황을 정확하게 설명합니다.

이제 오늘 우리는 WinRT/UWP가 출시된 지 7~8년이 지난 현재 시점에서 UWP를 취소하기에는 너무 늦었다는 데 동의해야 합니다. " 및 매몰 비용 손실에 대한 혐오감.

그렇다면 상황을 구출하기 위해 합리적으로 할 수 있는 일은 무엇입니까? 몇 년 전에 확실히 취소했어야 했지만 UWP를 취소한다고 상황을 구할 수는 없습니다. 우리가 할 수 있는 일은 WinRT가 가한 막대한 피해를 수용하되 더 이상 피해를 입히지 않고 프로젝트의 절차/정책을 변경하는 것입니다. 즉, WinRT의 동일한 치명적인 실수를 반복/계속하는 것을 중지합니다. 예를 들어, 이러한 많은 양의 관리 코드를 비생산적인 오래된 관리되지 않는 "네이티브" 코드로 다운그레이드하지 마십시오. 진정한 베타 상태에 도달하는 데 걸리는 지연은 이미 매우 큽니다. 지연을 더 악화시키는 이유는 무엇입니까?

DataGrid가 관리되지 않는 "네이티브" 코드로 다운그레이드되면 "계획 지속 편향"/매몰 비용 실수가 계속됩니다. WinRT/UWP와 같은 치명적인 실수를 저질렀을 때 이 같은 실수가 계속해서 반복되면 훨씬 더 나빠집니다. 피해를 줄이기 위해서는 같은 실수를 반복하지 않아야 합니다. WinRT의 치명적인 실패로부터 배우고 지속적인 혈액 손실을 막기 위해 붕대를 적용해야 할 때입니다.

DataGrid를 비관리 코드로 변환하는 것은 도서관에 가서 가장 많은 지식/경험을 가진 최고의 저자로부터 최고의 프로젝트 관리 책을 모두 빌린 다음 이 모든 우수한 관리 책을 모닥불에 던지고 타는 것을 지켜보는 것과 같습니다.

@verelpode DataGrid에 대한 두 개의 매우 큰 게시물에 대한 귀하의 요점이 무엇인지 궁금합니다. 저는 개인적으로 위의 피드백이 구체적으로 OOB DataGrid 컨트롤을 개선하는 데 무엇을 의미하는지 정말로 이해하지 못합니다. 내가 얻은 유일한 것은 네이티브 코드로 변환하는 것이 시간 낭비라고 걱정하지만 C++에서 WinUI를 사용하는 사람들은 다루지 않는다는 것입니다. 관리되는 런타임을 로드하는 오버헤드가 괜찮다면 현재 관리되는 구현을 계속 사용할 수 있습니다. 다른 모든 것은 WinRT 및 UWP 앱 모델에 관한 것으로 보이며, v3에서는 WinUI에 완전히 적용되지 않으므로 어느 쪽도 실제로 WinUI에 적용되지 않습니다.

@dotMorten -- 내가 그 메시지에 추가 세부 사항을 쓴 이유는 문제를 적절하게 설명하지 않으면 사람들이 이해하지 못하기 때문입니다. 그러나 슬프게도 지금은 추가 세부 사항이 실패했으며 어쨌든 여전히 이해되지 않았다는 것을 알았습니다. 정말 답답합니다. 이것이 많은 사람들이 피드백을 전혀 작성하지 않는 이유입니다. 왜냐하면 이러한 문제를 사람들에게 설명하는 것은 무의미하다고 생각하고 메시지가 성공적으로 이해되더라도 총을 쏘는 것이 인간의 본성이라고 생각하기 때문입니다. 나쁜 소식을 전하는 사람이므로 아무 말도 하지 않거나 반대로 생각하면서 그냥 "공손하게" 미소 짓는 것이 좋습니다.

v3에서 완전히 해방되기 때문입니다.

이 v3 바인딩 해제는 동일한 실수의 반복을 방지하지 않습니다. "계획 지속 편향"은 여전히 ​​존재합니다.

마이크로소프트 홈페이지로 이동:
https://www.microsoft.com/en-us/
이제 Windows Phone이 표시될 때까지 홈 페이지를 아래로 스크롤합니다. 오! 저것 봐! 우리는 홈 페이지의 끝에 도달했고 Windows Phone은 Microsoft 홈 페이지의 어디에도 언급되지 않았습니다! 이것은 무엇을 의미 하는가? 일어나라는 뜻입니다. 그것은 내가 말했듯이 UWP가 치명적인 실패라는 것을 의미합니다. 즉, UWP의 실패로 이어진 동일한 실수를 반복하지 않는 것이 중요합니다. 재난으로부터 구조하고 복구하기 위해 계획을 변경하는 것을 의미합니다.
WinUI와 DataGrid가 UWP의 실패와 같은 실수를 계속 반복한다면 관리 실수가 될 것입니다.

"2016년 5월 Microsoft는 모바일 사업을 중단했습니다. ... 2017년 Microsoft 임원인 Joe Belfiore는 시장 점유율의 손실과 앱 개발."
-- https://en.wikipedia.org/wiki/Microsoft_Mobile

Ana는 wrt DataGrid에 대한 피드백을 제공하기 위해 5가지 사항을 나열합니다. 그 중 어떤 점에 대해 논평하고 있습니까? 당신이 쓰고 있는 것에서 내가 이해하지 못하는 부분인 것 같아요. UWP는 모든 사람의 요구를 충족시키지는 않지만 WinUI3는 UWP 앱 모델을 사용하도록 지시하지 않으며 대부분 UWP에 반대하는 것 같습니까? 그래서 당신은 거기에 잘해야합니다.

DataGrid는 같은 실수를 계속해서는 안 된다고 언급했습니다. 그렇다면 기존 DataGrid에 구체적으로 어떤 실수가 있으며 수정해야 한다고 제안하는 방법은 무엇입니까? (어떤 이유로 C++로 구현하고 싶지 않다는 점을 제외하고)

@dotMorten

Ana는 wrt DataGrid에 대한 피드백을 제공하기 위해 5가지 사항을 나열합니다. 그 중 어떤 점에 대해 논평하고 있습니까?

내 메시지의 시작 부분에서 Ana를 인용한 부분입니다. 나는 내 메시지의 시작 부분에 인용한 Ana의 메시지의 일부에 대해 논평하고 있습니다.

WinUI3는 UWP 앱 모델을 사용하도록 지시하지 않습니다.

그것은 내 메시지와 관련이 없습니다. Nuget 패키지를 통해 바인딩되지 않고 사용할 수 있는 WinUI 3은 UWP 및 Windows Phone의 실패와 Microsoft의 수십억 달러 손실을 초래한 동일한 관리 실수를 WinUI 3이 계속하는지 여부에 대한 질문과 관련이 없습니다.

어떻게 수정해야 한다고 제안합니까?

이전 메시지 의 끝에 있는 6개의 글머리 기호. 두 번째 글머리 기호(스크립팅)는 일반적으로 WinUI 및 UWP와 관련되지만 DataGrid와는 관련이 없습니다. DataGrid에 대해 구체적으로 묻는 경우 첫 번째 글머리 기호가 가장 중요합니다.
나는 또한 이렇게 썼습니다. 많은 양의 관리되는 코드를 비생산적인 오래된 관리되지 않는 "네이티브" 코드로 다운그레이드하지 마십시오. 진정한 베타 상태에 도달하는 데 걸리는 지연은 이미 매우 큽니다. 지연을 더 악화시키는 이유는 무엇입니까?

@anawishnoff 는 다음

기본 WinUI 컨트롤로 전환하는 데 관심이 있습니다.

"기본 WinUI 컨트롤로 전환"은 Wikipedia에 언급된 "시장 점유율 손실 및 앱 개발 부족"으로 이어진 동일한 실수 중 일부의 연속/반복을 구성합니다.

"2016년 5월 Microsoft는 모바일 사업을 중단했습니다. ... 2017년 Microsoft 임원인 Joe Belfiore는 시장 점유율의 손실과 앱 개발."
-- https://en.wikipedia.org/wiki/Microsoft_Mobile

왜 DataGrid는 Microsoft의 모바일 비즈니스를 파괴한 동일한 경로를 따라야 합니까?

@verelpode

WinUI 3는 UWP 및 Windows Phone의 실패와 Microsoft의 수십억 달러 손실로 이어진 동일한 관리 실수를 계속합니다.

마이크로소프트에서 일하지 않는데 왜 WinUI가 관리 실수를 하고 있다고 하시는지 궁금합니다.
WinUI가 오픈 소스로 제공되고 모든 사람이 대화와 의사 결정에 기여한다는 바로 그 사실이 실제로 WinUI가 무엇인지 정의하는 데 도움이 되며 실수가 발생하지 않도록 방지해야 합니다.
DataGrid가 모바일과 동일한 경로를 따라 계속 진행되고 있다고 언급했지만 피치에서 모바일에 대한 언급을 본 적이 없습니다. 아마도 이 문제가 논의 중인 내용에 대한 피드백을 직접 유지할 수 있습니다.
WinUI에 잘못된 관리 단계가 있다고 생각되면 우려 사항에 대해 별도의 문제를 만들 수 있지만 실제로 귀하의 의견이 DataGrid 컨트롤과 관련이 있다고 생각하지 않습니다.

@verelpode 여기에서 주제에 대한 피드백을 유지하십시오. WinUI 또는 UWP에 대해 전반적으로 우려 사항이 있는 경우 새로운 토론 주제를 시작하거나 저에게 직접 연락하십시오(이메일 또는 트위터 DM). 또는 #717 또는 #1531과 같은 기존 주제에 대해 토론하는 것을 고려할 수 있습니다.

DataGrid가 C++로 다시 작성되는 것에 대한 우려를 공유했지만 실제로 원래 제안에서는 이에 대해 언급하지 않았습니다. @anawishnoff 는 DataGrid 기능 세트에 대한 피드백을 수집하려고 합니다. 구현 측면에서 C#으로 유지하는 것이 가장 합리적이라면 그렇게 할 것입니다(WinRT 구성 요소로 수행한 경우 C++에서 여전히 호출할 수 있음).

@jevansaks -- 제 피드백은 주제였지만 나쁜 소식을 전하는 메신저를 쏘는 것은 인간의 본성입니다. 당신의 반응은 저를 슬프고 실망스럽게 만듭니다. 알겠습니다. 도움이 필요하지 않습니다. 너무 정직하고 직접적이며 인정하고 해결하기에는 너무 고통스러운 고통스러운 문제를 다루기 때문입니다(WinRT의 치명적인 실패는 너무 많은 감정을 불러일으키므로 지우기가 더 쉽습니다. 메모리에서 삭제하고 재해가 발생하지 않은 것처럼 동일한 이전 원래 WinRT 계획을 계속합니다. 실제 문제에 대해 계속해서 정직하고 직접적으로 말하는 것은 사람들을 짜증나게 할 것이기 때문에 이 토론을 끝내고 DataGrid의 개발에 더 이상 참여하지 않을 것입니다.

@verelpode 여기에서 "나쁜 소식을 전하는 메신저를 쏜" 사람은 아무도 없습니다. @jevansaks 는 이 리포지토리에서 UWP/WinUI/WinRT에 대한 광범위한 우려를 공유하기 위해 새 문제를 열

당신이 언급한 문제는 WinUI 팀과 커뮤니티 모두가 관련된 흥미로운 토론의 기초가 될 수 있지만 이 특정 문제는 그러한 토론에 적합하지 않습니다.

@anawishnoff
Microsoft Pivot Viewer Control이 html이 아니라고 확신합니다. 다시 봐주세요. 이와 같은 것을 사용하여 대규모 데이터 세트를 시각화하는 기능은 우리가 한때 하고 싶었던 것이었습니다. Silverlight에서 사용할 수 있었던 것 같습니다. https://www.microsoft.com/silverlight/pivotviewer/default# Deep Zoom 기능을 사용했습니다. WinUI 3.0에 Deep Zoom 기능을 추가하면 정말 멋질 것입니다! 실제로 DataGrid가 아니라 Data Display 컨트롤입니다. Deep Zoom과 같은 WPF 초창기부터 많은 "포기된" 아이디어가 있지만 시간이 지나면서 WinUI 3.0에서 다시 살아나게 하는 프로덕션 WPF 컨트롤로 만들지 못했습니다. 젠장 WPF 박사를 지하실에서 꺼내서 다시 게시하게 하세요!!! 우리는 그가 다시 필요합니다. 운동을 시작해야 합니다. WPF 박사를 돌려주세요!!!!! 어디 갔다? 윈유이 박사!!!

@PaulMontgomerySP 는 피벗 제어에 대해 논의하기 위해 새로운 문제를 열어야 할 것 같습니다. https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/770 에서 Windows Community Toolkit에서 이에 대한 이전 토론을 참조하십시오.

키보드로 이동하는 각 행에 대해 선택 변경 이벤트가 발생합니다.
선택 변경 이벤트가 아니라 마우스 클릭이나 셀 탭에만 이벤트가 있으면 좋을 것입니다.

선택 변경 이벤트는 클릭 및 키보드 모두에 대해 발생합니다. 클릭만을 위한 이벤트가 있다면 큰 도움이 될 것입니다.

@Going-Gone 그 사용 사례가 무엇인지 궁금합니다. 차이점을 알아야 하는 이유는 무엇입니까? 또한 탭 이벤트를 사용할 수 없습니까?

방금 UWP Toolkit의 DataGrid에 부딪힌 한 가지 제한 사항은 DataGridTemplateColumn 에 CellTemplate이 있지만 CellTemplateSelector 없다는 것입니다( CellEditingTemplate 대해 동일한 누락). 셀렉터 접근 방식을 사용하여 각 셀의 UI를 데이터에 적용하는 작업을 단순화합니다. 이를 처리하기 위해 셀 아래에 있는 추가 수준의 UI 컨트롤로 이 작업을 수행할 필요가 없습니다.

여기에서 자세히 설명한 것처럼 연속적인 순서로 행을 선택할 뿐만 아니라 행을 선택할 수도 있습니다.
https://github.com/duke7553/files-uwp/issues/276#issue -520060100

그리드가 지원해야 하는 클라이언트가 자주 요청하는 특정 순서는 없습니다.

1. 필터를 저장, 로드 및 빌드하는 기능. 예를 들어 linq 표현식에 대한 필터, SQL 쿼리에 대한 필터, 표현식 트리에 대한 필터 및 그 반대입니다. 예 - https://querybuilder.js.org/demo.html

1. 고속 실시간 데이터 기능, 성능이 중요합니다. 거래 응용 프로그램의 1ms 미만 재생 빈도와 1백만 개 이상의 행은 성능 고려 사항이 다릅니다.
2. 정렬 순서를 지정하는 기능, 예: i. 높은/낮은 정렬, ii. 낮은/높은 정렬 및 iii. 종류가 없거나 나. 낮은/높은 정렬, ii. 높음/낮음 정렬 및 iii. 종류가 없다
3. 엑셀과 같은 필터링
4. 셀에 CSS 서식을 적용하는 기능, 조건부 서식
5. 필터, 열 너비, 정렬 등과 ​​같은 그리드 설정을 쉽게 저장/로드하는 기능
6. 작동하는 스크롤, 예를 들어 데이터 업데이트 후 재설정되지 않음, 부드럽게.
7. 데이터 수집 이벤트에는 개별 개체가 아닌 범위를 로드한 후 이벤트를 실행하는 옵션이 있어야 합니다. 예를 들어 ObservableCollection에는 추가된 각 개별 개체에 대해 INotifyPropertyChange 발생을 방지하기 위해 하위 클래스가 필요하다고 생각합니다.
8. 데이터 로드/로드, 데이터 로드 시작, 데이터 로드, 특히 비동기 로드를 사용하는 경우 데이터 로드에 대한 더 나은 이벤트.
9. 그리드는 종종 데이터 필터, 범위 선택, 교차 필터(예: https://github.com/dc-js/dc.js), 차트, 피벗 테이블 등과 같은 다른 컨트롤에 연결됩니다.
10. 영숫자 데이터를 처리하는 스마트 정렬(예: 정렬 순서 ABC11, ABC111, ABC12 대신 ABC11, ABC12, ABC111)
11. 무제한 수준의 계층적 그리드(예: https://docs.telerik.com/devtools/wpf/controls/radgridview/hierarchical-gridview/hierachy-overview)

유용한 리소스: - 더 나은 데이터 테이블 디자인
https://news.ycombinator.com/item?id=21460966
https://uxdesign.cc/design-better-data-tables-4ecc99d23356

헤더에서 직접 열 너비에 바인딩할 수 없습니다. WPF에서는 이 경우 BindingProxy 개체를 사용해야 합니다.

더 쉽게 편집할 수 있도록 활성 행의 편리한 동적 크기 조정.
편집 모드에서 상황에 맞는 메뉴를 완전히 제어합니다.

Telerik에서와 같이 CellDecorationStyleSelector를 지원하기를 바랍니다.

접근성!
문서화되도록 언급하지만 이 컨트롤은 완전히 액세스할 수 있어야 합니다.
현재 툴킷 버전은 https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3400 & https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3079 영역에서 몇 가지 제한 사항이 있습니다.
또한 Telerik RadDataGrid에는 몇 가지 훌륭한 기능이 있지만 접근성을 지원하지 않는 것 같습니다 .

D&I에 대한 Microsoft의 대대적인 추진으로 인해 모든 컨트롤에 완전히 액세스할 수 있어야 한다는 요구 사항이 모든 곳에서 요구 사항으로 지정되지 않았다는 사실에 놀랐습니다.

아마도 이것은 이미 가능하고 나는 아직 그것을 달성하는 방법을 모릅니다... 하지만 어떻게: 사용자 정의 행 또는 셀 스타일 지정?

특정 행을 대상으로 하고 배경 및 텍스트 색상을 변경하는 기능은 훌륭할 것입니다.

WCT UWP DataGrid와 비교하여:
1) 성능
2) 더 많은 기본 제공 열 유형(템플릿 열보다 성능이 더 좋다고 가정)
3) 셀당 마우스 이벤트 후크 기능
4) Cell별 키보드 이벤트
5) (3)을 실행할 수 없는 경우 적중 테스트 기능이 있는 경우 에뮬레이션할 수 있습니다.
6) 성능

WinUI DataGrid가 최종 사용자가 DataGrid 내부에서 인라인/직접적으로 셀 값을 편집할 수 있는 기능을 포기한다면 얼마나 많은 사람들이 이의를 제기할 것입니까?

VB6을 기억하는 사람이 있습니까? VB6 DataGrid는 즉시 편집, 삭제 및 AddNew를 지원했습니다. 추가는 목록 끝에 자동으로 추가되는 빈 행으로 사용할 수 있었습니다. 행을 완성하면 다른 빈 행이 나타납니다.

DataGrid에는 데이터 입력을 지원하는 옵션이 있어야 합니다. 대부분의 개발자가 이 기능을 기본적으로 끄기로 설정하는 것을 선호하는 경우에도 마찬가지입니다.

VB6 앱을 UWP로 이식할 때 추가/편집/삭제를 지원하기 위해 자체 데이터 그리드를 작성해야 했습니다.

여기에 기여하는 대부분은 WPF/Xaml 사람들인 것 같습니다. 이것은 xaml 사람이 아닌 사람에게서 2센트 가치가 있습니다.

내 소프트웨어에서 DataGrid 컨트롤을 많이 사용합니다. 편집 장소가 중요합니다! 내 소원/고통 사항 중 일부는 다음과 같습니다.

1. 편집 모드에서 상황에 맞는 메뉴를 사용자 정의하는 기능.
2. 열 자동 크기 조정 시 더 나은 성능과 더 많은 제어가 가능합니다. 필요한 경우 사용자가 크기를 제어할 수 있기를 원하지만 대부분은 필요하지 않습니다. 열 크기가 지속적으로 변경되는 것을 원하지 않지만 백만 행에 해당하는 데이터를 측정하지 않고도 데이터를 기반으로 하기를 원합니다.
3. 편집할 때 편집을 종료하지 않고 편집 중인 데이터에(또는 이와 함께) 작업을 수행하는 다른 컨트롤/버튼을 클릭할 수 있기를 원합니다. (이것은 #1이 구현된 경우 덜 필요하지만 여전히 유용합니다.)
4. DataError 이벤트를 사용하여 예외를 처리하는 현재 방식은 대략적입니다. (죄송합니다. 구체적으로 말씀드리기 어렵습니다. 하지만 과거에 여러 번 저를 아프게 했던 것으로 알고 있습니다.)
5. 내장된 자동 스크롤 기능이 좋을 것입니다: http://stackoverflow.com/questions/2567809/how-to-autoscroll-a-datagridview-during-drag-and-drop
6. 데이터가 "더티"인 경우를 나타내는 "워터마크"를 표시하는 기능(DataGridView에 대한 몇 가지 유용한 추가 개선 사항은 BetterGrid 를 참조
7. 필수 "키" 셀이 비어 있는 경우 행을 포기하는 기능(검증 오류 없이).
8. 사용자가 추가한 행에 대해 이미지를 표시하지 않는 기본 제공 기능(빨간색 X 대신). 참조: https://stackoverflow.com/questions/937919/datagridviewimagecolumn-red-x
9. 체크박스 열이 변경되면 즉시 커밋되도록 허용: https://stackoverflow.com/questions/11843488/how-to-detect-datagridview-checkbox-event-change

알파는 언제 출시될 예정인가요? 기부금을 받을 수 있습니까? 오래된 데이터 그리드를 버리고 특히 가상화 기능을 기대하고 있습니다.

이 스레드에 매우 늦은 입력을 넣어 죄송하지만 저에게는 "새로운" 것입니다 ;)
_컨트롤이 어떻게 작동하는지 조금 더 알아본 후 수정_

클라우드 드라이브용 인터페이스와 같은 탐색기를 만들기 위해 DataGrid와 함께 작업하면서 탭되는 행과 셀을 결정하는 것이 "해야"하는 것보다 약간 더 복잡할 수 있음을 발견했습니다(IMHO).

내 앱 디자인에서 행은 파일 또는 폴더(DriveItems)를 나타냅니다. 상세 보기는 항목에 대한 자세한 내용을 표시합니다.

폴더 항목을 클릭할 수 있는 기능을 만들고 인터페이스를 건너뛰고 해당 항목 목록을 만들어 드라이브 전체를 탐색할 수 있도록 하고 싶었습니다.

예를 들어 항목의 "상위" 열 항목(여기에서 /drive/root:/Documents/Vital%20Documents 탭하면 인터페이스가 해당 폴더로 재설정되고 거기에 파일이 나열됩니다.

셀에 대해 클릭된 이벤트를 얻을 수 있지만 해당 이벤트에는 탭된 셀(행, 예, 열 아님)을 결정하는 핸들러에 대한 컨텍스트가 없는 것 같으며 현재 확실하지 않습니다. 컨트롤을 사용하면 셀 탭 동작과 자동으로 열리는 세부 정보 동작을 모두 가질 수 있습니다(이를 허용하는 "해킹"이라고 부를 수 있는 것을 여전히 조사하고 있지만 디자이너가 컨트롤의 정상적인 기능을 무시하기 시작할 때 특히 문서화된 동작이 아니라 컨트롤 동작의 변경으로 인해 디자인이 손상될 위험이 있습니다.

이 모든, 또한 포함되어야 데이터 그리드는 현재 CurrentItem으로 DriveItem를 반환하는 이벤트를함으로써 내 시나리오를 지원하는 것 같습니다 말했다 CurrentColumn 전체가 될 것이라고 DataGridColumn 내에서 클릭 된 객체를 통해 열 이름을 추출할 수 있습니다. 이제 이벤트에서 조사할 수 있는 CurrentColumn 개체가 있다는 것을 깨달았습니다. 따라서 이벤트 인수로 사용하는 것이 더 좋지만 작동해야 합니다.

또한 세부 정보 동작에 대한 보다 엄격한 제어는 행의 아무 곳이나 클릭할 때마다 확장되는 대신 세부 정보가 특정 열을 클릭할 때만 자동 확장되도록 하는 것일 수 있습니다.

DataGridColumn 개체의 기본 클래스에는 각 열에 대해 기본적으로 true로 설정할 수 있는 ExpandDetails 속성이 있을 수 있습니다. 즉, 특정 열을 클릭하면 행이 확장됩니다. 속성이 false인 다른 항목은 그렇지 않습니다.

예를 들어 내 디자인에서 첫 번째 열은 파일 또는 폴더, 이미지 또는 사진, 오디오 등과 같은 항목 유형입니다. 해당 열을 자동 확장 동작을 일으키는 유일한 열로 설정하는 것을 구상할 수 있습니다. 그런 다음 경로 열을 클릭하면 위에서 설명한 "해당 경로 목록 가져오기" 동작이 발생할 수 있습니다.

정렬의 경우 디자이너가 다단계 정렬을 수행할 수 있도록 충분한 제어를 구현하는 것이 논리적으로 중요해 보입니다. 현재 컨트롤이 이벤트 및 콜백 후킹/재정의를 통해 이를 지원할 수 있는 방법을 확인하기 위해 조사를 수행하지 않았지만 간단해 보이지 않습니다.

마지막으로, 나는 당신이 이것을 잘 알고 있다는 것을 알고 있지만 (더 많은 기능을 요구하는 경우에도) 사용자가 DataGrid 위에 스스로 구현할 수 있는 복잡한 동작을 많이 추가하지 않도록 합시다. DataGrid에서 구현하지 않을 것 중 하나는 필터 또는 정렬 등을 외부에 저장하는 것과 관련이 있습니다. 또한 이 컨트롤을 Excel 복제본으로 만드는 것을 피합니다.

-고마워, 잘했어!
-이자형

고정 그룹: 큰 그룹이 있는 데이터 세트를 탐색할 때 보고 있는 그룹(또는 그룹, 즉, 이동 경로)에 대한 컨텍스트가 있어야 합니다. 이것은 그룹화된 목록 보기, 데이터 그리드 및 트리 보기와 같은 모든 계층적 목록 기반 보기에 필수적인 사용성 기능인 것 같습니다.

새 WinUI ItemsRepeater 컨트롤 위에 새 DataGrid 컨트롤을 빌드합니다. 그리고 해당 컨트롤은 ItemsSource를 개체로 노출합니다.
Object ItemsSource { get; set; };

@RBrid ~1년 후에 다시 돌아옵니다. 나는 ItemsRepeater에 ItemsSource 개체가 있지만 실제로 가상화된 데이터 소스 작업에 필요한 다음 인터페이스에 대한 기본 제공 지원이 없다는 것을 깨달았습니다.

• ISupportIncrementalLoading
• IItemsRangeInfo
• ISelectionInfo

- C++에서 DataGrid를 사용할 수 있도록 MVP를 가져오는 것은 어떻습니까?