삽질의 현장/- .NET

#114_닷넷(.NET)_ WPF_ 라우팅된 이벤트 (Routed Event)

shovelman 2015. 12. 6. 16:25


안녕하세요 삽잡이입니다.

이번 시간에는 라우팅 된 이벤트에 대해서 알아보려고합니다.




버튼이라는 콘트롤에 있는 모든 콘텐츠들을 

각각의 색상으로 칠해봤습니다.


여기서 버튼의 콘텐츠라고 하면,

버튼 내에 모든 것들을 말할 수 있지요.


빨간색 배경 안에 있는 것들이 모두 버튼의 콘텐츠 입니다.


코드가 아닌, 버튼이라는 UI만 보더라도,

Grid 내부에 Canvas, Button, Ellipse, TextBlock등이 있는 것을 알 수 있습니다.


각각의 Element들을 색상으로 구분지어봤고,

중요한 것은 어떤 Element던지 버튼이 클릭되면, 

이벤트가 발생할 수 있다는 사실입니다.


Canvas가 버튼의 콘텐츠이기에 버튼이 클릭된것 처럼 보이고,

Ellipse를 클릭해도, TextBlock을 클릭해도 

모두 버튼이 클릭된다는 사실이 중요한 것입니다.


사실, 버튼의 콘텐츠들은 무한대로 확장될 수 있는것인데,

세세하게 하나하나 클릭할 때마다

각각의 핸들러들을 등록하게 된다면... 

머리 뽑힙니다... 허허...


Button이 눌렸다는 메시지를 직접 받을 수 없는 경우,

모든 핸들러가 Button의 핸들러로 클릭 됬다는 메시지로 알려야하는데...

코드가 복잡해지지 않겠냐 이겁니다.


그래서, 기존 이벤트 장치로는 WPF에 있는

이와 같은 문제점을 처리할 수 없기에 새로 만들었습니다.

즉, 이벤트를 좀 새롭게(?) 만들어 제공한다 이겁니다.

이를 RoutedEvent라고 부릅니다.


부모 트리가 하나 있다면,

이 부모로부터 자식들이 물고 물리는 모습을 볼 수 있지요.



이때 부모를 클릭하면,

부모트리를 검색했다가...

즉, 쪽 오르락 내리락 해서 계속해서 메시지들을 전달해준다 이겁니다.


이렇게 오르락 내리락 메시지를 전달하다 보니

내려갈 때에는 통과한다고 터널링 이벤트라고 부르고,

올라갈 때에는 버블링 이벤트라고 부르게 됬습니다.


우리가 눌리는데 관심이 있는 녀석에게 핸들러를 등록했다고 합시다.

이때 V자로 순찰을 하며 이벤트를 발생시키더라도,

결국 등록된 녀석만이 이벤트 발생에 대한 처리를 할 수 있습니다.


이러한 이유는 바로, 콘텐츠 모델로 이루어져있기 때문에 가능합니다.


그런데, 순차적으로 이벤트를 오르락 내리락 하며 전달하다가,

가끔은 이벤트를 중단할 필요성이 있을 때가 있습니다.


이때에는 Handled라는 속성을 true로 설정하여

더이상 이벤트가 라우팅되지 않도록 할 수 있습니다.



라우팅된 이벤트에 핸들러에는 중요한 인수들이 있습니다.

즉, 두가지의 Sender가 있다고 생각하시면 되는데요...


닷넷 이벤트에서 object는 이벤트를 발생시킨 객체였습니다.

하지만, WPF에서는 아니지요.

또한, RoutedEventArgs 형식은 이전에 부가정보였지만,

WPF에서도 역시 아닙니다...


WPF의 라우팅된 이벤트에서는

Sender는 말 그대로 이벤트를 등록한 객체,

RoutedEventArgs에 있는 Source 속성의 객체는 

실제 발생시킨 객체를 의미합니다.


생소하긴 하군요....

기존에 닷넷에서 배웠던 이벤트가 아니기 때문입니다.


아무튼... 닷넷의 이벤트 규칙을 따랐을 뿐,

WPF에서는 Sender가 이벤트 등록 객체이고,

e.Source가 진짜 이벤트를 발생시킨 객체를 의히맙니다.



다음시간에 뵙겠습니다.

이상 삽잡이였습니다!