Service Manager 작성 도구를 사용하여 양식 사용자 지정 및 작성 개요

아티클
11/06/2024

양식은 사용자가 데이터베이스의 개체와 상호 작용할 수 있도록 하는 창입니다. 사용자는 양식을 사용하여 개체의 속성을 보고 편집할 수 있습니다. 각 양식은 특정 클래스와 결합되어, 대상 클래스의 인스턴스에 대한 정보만 표시합니다. 양식에는 필드가 포함됩니다. 일반적으로 각 필드는 양식의 대상 클래스의 특정 속성에 바인딩됩니다. 예를 들어 인시던트 양식은 인시던트 개체와 결합됩니다. 따라서 인시던트 양식은 데이터베이스의 인시던트 개체에 대한 정보를 표시합니다.

Service Manager 양식은 Microsoft .NET Framework 어셈블리의 WPF(Windows Presentation Foundation) 양식 구현과 Service Manager 관리 팩의 양식 정의로 구성됩니다. 양식 정의는 양식이 나타내는 클래스와 양식의 다른 속성을 지정합니다.

양식에 대한 주요 개념

양식을 사용자 지정하려면 먼저 다음과 같은 양식 개념에 익숙해야 합니다.

양식 사용

양식 정의가 포함된 관리 팩을 Service Manager로 가져오면 양식 정의가 데이터베이스에 저장됩니다. 나중에 사용자가 개체를 표시해야 하는 Service Manager 콘솔 작업을 시작하면 Service Manager에서 요청된 개체를 표시할 양식을 찾아야 합니다. Service Manager는 데이터베이스에 액세스하고 해당 개체에 대해 정의된 양식을 검색합니다. 개체에 대해 정의된 양식이 없는 경우 Service Manager는 개체의 부모 개체에 대해 정의된 폼을 검색합니다. Service Manager는 정의된 양식을 찾을 때까지 전체 개체의 상속 계층 구조를 계속 검색합니다.

제네릭 양식

Service Manager가 개체 또는 해당 부모 개체에 대한 폼을 찾을 수 없는 경우 Service Manager는 해당 개체에 대한 기본 제 네릭 양식을 동적으로 빌드합니다. 일반 양식은 시스템에서 생성되는 양식으로, 단순한 양식 사용에 충분합니다. 일반 양식을 사용하면 양식을 정의하지 않고도 개체에 대한 양식을 쉽고 빠르게 만들 수 있습니다.

기본적으로 제네릭 양식은 변경할 수 없는 간단한 레이아웃으로 양식의 모든 속성을 표시합니다. 제네릭 양식은 양식의 상속 계층 구조에 있는 모든 부모 개체의 속성을 표시하며 해당 동작을 변경할 수 없습니다. 일반 양식에 대한 사용자 지정은 제한적입니다. 예를 들어 제네릭 폼을 표시할 속성을 지정할 수 있습니다. 그러나 제네릭 양식은 사용자 지정의 기준으로 사용할 수 없습니다. 나중에 해당 개체에 대한 사용자 지정 양식을 정의하면 사용자 지정 양식이 개체의 제네릭 폼을 덮어씁니다.

일반 양식에서 속성을 숨기는 방법과 일반 양식을 사용자 지정할 수 있는 기타 방법에 대해서는 블로그 게시물인 Overview of the Forms Infrastructure and the Generic Form(양식 인프라 및 일반 양식의 개요)을 참조하십시오.

양식의 조합 클래스

때로 둘 이상의 클래스에서 파생되는 정보를 표시하는 양식이 필요합니다. 이 작업을 수행하려면 조합 클래스 를 만든 다음 양식의 필드를 해당 다음 조합 클래스에 바인딩합니다. 조합 클래스에 대한 자세한 내용은 System Center 공통 스키마의 변경 내용을 참조하세요.

양식의 기능적 측면

양식에는 다음과 같은 기능적 측면이 있습니다.

초기화
크기 및 위치
보충
변경 내용 전송

이러한 측면은 다음 섹션에서 설명합니다.

초기화

초기화하는 동안 양식의 XAML(Extensible Application Markup Language)이 구문 분석되고 폼의 모든 컨트롤이 인스턴스화되고 로드됩니다. 폼의 Loaded 이벤트는 양식과 포함된 모든 요소가 로드된 시기를 나타냅니다. 데이터 로드 작업은 비동기적입니다. 따라서 Loaded 이벤트가 발생할 때 대상 인스턴스를 사용하지 못할 수 있습니다. 대신 양식에 대해 대상 인스턴스를 설정한 경우 알림에 DataContextChanged 이벤트를 사용해야 합니다. PropertyChanged 이벤트 대신 DataContext 속성의 DataContextChanged 이벤트를 사용할 수 있습니다.

제어 관련 사용자 지정 초기화에 Loaded 를 사용한 후 대상 인스턴스 관련 사용자 지정 초기화에 대한 DataContextChanged 속성에서 PropertyChanged 또는 DataContext 이벤트를 사용하는 것이 좋습니다.

크기 및 위치

팝업 창에 폼이 표시되면 폼의 너비, 높이, MinWidth 및 MinHeight 속성에 따라 초기 크기가 결정됩니다. 양식에 대해 이러한 속성이 설정되지 않은 경우 양식의 초기 크기는 해당 내용에 따라 계산됩니다.

이러한 속성을 다음과 같이 설정하는 것이 좋습니다.

양식의 Width 및 Height 속성을 설정하여 이상적인 크기를 명시적으로 지정합니다. 이러한 속성을 Auto 값으로 지정할 수 있습니다. 이 값은 콘텐츠 크기에 따라 양식의 너비와 높이를 설정합니다.
양식의 MinWidth 및 MinHeight 속성으로 양식에 허용되는 최소 창을 지정합니다. 사용자가 창의 크기를 지정된 것보다 작게 조절하면 숨은 양식 콘텐츠를 스크롤할 수 있도록 스크롤바가 나타납니다.

양식이 Service Manager 양식 호스트 내에서 호스트되는 경우 동일한 실행 세션 내에서 동일한 사용자가 해당 양식의 후속 표시를 위해 마지막으로 사용한 크기와 위치가 유지됩니다.

보충

양식의 대상 인스턴스는 양식에서 Refresh 명령을 실행한 결과로 변경될 수 있습니다. 이 명령의 처리기는 데이터베이스에서 새 데이터를 가져옵니다. 데이터가 도착하면 폼의 DataContext 속성 값이 새 대상 인스턴스로 설정되고 DataContextChanged 이벤트가 발생합니다.

양식을 처음 로드했을 때 발생하는 DataContextChanged 이벤트와 Refresh 명령을 처리하기 위해 발생한 이벤트를 구분하려면 이벤트와 함께 전달되는 이벤트 인수의 OldValue 속성을 확인합니다. 양식이 초기화되면 이 속성은 Null입니다.

변경 내용 전송

Service Manager의 양식 호스트 팝업 창은 양식에서 변경한 내용을 제출하고 팝업 창을 닫는 단추를 제공합니다.

사용자가 양식의 적용 단추를 선택하면 양식의 대상 인스턴스가 스토리지용으로 제출됩니다. 이 작업은 동기식입니다. 따라서 사용자는 제출 작업이 완료될 때까지 양식을 편집할 수 없습니다. 양식 전송 중 오류가 발생하면 오류 메시지가 나타납니다. 양식이 추가 변경을 위해 열린 상태로 남아 있습니다. 양식의 다른 인스턴스가 동시에 편집되는 경우 충돌을 방지하기 위해서 변경 내용을 자주 적용하는 것이 좋습니다.

사용자가 확인 단추를 선택하면 양식 제출 작업이 성공하면 양식과 호스트 창이 닫힌다는 점을 제외하고 동작은 적용과 유사 합니다.

사용자가 취소 단추를 선택하면 사용자에게 작업을 확인하도록 요청하는 대화 상자가 나타납니다. 사용자는 예를 선택하고 변경 내용을 손실하거나 아니요를 선택하고 양식으로 돌아갈 수 있습니다.

양식에 대한 일반 지침 및 모범 사례

양식을 추가하거나 수정하여 Service Manager의 기능을 확장할 수 있습니다. 이 섹션에서는 다양한 도구 및 스크립팅 양식 정의를 직접 사용하여 Service Manager 양식을 만들고 사용하기 위한 몇 가지 모범 사례 권장 사항을 설명합니다.

이 섹션은 주로 WPF(Windows Presentation Foundation) 및 Microsoft Visual Studio Team System 또는 Microsoft Expression Blend를 사용하여 고유한 사용자 지정 양식을 빌드한 경험이 있는 파트너 및 고객을 대상으로 합니다.

새로운 양식 제작에 대한 일반적인 지침은 다음과 같습니다.

표준 컨트롤을 사용합니다.
일반적인 양식 디자인 지침을 따릅니다.
코드 숨김을 방지합니다.
예외 처리를 포함합니다.
양식 사용자 지정 및 업그레이드를 고려합니다.
사용자 지정 가능한 모든 컨트롤의 이름을 지정합니다.
데이터 원본에 양식을 바인딩합니다.
Service Manager 양식 인프라 유효성 검사 규칙, 값 변환기 및 오류 템플릿을 사용합니다.
양식 인프라 명령 및 이벤트를 사용합니다.

이러한 지침에 대한 자세한 내용은 다음 섹션을 참조하십시오.

표준 컨트롤 사용

양식에서 사용할 수 있는 컨트롤은 다음과 같습니다.

표준 컨트롤 여기에는 콤보 상자 및 목록 상자와 같은 .NET 라이브러리 컨트롤이 포함됩니다.
사용자 지정 컨트롤 여기에는 양식 제작자 또는 제3자가 만든 추가 컨트롤이 포함됩니다.

팁

가능하면 표준 컨트롤을 사용하고 사용자 지정 컨트롤을 만들지 않으려는 경우 양식의 사용자 환경에 관계없이 일관성의 수준을 올립니다. 사용자 지정 컨트롤을 만들어야 하는 경우 컨트롤 모양을 정의하기 위해 컨트롤 템플릿을 사용하여 시각적 모양 및 동작과 논리적 동작을 분리합니다. Windows 테마마다 별도의 컨트롤 템플릿을 사용하는 것이 좋습니다.

일반 양식 디자인 지침 준수

양식을 디자인할 때 공용 디자인 지침을 따라서 양식이 사용자에게 친숙하고 공통 사용자 상호 작용 패러다임을 준수하도록 합니다.

일반 Windows 디자인에 대한 자세한 내용은 Windows User Experience Interaction Guidelines(Windows 사용자 환경 상호 작용 지침)를 참조하십시오.

추가:

양식을 더욱 간편하고 쉽게 읽을 수 있도록 여러 탭으로 정보를 나눕니다. 첫 번째 탭에서 가장 일반적으로 사용되는 정보와 후속 탭의 중요도가 낮은 정보를 포함합니다.
레이아웃 패널을 사용하여 양식에서 컨트롤의 레이아웃을 지정합니다. 이렇게 하면 폼의 크기가 조정되고 지역화될 때 양식이 올바르게 동작합니다.
개별 컨트롤의 시각적 속성을 설정하지 않고 스타일을 사용합니다. 이렇게 하면 스타일을 수정하여 일련의 양식에서 모든 컨트롤의 모양을 변경할 수 있으며 관련 양식에서 일관된 모양을 승격할 수 있습니다.

코드 숨김 방지

코드 숨김 은 XAML 페이지가 태그 컴파일되는 경우 태그 정의된 개체와 결합된 결합된 코드를 설명하는 용어입니다. 양식에서 가능한 한 코드 숨김의 사용을 제한합니다. 나중에 해당 코드를 변경하는 것이 더 쉽기 때문에 폼에 대한 코드를 컨트롤 자체에 포함하는 것이 좋습니다. 대신 Service Manager 양식 인프라에서 지원하는 선언적 기능을 사용하여 양식에서 값 변환 및 유효성 검사 규칙을 정의합니다.

일반적인 지침에서는 WPF 및 양식 인프라 라이브러리에 정의된 클래스와 함께 XAML의 선언적 기능을 사용하여 필요한 기능을 제공할 수 없는 상황으로 코드 숨김 사용을 제한해야 합니다. 이런 경우에도 코드 숨김에서 구현된 기능을 도우미 라이브러리로 이동한 후 XAML에서 참조합니다.

예외 처리 포함

작성 도구의 디자인 단계와 런타임에 Service Manager 콘솔에서 양식을 로드할 수 있도록 양식의 코드에 예외 처리가 포함되어 있는지 확인합니다.

양식 사용자 지정 및 업그레이드 고려

새 양식을 디자인할 때는 향후 사용자 지정 및 해당 양식으로의 업그레이드를 고려해야 합니다. 사용자 지정을 유지하면서 양식을 사용자 지정하고 업그레이드할 수 있도록 하려면 다음 지침과 함께 이 섹션의 이전에 제공된 지침과 팁을 따르세요.

양식을 디자인하는 동안 나중에 사용자 지정하고 업그레이드하는 것이 좋습니다. 양식은 이후 버전에서 진화할 가능성이 높으며, 사용자가 사용자 지정을 원래 양식으로 유지하면서 새 버전의 양식으로 업그레이드할 수 있는 방법을 고려하는 것이 중요합니다. 예를 들어 사용자가 원래 양식을 사용자 지정하는 데 상당한 시간과 노력을 쏟은 후 업데이트된 양식을 제공해야 할 수 있습니다. 이런 경우 사용자는 버전을 업그레이드해도 사용자 지정이 유지되길 바랍니다.
사용자 지정이 컨트롤에 적용될 수 있도록 양식의 각 컨트롤에 고유한 이름을 제공합니다. 양식 사용자 지정은 특정 컨트롤 또는 컨트롤 집합을 대상으로 하는 작업의 집합으로 저장됩니다. 대상 컨트롤은 이름으로 참조되므로 양식 버전 간에 컨트롤 이름을 유지하는 것이 중요합니다. 컨트롤에 이름이 없으면 폼 사용자 지정 편집기에서 이름을 생성하지만 생성된 이름은 양식의 여러 버전에서 유지되지 않습니다.
컨트롤 이름이 양식의 여러 버전에서 변경할 수 없는 상태로 유지되는지 확인합니다. 그래야 이전 버전에서 제공된 컨트롤의 사용자 지정이 새로운 버전의 양식에서 동일한 컨트롤에 적용될 수 있습니다.
가능하면 양식을 업그레이드할 때 동일한 탭의 다른 위치로 컨트롤을 이동하지 않습니다. 일반적인 사용자 지정은 양식의 컨트롤을 다른 위치로 이동합니다. 폼의 새 버전에서 컨트롤의 위치를 변경하는 경우 새 컨트롤 위치가 사용자가 재배치한 컨트롤과 겹칠 위험이 있습니다.
가능하면 기존 양식에 대한 업데이트를 디자인할 때 탭 간에 컨트롤을 이동하지 마세요. 컨트롤은 이름 및 해당 컨트롤이 있는 탭으로 식별됩니다. 새로운 버전의 양식에서 탭 간에 컨트롤을 이동하면 사용자 지정이 대상 컨트롤을 확인할 수 없으므로 사용자가 해당 컨트롤에 대해 수행한 사용자 지정이 중단될 수 있습니다.
양식 업데이트에 새 컨트롤이 포함된 경우 새 탭에 새 컨트롤을 추가하는 것이 좋습니다. 이는 기존 탭 및 컨트롤에 대한 사용자 사용자 지정을 방해하지 않는 가장 안전한 방법입니다.
컨트롤의 바인딩 방법을 알아둡니다. 읽기 전용 컨트롤은 단방향 바인딩만 사용해야 합니다.

모든 사용자 지정 가능한 컨트롤 이름 지정

컨트롤이 바인딩되는 데이터나 컨트롤의 기능을 설명하는 컨트롤 이름을 사용합니다.

데이터 원본에 양식 바인딩

양식의 주요 목적은 Service Manager 데이터베이스에서 단일 개체를 시각화하는 것입니다. 이 개체를 target instance라고 하며, 항상 양식의 DataContext 속성( FrameworkElement 클래스에서 상속됨)으로 지정됩니다.

Important

양식의 DataContext 속성을 수정하지 마세요. 양식 호스트 환경은 이 속성을 사용하여 양식 대상 인스턴스를 식별합니다.

Service Manager 데이터 모델에서 대상 인스턴스는 BindableDataItem 개체로 표시됩니다. 이 클래스는 기본 SDK(소프트웨어 개발 키트) 개체를 집계하고 속성 이름을 매개 변수로 사용하는 인덱서를 통해 속성을 공개합니다.

또한 BindableDataItem 클래스는 ICustomTypeDescriptor를 구현하므로, BindableDataItem 클래스를 WPF 바인딩을 위한 데이터 원본으로 사용할 수 있습니다. 다음은 Text 컨트롤의 TextBox 속성에 대상 인스턴스 속성을 바인딩하는 예입니다.


<TextBox Name="textBoxDescription" Text="{Binding Path=Summary}"/>

대상 인스턴스가 폼의 모든 컨트롤에 대한 기본 원본 역할을 하는 양식의 DataContext로 설정되므로 바인딩의 원본을 지정할 필요가 없습니다.

폼의 컨트롤은 대상 인스턴스가 아닌 데이터 원본에 바인딩할 수 있으며 양식 인프라 라이브러리에는 바인딩을 암시적으로 수행하는 많은 컨트롤이 포함되어 있습니다. 예를 들어 인스턴스 선택 컨트롤은 선택할 인스턴스의 컬렉션을 제공하는 데이터 원본에 바인딩됩니다. ObjectDataProvider 및 XmlDataProvider 클래스를 사용하여 선언적으로 추가 데이터 원본을 정의할 수도 있습니다.

양식 인프라는 대상 인스턴스를 양식의 유일한 읽기/쓰기 데이터 원본으로 간주합니다. 따라서 Submit 명령을 구현하면 대상 인스턴스의 변경 내용만 저장됩니다. 양식의 다른 데이터 원본은 읽기 전용으로만 처리됩니다.

Service Manager 양식 인프라 유효성 검사 규칙, 값 변환기 및 오류 템플릿 사용

양식의 양식 인프라 유효성 검사 규칙을 사용하여 유효하지 않은 데이터 입력을 지정하는 것이 좋습니다. WPF 바인딩 인프라는 단방향 또는 양방향 바인딩을 사용하여 데이터 원본에 바인딩되는 컨트롤 속성의 유효성 검사를 지원합니다. 바인딩 개체에는 임의 개수의 ValidationRule 개체를 포함할 수 있는 ValidationRules 컬렉션이 있습니다. 컨트롤에서 데이터 원본으로 데이터를 밀어넣을 때마다 ValidationRule 개체가 호출되어 값의 유효성을 검사합니다.

양식 인프라 라이브러리에는 가장 일반적인 사례를 처리하는 많은 유효성 검사 규칙이 포함되어 있습니다. 양식 인프라는 유효성 검사 규칙을 사용하여 저장하도록 양식 콘텐츠를 제출할 수 있는지 여부를 결정합니다. 예를 들어 폼에 유효성 검사 오류가 있는 컨트롤이 있는 경우 폼 의 제출 단추를 사용하지 않도록 설정할 수 있습니다.

양식 인프라 라이브러리와 함께 제공되는 사용자 지정 오류 템플릿을 사용하는 것이 좋습니다. 컨트롤에 유효성 검사 오류가 있는 경우 기본적으로 빨강 테두리가 나타납니다. WPF를 사용하면 모든 컨트롤에서 설정할 수 있는 Validation.ErrorTemplate 속성을 통해 사용자 지정 오류 표시기를 정의할 수 있습니다. Service Manager 양식 인프라 라이브러리에는 WPF 빨간색 테두리 대신 오류 아이콘을 표시하는 사용자 지정 오류 템플릿이 포함되어 있습니다. 또한 마우스로 오류 아이콘을 가리키면 오류 메시지와 함께 도구 설명이 나타납니다. 오류 메시지는 컨트롤의 데이터가 유효성 검사에 실패한 이유를 나타냅니다.

다음 예에서는 XAML의 오류 템플릿을 참조하는 방법을 보여 줍니다.


<TextBox Text="{Binding SomeProperty}"
         scwpf:Validation.ValueRequired="True"
         Validation.ErrorTemplate="{DynamicResource {ComponentResourceKey {x:Type scwpf:Validation}, InvalidDataErrorTemplate}}"/>

기본 제공 유효성 검사 규칙이 필요한 유효성 검사 논리를 제공하지 않는 경우 해당 논리를 나타내는 사용자 지정 유효성 검사 규칙을 빌드하는 것이 좋습니다. 그렇게 하면 표준 유효성 검사 논리와 사용자 지정 유효성 검사 논리가 공통 유효성 검사 처리 메커니즘 내에 공존할 수 있습니다.

유효성 검사 규칙 메커니즘이 특정 시나리오에 적합하지 않은 경우 FormEvents.PreviewSubmitEvent를 대신 처리하고 여기에서 유효성 검사를 실행해야 합니다.

다음 코드 예는 사용자 지정 유효성 검사를 실행하기 위해 사용할 수 있는 패턴의 예를 제공합니다.


void MyForm_Loaded(object sender, RoutedEventArgs e)
{
    // hook to handle form events
    this.AddHandler(
        FormEvents.PreviewSubmitEvent,
        new EventHandler<PreviewFormCommandEventArgs>(this.OnPreviewSubmit));
}
private void OnPreviewSubmit(object sender, PreviewFormCommandEventArgs e)
{
    string errorMessage;
    bool result = this.DoVerify(out errorMessage);
    if (!result)
    {
        // cancel Submit operation
        e.Cancel = true;
        // display error message
        MessageBox.Show(errorMessage);
    }
}
internal bool DoVerify(out string errorMessage)
{
    // Do custom verification and return true to indicate that
    // validation check has passed; otherwise return false and
    // populate errorMessage argument
}

양식 인프라 명령 및 이벤트 사용

양식 인프라는 양식에서 실행할 수 있는 많은 명령을 노출합니다. 이러한 명령은 다음과 같습니다.

FormsCommand.Submit는 양식의 대상 인스턴스를 저장합니다.
FormsCommand.SubmitAndClose는 양식의 대상 인스턴스를 저장하고 양식을 닫습니다.
FormsCommand.Refresh는 양식의 대상 인스턴스에 대한 쿼리를 반복합니다.
FormCommands.Cancel- 모든 변경 내용을 삭제하고 양식을 닫습니다.

이러한 각 명령은 명령 실행 전후에 발생하는 이벤트에 따라 괄호로 묶입니다.

명령 전에는 다음 이벤트가 발생합니다.

FormEvents.PreviewSubmit 이벤트는 FormCommand.Submit 명령 전에 발생하고, FormEvents.Submitted 이벤트는 FormCommand.Submit 명령 후에 발생합니다.
FormEvents.PreviewRefresh 이벤트는 FormCommands.Refresh 명령 전에 발생하고, FormCommand.Refreshed 명령은 FormCommand.Submit 명령 후에 발생합니다.
FormEvents.PreviewCancel 이벤트는 FormCommands.Cancel 명령 전에 발생하고, FormCommand.Canceled 이벤트는 FormCommand.Cancel 명령 후에 발생합니다.

미리 보기 이벤트는 PreviewFormCommandEventArgs 개체를 통해 전달됩니다. 이 개체에는 속성이 Cancel 로 설정될 때 해당 명령이 실행되지 않도록 방지하는 변경 가능한 true속성이 있습니다.

명령 후 발생하는 이벤트는 FormCommandExecutedEventArgs 개체를 전달합니다. 이 개체에는 명령 실행이 성공 또는 취소되었는지 아니면 오류를 일으켰는지 여부를 나타내는 Result 속성이 있습니다. 오류가 발생하는 경우 FormCommandExecutedEventArgs 개체의 Error 속성은 오류에 대한 정보를 제공하는 예외를 참조합니다.

양식 명령을 프로그래밍 방식과 선언적으로 모두 사용, 사용 안 함 및 실행할 수 있습니다.

양식 명령을 프로그래밍 방식으로 사용하도록 설정하려면 양식 및 관련 명령 간에 CommandBinding 을 설정합니다.

다음 예에서 명령 바인딩은 양식과 Refresh 명령 간에 설정되며 이 명령에 대해 두 처리기가 정의됩니다. 첫 번째 처리기는 Refresh 명령을 실행할 수 있는지 여부를 반환하고 두 번째 처리기에는 실제로 Refresh 명령의 구현이 포함됩니다.


    public class MyForm : UserControl
    {
        public MyForm()
        {
            // do standard initialization
            // establish CommandBinding for Refresh command
            this.CommandBindings.Add(
                new CommandBinding(FormCommands.Refresh, this.ExecuteRefresh, this.CanExecuteRefresh));
        }
        private void CanExecuteRefresh(
              object sender,
              CanExecuteRoutedEventArgs e)
        {
            // put your logic that determines whether Refresh
// can be executed here
            bool canExecute = true;
            BindableDataItem dataItem = this.DataContext as BindableDataItem;
            if (dataItem)
            {
                canExecute = dataItem["Status"] != "New";
            }
            e.CanExecute = canExecute;
        }
        private void ExecuteRefresh(
            object sender,
            ExecutedRoutedEventArgs e)
        {
            // here is placeholder for the code that has do be
// executed upon running Refresh command
        }
    }

또한 양식 명령에 대해 처리기를 선언적으로 정의할 수 있습니다. RoutedCommandTrigger 를 사용하는 Rule개체를 통해 처리기를 정의할 수 있습니다. 다음 코드 예는 처리기를 선언적으로 정의하는 방법을 보여 줍니다.


    <scwpf:BusinessLogic.Rules>
        <scwpf:RuleCollection>
            <scwpf:Rule>
                <scwpf:Rule.Triggers>
                    <scwpf:RoutedCommandTrigger
RoutedCommand="{x:Static scwpf:FormCommands.Refresh}"/>
                </scwpf:Rule.Triggers>
                <scwpf:Rule.Conditions>
                    <scwpf:PropertyMatchCondition
                        Binding="{Binding Status}"
                        Value="New"
                        Operation="NotEquals" />
                </scwpf:Rule.Conditions>
                <!-- Use RuleAction objects to define the logic that executed
                upon running Refresh command; this can be left empty -->
            </scwpf:Rule>
        </scwpf:RuleCollection>
    </scwpf:BusinessLogic.Rules>

다음을 통해 공유