Windows Phone의 텍스트

2013-12-05

적용 대상: Windows Phone 8 | Windows Phone OS 7.1

 

이 항목에서는 이벤트의 프로그래밍 개념을 소개하고 Windows Phone 및 해당 프로그래밍 모델에서 이러한 이벤트 개념이 어떻게 적용되는지에 대해 설명합니다. Windows Phone 이벤트는 CLR(공용 언어 런타임) 및 .NET Framework에서 정의한 이벤트 개념과 기본적으로 동일합니다. WPF와 마찬가지로 XAML에서 UI 요소 선언의 일부로 이벤트 처리기를 할당하거나 언어별 구문을 사용하여 코드에 처리기를 추가할 수 있습니다. Windows Phone 에서는 라우트된 이벤트 개념을 지원하므로 특정 입력 이벤트와 데이터 이벤트를, 해당 이벤트를 발생시킨 개체가 아닌 다른 개체로 처리할 수 있습니다. 라우트된 이벤트는 컨트롤 템플릿을 합성할 때 또는 앱 페이지의 이벤트 논리를 중앙에서 처리할 때 유용합니다.

이 항목에는 다음 단원이 포함되어 있습니다.

 

이벤트는 동작의 발생을 알리기 위해 개체에서 보내는 메시지입니다. 이 동작은 화면 터치와 같은 사용자 상호 작용으로 일어나거나 내부 클래스 논리에 의해 트리거될 수 있습니다. 이벤트를 발생시키는 개체를 이벤트 전송자라고 하며 이벤트를 캡처하고 이벤트에 응답하는 개체를 이벤트 수신자라고 합니다. 기본적으로 이벤트의 용도는 런타임 시 개체로부터 상대적으로 크기가 작은 시간별 정보를 받아서 이 정보를 앱의 다른 개체에 제공하는 것입니다.

Windows Phone 이벤트

일반적으로 Windows Phone 이벤트는 CLR 이벤트이므로 관리 코드를 사용하여 처리할 수 있습니다. 기본 CLR 이벤트를 사용하는 방법을 알고 있다면 관련된 일부 개념을 바로 활용할 수 있습니다. 그러나 처리기 연결과 같은 일부 기본적인 작업을 수행하기 위해서는 CLR 이벤트 모델에 대해 많은 지식이 필요하지 않습니다.

일반적인 Windows Phone 기반 앱의 UI는 태그(XAML)에서 정의되므로, UI 이벤트를 태그 요소에서 런타임 코드 항목에 연결하는 일부 원리는 ASP.NET 등의 다른 웹 기술이나 HTML DOM을 사용할 때와 유사합니다. Windows Phone 에서 XAML에 정의된 UI에 대한 런타임 논리를 제공하는 코드는 코드 숨김 또는 코드 숨김 파일이라고도 합니다. Visual Studio 솔루션 뷰에서 이 관계는 그래픽으로 표시되며, 여기서 코드 숨김 파일은 참조 대상 XAML 페이지에 대한 종속 및 중첩 파일입니다.

Windows Phone 에는 고유한 런타임 개체 모델 내에서 작동하는 CLR 이벤트 외에 OnError와 같이 HTML 수준에서 스크립트 기반 처리기를 호출할 수 있는 몇 가지 이벤트도 포함됩니다. 이러한 이벤트는 노출되어 HTML DOM의 플러그 인 인스턴스에서 작동하는 스크립트를 사용하여 처리될 수 있습니다. 앱용 일반 이벤트 모델인 HTML 스크립팅이 먼저 이벤트를 처리해야 하며, HTML에서 이벤트를 처리하는 경우 이러한 이벤트가 관리되는 API로 전달되어서는 안 됩니다.

Windows Phone 은 UI 기술이므로 가장 일반적인 작업 중 하나는 UI에 대한 사용자 입력을 캡처하는 것입니다. 예를 들어 UI에 사용자가 정보를 제출하거나 앱 상태를 변경하려면 탭해야 하는 버튼이 있을 수 있습니다.

일반적으로 XAML을 생성하여 Windows Phone 기반 앱의 UI를 정의합니다. 이 XAML은 디자이너(예: Visual Studio용 Blend ) 또는 대규모 IDE(예: Windows Phone)의 디자인 화면 출력일 수 있습니다. 일반 텍스트 편집기나 타사 XAML 편집기에서 XAML을 작성할 수도 있습니다. XAML을 생성할 때 UI 요소를 설명하는 다른 모든 특성을 정의하는 동시에 개별 UI 요소에 대한 이벤트 처리기를 연결할 수 있습니다.

Windows Phone 을 사용할 경우 디자인 기능을 사용해 XAML의 이벤트 처리기를 간단히 연결한 다음 코드 숨김에 정의할 수 있습니다. 이 과정에서 처리기에 대해 자동 이름 지정 체계도 제공합니다.

또한 Windows Phone 용 .NET Framework 클래스 라이브러리 설명서를 사용하여 특정 이벤트를 찾아보고 해당 대리자를 확인할 수 있습니다. 작성한 처리기는 해당 대리자 시그니처와 호환되어야 합니다. 이전 예제에서 가장 적합한 대리자는 RoutedEventHandler입니다.

참고참고:

Windows Phone 이벤트 처리기 함수는 매개 변수 값(비어 있는 값 포함)으로 호출할 수 없으며 HTML DOM의 이벤트 처리기 구문과 많은 차이가 있습니다. XAML의 특성 값은 처리기 이름만 참조하며 정보는 해당 처리기에 필요한 입력 매개 변수와 같은 다른 메커니즘을 통해 전달됩니다.

XAML에 선언된 UI 개체의 경우 이벤트 처리기 코드가 XAML 페이지의 코드 숨김 역할을 수행하는 partial 클래스에 정의되어야 합니다.

partial 클래스의 이벤트 처리기는 특정 이벤트에 사용되는 CLR 대리자를 기반으로 하는 메서드로 작성됩니다. 이벤트 처리기 메서드는 공개 또는 비공개 액세스 수준을 가질 수 있습니다. XAML에서 만들어지는 처리기와 인스턴스는 최종적으로 코드 생성을 통해 결합되기 때문에 전용 액세스가 작동합니다. 대개의 경우에는 이벤트 처리기 메서드를 클래스에서 public으로 만들지 않는 것이 좋습니다.

관리되는 Windows Phone 이벤트에 대해 작성하는 처리기는 해당 처리기가 호출되는 경우에 입력으로 사용할 수 있는 두 가지 값에 액세스할 수 있습니다. 그 중 첫 번째 값은 처리기가 연결되는 개체에 대한 참조인 sender입니다. sender 매개 변수는 기본 Object 형식으로 지정됩니다. Windows Phone 이벤트 처리에서 일반적으로 사용되는 기술은 보다 정확한 형식으로 sender를 캐스팅하는 것입니다. 이 기술은 sender 개체 자체에서 상태를 확인하거나 변경하려는 경우에 유용합니다. 사용자 고유의 앱 디자인에 따라, 처리기가 연결되는 위치 또는 기타 디자인 고유 정보를 기준으로 sender를 안전하게 캐스팅할 수 있는 형식이 필요합니다.

두 번째 값은 이벤트 데이터로, 일반적으로 시그니처에서 e 매개 변수로 나타납니다. CLR 이벤트 모델별로 모든 이벤트는 EventArgs를 상속하거나 EventArgs 자체인 클래스 인스턴스로 캡처되는 데이터와 함께 몇 가지 종류의 이벤트 데이터를 전송합니다. 처리하는 특정 이벤트에 할당된 대리자의 e 매개 변수를 찾아본 다음 Visual Studio의 Intellisense 또는 Windows Phone 용 .NET Framework 클래스 라이브러리를 사용하여 이벤트 데이터에서 사용 가능한 속성을 확인할 수 있습니다. 일부 Windows Phone 이벤트는 EventHandler<TEventArgs> 대리자나 다른 제네릭 처리기 형식을 사용합니다. 대부분의 경우 이벤트 정의는 특정 EventArgs 파생 이벤트 데이터 클래스로 제네릭을 제한합니다. EventArgs 파생 이벤트 데이터 클래스를 직접 두 번째 매개 변수로 사용한 것처럼 처리기 메서드를 작성해야 합니다.

일부 이벤트의 경우 EventArgs 파생 클래스의 이벤트 데이터는 이벤트 발생을 인식하는 것만큼 중요하며 입력 이벤트의 경우 특히 그렇습니다. 키보드 이벤트의 경우 키보드의 키를 누르면 동일한 KeyUpKeyDown 이벤트가 발생합니다. 사용자가 누른 키를 확인하려면 이벤트 처리기에서 사용할 수 있는 KeyEventArgs에 액세스해야 합니다.

XAML을 사용해서만 개체에 이벤트 처리기를 할당할 수 있는 것은 아닙니다. XAML에서 사용할 수 없는 개체를 포함하여 관리 코드의 지정된 개체에 이벤트 처리기를 추가하려면 CLR 언어 관련 구문을 사용하여 이벤트 처리기를 추가합니다.

C# 구문에서는 += 연산자를 사용합니다. 이벤트 처리기 메서드 이름을 사용하는 새 대리자를 선언하여 처리기를 인스턴스화합니다.

런타임 UI에 표시되는 개체에 이벤트 처리기를 추가하는 코드를 사용할 경우 Windows Phone 에서는 일반적으로 Loaded 또는 OnApplyTemplate 등과 같은 개체 수명 이벤트 또는 콜백에 대한 응답으로 이벤트 처리기를 추가하여 런타임 시 사용자가 시작한 이벤트에서 관련 개체에 이벤트 처리기를 사용할 수 있도록 합니다.

Visual Basic 구문에서 사용할 수 있는 다른 방법은 이벤트 처리기에서 Handles 키워드를 사용하는 것입니다. 이 기술은 처리기가 로드 시에 개체에 존재하고 개체 수명 동안 지속될 것으로 예상할 수 있는 경우에 적합합니다. XAML에 정의된 개체에서 Handles를 사용하려면 Name / x:Name을 제공해야 합니다. 이 이름은 Handles 구문의 Instance.Event 부분에 필요한 인스턴스 한정자가 됩니다. 이 경우 개체 수명 기반 이벤트 처리기를 사용하여 다른 이벤트 처리기 연결을 시작할 필요가 없으며 Handles 연결은 XAML 페이지를 컴파일할 때 생성됩니다.

Sub textBlock1_MouseEnter(ByVal sender As Object, ByVal e As MouseEventArgs) Handles textBlock1.MouseEnter
'....
End Sub
Sub textBlock1_MouseLeave(ByVal sender As Object, ByVal e As MouseEventArgs) Handles textBlock1.MouseLeave
'....
End Sub
참고참고:

Visual Studio 및 해당 XAML 디자인 화면에서는 보통 Handles 키워드 대신 인스턴스 처리 기술이 사용됩니다. XAML에서 이벤트 처리기 연결을 설정하는 작업은 Windows Phone 의 일반적인 디자이너/개발자 워크플로에 포함되며, Handles 키워드 기술은 XAML의 이벤트 처리기 연결 작업과 호환되지 않기 때문입니다.

Windows Phone 에서는 몇 가지 입력 이벤트에 대해 라우트된 이벤트 개념을 지원합니다. 이러한 이벤트는 기본 클래스에서 정의되며 사용자 상호 작용과 입력을 지원하는 대부분의 UI 요소에서 발생합니다. 다음은 입력 이벤트(라우트된 이벤트) 목록입니다.

라우트된 이벤트는 자식 개체에서 개체 트리의 다음 부모 개체 각각에 전달되는 이벤트입니다. 해당 개체 트리는 XAML의 루트가 되는 트리의 루트를 사용하여 XAML 구조의 UI로 그려집니다. 실제 개체 트리는 속성 요소 태그 등의 XAML 언어 기능을 포함하지 않으므로 XAML과 다소 다를 수 있습니다. 일반적으로 라우트된 이벤트는 이벤트를 발생시키는 XAML 개체 요소의 자식에서 해당 자식을 포함하는 부모 개체 요소에 대해 수행하는 "버블링"으로 간주할 수 있습니다. 이벤트 발생과 해당 이벤트 데이터는 루트 요소에 도달할 때까지 계속 진행되며 이벤트 경로를 따라 개체에 보고됩니다. DHTML과 같은 특정 웹 기술을 사용해 보았다면 "버블링" 개념에 익숙할 것입니다.

참고참고:

XAML은 비유적인 의미의 "터널링" 라우팅 전략을 지원합니다. 이 전략에서는 페이지의 루트인 / 개체 트리에게 라우트된 이벤트를 가장 먼저 처리할 수 있는 기회가 주어지며, 그런 다음 이벤트는 "터널"을 지나가듯 이벤트 소스를 향해서 개체 트리를 통과하게 됩니다. Windows Phone 은 라우트된 이벤트 "터널링"을 사용하지 않습니다. Windows Phone 의 이벤트는 "버블링" 라우팅 전략에 따라 라우트된 이벤트로 참조되며, 그렇지 않은 경우에는 라우트하지 않습니다. wphone과 XAML 간의 라우트된 이벤트 동작에는 API 수준의 다른 차이점도 있습니다.

RoutedEventArgs의 OriginalSource 속성

이벤트가 이벤트 경로의 위쪽으로 버블링하게 되면 sender는 이벤트를 발생시킨 개체와 더 이상 같은 개체가 아닙니다. 대신 sender는 호출된 처리기가 연결된 개체입니다. 대부분의 경우 sender는 관심 대상 개체가 아니며 키보드 키를 눌렀을 때 포커스를 가지는 개체 등에 대한 정보를 알아야 합니다. 이러한 경우 OriginalSource 속성의 값이 찾고 있는 개체입니다.

경로의 모든 지점에서 OriginalSource는 처리기 연결 위치가 아닌 이벤트가 발생한 원본 개체를 보고합니다. 이 기능은 앱에서 현재 키보드 포커스를 가지고 있으며 이벤트를 시작한 컨트롤에 관계없이 특정 키 조합을 "바로 가기 키" 또는 액셀러레이터로 사용하려는 경우에 유용합니다. 개체 트리의 측면에서 볼 때 포커스가 있는 개체는 목록 상자의 일부 항목 목록에서 중첩될 수 있으며 전체 UI에 있는 수많은 개체 중 하나일 수도 있습니다. 액셀러레이터를 감지하기 위해 앱의 모든 포커스 가능 개체에 처리기를 연결하는 것은 적절하지 않습니다. 그러나 키보드 이벤트는 라우트된 이벤트를 버블링하므로 결과적으로 경로의 루트 개체에 도달하게 됩니다. 따라서 루트 개체에서 단일 KeyDown 처리기를 연결한 다음 KeyDown 이벤트가 버블링을 통해 결과적으로 루트 개체에 도달하는 동작을 활용할 수 있습니다. 그런 다음 해당 키가 원하는 액셀러레이터 작업에 유효한 조합인지 또는 필요한 작업이 없는지 여부를 처리기에서 결정할 수 있습니다.

팁팁:

입력 버블링은 템플릿 컨트롤을 만들 때 특히 유용합니다. 템플릿을 포함하는 모든 컨트롤의 경우 해당 소비자가 새 템플릿을 적용할 수 있으므로 기본 템플릿 XAML에 선언된 모든 이벤트 처리가 제거될 수 있습니다. 이 경우에도 클래스 정의에서 OnApplyTemplate 재정의의 일부분으로 처리기를 연결하여 컨트롤 수준 이벤트 처리 기능을 제공하고 컨트롤 루트로 버블링되는 입력 이벤트를 catch할 수 있습니다.

Handled 속성

특정 라우트된 이벤트에 대한 여러 이벤트 데이터 클래스에는 Handled라는 속성이 있습니다. 자세한 내용은 MouseButtonEventArgs.Handled, KeyEventArgs.Handled, DragEventArgs.HandledValidationErrorEventArgs.Handled를 참조하세요. Handled는 설정 가능한 부울 속성입니다.

Handled 속성을 true로 설정하면 Windows Phone 의 이벤트 시스템에 영향을 줍니다. 이벤트 데이터에서 값을 true로 설정하면 대부분의 이벤트 처리기에 대해 라우팅이 중지됩니다. 이 경우 이벤트가 경로를 따라서 진행되지 않기 때문에 연결된 다른 처리기에 해당 특정 이벤트가 알려지지 않습니다. 이벤트 컨텍스트에서 "Handled" 동작의 의미와 앱의 응답 방법은 사용자가 결정하는 것입니다. 하지만 이벤트 처리기에서 Handled를 설정하는 경우에는 Windows Phone 이벤트 시스템의 동작을 유념해야 합니다.

라우트된 이벤트 중 일부는 이 방법으로 취소할 수 없습니다. GotFocus, LostFocusMouseMove는 항상 루트로의 모든 경로를 라우트하며, 해당 이벤트 데이터 클래스에는 이 동작에 영향을 줄 수 있는 Handled 속성이 없습니다. 따라서 이벤트를 처리하고 있지 않은지와 이벤트의 의미 및 UI 레이아웃에서 입력 이벤트가 처음 발생한 위치를 잘못 가정하고 있지 않은지를 확인하기 위해 이러한 이벤트의 OriginalSource 값을 검사하는 것이 좋습니다.

참고참고:

라우트된 이벤트에 대한 Handled 속성의 개념은 XAML에도 있습니다. XAML에서 Handled 속성은 모든 라우트된 이벤트 데이터 클래스에 있습니다. Windows Phone 에서는 관련 이벤트 경로를 취소하는 데 자체 Handled 속성을 갖는 특정 이벤트 데이터 클래스만 사용할 수 있습니다.

시각적 트리 외부의 라우트된 이벤트

Windows Phone 의 특정 개체는 개념상 주 표시의 오버레이와 같은 기본 표시 트리와의 관계에 참여하며, 모든 트리 요소를 표시 루트에 연결하는 일반적인 부모-자식 관계에 속하지 않습니다. 표시된 Popup이 이러한 경우에 해당됩니다. Popup에서 라우트된 이벤트를 처리하려는 경우 Popup 요소 자체가 아니라 Popup 내에 있는 특정 UI 요소에 처리기를 배치해야 하며, Popup 콘텐츠에 대해 이루어진 합성 내부의 라우팅을 사용해서는 안 됩니다. 그 이유는 라우트된 이벤트의 이벤트 라우팅이 주 표시 트리에서만 작용하기 때문입니다. Popup은 보조 UI 요소의 부모로 간주되지 않으며 Popup 기본 배경과 같은 요소를 입력 이벤트에 대한 캡처 영역으로 사용하려는 경우에도 라우트된 이벤트를 받지 않습니다.

기존의 특정 Windows Phone 컨트롤에서는 이 Handled 개념을 내부적으로 입력 이벤트에 사용하기도 합니다. 이를 사용하면 입력 이벤트가 발생하지 않는 사용자 코드의 모양을 제공할 수 있습니다. 예를 들어, Button 클래스에는 일반적인 입력 이벤트인 MouseLeftButtonDown을 의도적으로 처리하는 논리가 포함되어 있습니다. .NET Framework 라이브러리에서 특정 컨트롤에 대한 참조 항목에는 해당 클래스에서 구현한 이벤트 처리 동작이 기술되어 있는 경우가 많습니다. 서브클래스에서 OnEvent 메서드를 재정의하여 동작을 변경하거나 추가할 수 있는 경우도 있습니다. 예를 들어, TextBox.OnKeyDown을 재정의하여 키 입력에 대한 TextBox 파생 클래스의 반응 방법을 변경할 수 있습니다.

이미 처리된 라우트된 이벤트에 대한 처리기 등록

앞부분에서 Handledtrue로 설정하면 대부분의 처리기의 작동을 차단할 수 있다고 설명했습니다. AddHandler API는 경로 앞부분에 있는 다른 처리기의 Handledtrue로 설정했더라도 해당 경로에 대해 항상 호출되는 처리기를 연결할 수 있는 기술을 제공합니다. 이 기술은 사용하는 컨트롤에서 내부 합성의 이벤트를 처리할 경우 또는 컨트롤 관련 논리에 유용하지만 컨트롤 인스턴스 또는 라우트의 상위에서 이벤트에 응답하도록 할 수도 있습니다. 그러나 이 기술은 Handled의 용도와 상반될 수 있으며 올바른 컨트롤 사용법 또는 개체 모델을 위반할 수 있으므로 주의하여 사용해야 합니다.

사용 예제를 비롯한 자세한 내용은 AddHandler를 참조하세요.

Windows Phone 은 사용자가 시작한 이벤트를 처리하는 처리기 컨텍스트에서만 특정 작업을 수행할 수 있도록 합니다. 이러한 작업 목록은 다음과 같습니다.

Windows Phone 의 사용자가 시작한 이벤트에는 마우스 이벤트(예: MouseLeftButtonDown)와 키보드 이벤트(예: KeyDown)가 있습니다. 그러한 이벤트를 기반으로 하는 컨트롤 이벤트도 사용자 시작 이벤트로 간주됩니다.

사용자가 시작해야 하는 API 호출은 이벤트 처리기에서 최대한 빨리 호출해야 합니다. Windows Phone 의 사용자 시작 개념에서는 이벤트 발생 후 특정 기간 내에 호출이 수행되어야 하기 때문입니다. Windows Phone 에서 이 기간은 약 1초입니다.

경우에 따라 앱 수명 동안 이벤트 처리기를 제거해야 할 수도 있습니다. 이벤트 처리기를 제거하려면 CLR 언어 관련 구문을 사용합니다. C#에서는 -= 연산자를 사용하고, Visual Basic에서는 RemoveHandler 함수를 사용합니다. 두 경우 모두 이벤트 처리기 메서드의 이름을 참조합니다.

다음 코드에서는 대상 개체인 textBlock1에서 textBlocks_MouseEnter라는 이벤트 처리기를 제거하는 방법을 보여 줍니다.

void Cleanup()
{
    textBlock1.MouseEnter -= textBlocks_MouseEnter;
}

이벤트가 XAML 특성을 통해 추가된 경우에도 처리기를 제거할 수 있습니다. 처리기가 연결된 요소에 Name 값을 제공하면 이후 코드에 대한 개체 참조가 제공되므로 이 작업을 쉽게 수행할 수 있지만 필요한 경우 개체 트리를 검색하여 필요한 개체 참조를 찾을 수도 있습니다.

Windows Phone 에서는 일부 UI 요소가 명령을 지원합니다. 명령은 내부 구현에서 입력 관련 라우트된 이벤트를 사용하며, 단일 명령 처리기를 호출하여 관련 UI 입력(특정 마우스 동작, 특정 액셀러레이터 키)을 처리할 수 있도록 합니다. UI 요소에 대해 명령을 사용할 수 있는 경우에는 개별 입력 이벤트가 아닌 해당 명령 API를 사용하는 것이 좋습니다. 자세한 내용은 다음 중 하나를 참조하세요.

ButtonBase.Command

Hyperlink.Command

참고 항목

기타 리소스

표시:
© 2014 Microsoft