다음을 통해 공유

속성 변경 이벤트

  • 아티클

WPF(Windows Presentation Foundation)는 속성 값 변경에 대한 응답으로 발생하는 여러 이벤트를 정의합니다. 일반적으로 속성은 종속성 속성입니다. 이벤트 자체가 라우트된 이벤트인 경우도 있고 표준 CLR(공용 언어 런타임) 이벤트인 경우도 있습니다. 이벤트 정의는 시나리오에 따라 달라집니다. 일부 속성 변경은 요소 트리를 통해 더 적절하게 라우트되지만 다른 속성 변경은 일반적으로 해당 속성이 변경한 개체에만 영향을 미치기 때문입니다.

속성 변경 이벤트 식별

속성 변경을 보고하는 일부 이벤트는 시그니처 패턴 또는 명명 패턴 덕분에 속성 변경 이벤트로 명시적으로 식별되지 않습니다. 일반적으로 SDK 문서의 이벤트 설명은 이벤트가 속성 값 변경에 직접 연결되고 속성과 이벤트 간의 상호 참조를 제공하는지 여부를 나타냅니다.

RoutedPropertyChanged 이벤트

특정 이벤트에서는 속성 변경 이벤트에 명시적으로 사용되는 이벤트 데이터 형식 및 대리자를 사용합니다. 이벤트 데이터 형식은 RoutedPropertyChangedEventArgs<T>이고 대리자는 RoutedPropertyChangedEventHandler<T>입니다. 이벤트 데이터와 대리자는 둘 다 처리기를 정의할 때 변경 중인 속성의 실제 형식을 지정하는 데 사용되는 제네릭 형식 매개 변수를 포함합니다. 이벤트 데이터에는 두 가지 속성 OldValue 및 NewValue가 포함되고 이러한 속성은 둘 다 이벤트 데이터에 형식 인수로 전달됩니다.

이름의 "Routed" 부분은 속성 변경 이벤트가 라우트된 이벤트로 등록되었음을 나타냅니다. 속성 변경 이벤트를 라우트하는 방법의 장점은 자식 요소의 속성(컨트롤의 복합 부분) 값이 변경될 경우 최상위 컨트롤이 속성 변경 이벤트를 수신할 수 있다는 점입니다. 예를 들어, Slider와 같은 RangeBase 컨트롤을 통합하는 컨트롤을 만들 수 있습니다. 슬라이더 부분에서 Value 속성 값이 변경되면 해당 부분이 아닌 부모 컨트롤에서 해당 변경 사항을 처리할 수 있습니다.

이전 값과 새 값이 있으므로 이 이벤트 처리기를 속성 값에 대한 유효성 검사기로 사용하려고 할 수 있습니다. 하지만 이 방법은 대부분 속성 변경 이벤트의 디자인 의도가 아닙니다. 일반적으로 코드의 다른 논리 영역에서 값에 대한 작업을 수행할 수 있도록 해당 값이 제공되지만, 실제로 이벤트 처리기 내의 값을 변경하는 것은 좋지 않고 이로 인해 처리기 구현 방식에 따라 의도치 않은 재귀가 발생할 수 있습니다.

속성이 사용자 지정 종속성 속성이거나 인스턴스화 코드를 정의한 파생 클래스를 사용 중인 경우 속성 시스템이 CoerceValueCallback 및 PropertyChangedCallback을 콜백하는 훨씬 더 유용한 속성 변경 추적 메커니즘이 WPF 속성 시스템에 기본 제공됩니다. WPF 속성 시스템을 유효성 검사 및 강제 변환에 사용하는 방법에 대한 자세한 내용은 종속성 속성 콜백 및 유효성 검사 및 사용자 지정 종속성 속성을 참조하세요.

DependencyPropertyChanged 이벤트

속성 변경 이벤트 시나리오에 포함된 또 다른 형식 쌍은 DependencyPropertyChangedEventArgs 및 DependencyPropertyChangedEventHandler입니다. 이러한 속성 변경에 대한 이벤트는 라우트되지 않습니다. 이러한 이벤트는 표준 CLR 이벤트입니다. DependencyPropertyChangedEventArgs는 EventArgs에서 파생되지 않기 때문에 비정상적인 이벤트 데이터 보고 형식입니다. DependencyPropertyChangedEventArgs는 클래스가 아닌 구조체입니다.

DependencyPropertyChangedEventArgs 및 DependencyPropertyChangedEventHandler를 사용하는 이벤트는 RoutedPropertyChanged 이벤트보다 약간 더 일반적입니다. 이러한 형식을 사용하는 이벤트의 예는 IsMouseCapturedChanged입니다.

RoutedPropertyChangedEventArgs<T>와 마찬가지로 DependencyPropertyChangedEventArgs도 속성의 이전 값과 새 값을 보고합니다. 또한 이러한 값으로 수행할 작업에 대해 같은 사항을 고려해야 합니다. 일반적으로 이벤트에 대한 응답으로 sender에서 값을 다시 변경하지 않는 것이 좋습니다.

속성 트리거

속성 트리거는 속성 변경 이벤트와 밀접한 관계가 있습니다. 속성 트리거는 스타일 또는 템플릿 내에서 만들어지고 이를 통해 속성 트리거에 할당된 속성 값에 따라 조건부 동작을 만들 수 있습니다.

속성 트리거의 속성은 종속성 속성이어야 합니다. 읽기 전용 종속성 속성일 수 있고 대부분 이러한 속성입니다. 컨트롤이 표시하는 종속성 속성이 최소한 부분적으로 속성 트리거로 디자인된 경우를 나타내는 좋은 지표는 속성 이름이 "Is"로 시작되는 경우입니다. 일반적으로 이렇게 이름이 지정된 속성은 읽기 전용 부울 종속성 속성입니다. 이 종속성 속성에 대한 기본 시나리오는 실시간 UI에 대한 결과를 생성할 수 있는 컨트롤 상태를 보고하므로 속성 트리거의 후보가 됩니다.

이러한 속성 중 일부에는 전용 속성 변경 이벤트도 있습니다. 예를 들어, IsMouseCaptured 속성에는 속성 변경 이벤트 IsMouseCapturedChanged가 있습니다. 속성 자체는 읽기 전용이고 값은 입력 시스템에서 조정되며 입력 시스템은 실시간 변경이 발생할 때마다 IsMouseCapturedChanged를 발생시킵니다.

실제 속성 변경 이벤트에 비해 속성 변경에 대한 작업을 수행하는 속성 트리거 사용에는 몇 가지 제한 사항이 있습니다.

속성 트리거는 정확한 일치 논리를 진행합니다. 속성과 함께 트리거가 작업을 수행할 특정 값을 지정합니다. 예: <Setter Property="IsMouseCaptured" Value="true"> ... </Setter>. 이 제한 사항 때문에 대부분의 속성 트리거는 부울 속성 또는 전용 열거형 값을 사용하는 속성에 사용됩니다. 여기서 가능한 값 범위는 각 경우에 대한 트리거를 정의할 만큼 충분히 관리하기 쉽습니다. 또는 속성 트리거는 항목 개수가 0에 도달하는데 속성 값이 다시 0이 아닌 수로 변경될 때 이를 처리할 트리거가 없는 경우와 같은 특수 값에 대해서만 존재할 수 있습니다. 모든 경우에 대한 트리거 대신에 여기에는 코드 이벤트 처리기가 필요하거나 값이 0이 아닐 때 다시 트리거 상태에서 전환되는 기본 동작이 필요할 수 있습니다.

속성 트리거 구문은 프로그래밍의 "if" 문과 비슷합니다. 트리거 조건이 true이면 속성 트리거의 “본문”이 “실행”됩니다. 속성 트리거의 “본문”은 코드가 아니라 태”그입니다. 해당 태그는 스타일 또는 템플릿이 적용되는 개체의 다른 속성을 설정하는 데 하나 이상의 Setter 요소를 사용하도록 제한됩니다.

가능한 값을 다양하게 적용할 수 있는 속성 트리거의 "if" 조건을 오프셋하려면 일반적으로 Setter를 사용하여 동일한 속성 값을 기본값으로 설정하는 것이 좋습니다. 이 방법을 사용하면 트리거 조건이 true일 경우 Trigger에 포함된 setter가 우선 적용되고 Trigger에 포함되지 않은 Setter는 트리거 조건이 false일 때마다 우선 적용됩니다.

일반적으로 속성 트리거는 같은 요소에서 또 다른 속성 상태에 따라 하나 이상의 모양 속성을 변경해야 하는 시나리오에 적합합니다.

속성 트리거에 대한 자세한 내용은 스타일 지정 및 템플릿을 참조하세요.

참고 항목