WPF 이벤트에 속한 핸들러 확인
지난 글에서, 이벤트에 걸려 있는 이벤트 핸들러 목록을 나열하는 방법을 알아봤습니다.
이벤트에 속한 이벤트 핸들러 확인
; https://www.sysnet.pe.kr/2/0/618
사실, 프로그래밍하는 방법까지 알아보긴 했지만 어차피 VS.NET IDE 안에서 디버거의 "Watch" 윈도우로 확인이 가능하기 때문에 그다지 코딩을 할 이유는 없습니다.
혹시, 그 글을 읽어보고 나서 WPF의 DO(Dependency Object) 개체들에서 제공하는 이벤트를 대상으로 핸들러 목록을 나열해 보신 분이 계실런지 모르겠습니다. 낌새로 아시겠지만, WPF DO 개체들이 제공하는 일반적인 이벤트에 대해서는 그 방법이 통하지 않습니다. 왜냐하면, 그 이벤트들은 내부적으로 Event add/remove 메서드를 사용자 정의했기 때문입니다.
예를 들어, 이런 식이죠.
[그림 1: 일반 이벤트 "TestEvent"와 사용자 정의 이벤트 "HiddenEvent"]
보시는 것처럼, "MyTest" 개체에 정의된 이벤트가 2가지가 있는 데 "TestEvent"의 경우에는 디버거의 "Watch" 윈도우 창에 정상적으로 핸들러가 보이고 있는 반면, add/remove를 지정해서 정의한 "HiddenEvent"의 경우에는 디버거도 정상적으로 핸들러를 찾아내지 못하고 있습니다. 당연히 add/remove가 정의된 이벤트는 컴파일러에 의해서 자동으로 추가되는 동일한 이름으로 된 "System.MulticastDelegate" 타입의 필드도 가지고 있지 않습니다. 그야말로, 사용자가 임의로 특정 내부 필드에 이벤트 핸들러(delegate)를 보관할 수 있기 때문에 디버거가 임의로 그것을 발견할 수 없기 때문입니다.
물론, WPF의 RoutedEvent는 모두 이런 식으로 정의되어 있기 때문에 디버거에서 해당 이벤트에 걸려 있는 이벤트 목록을 확인할 수 없음은 물론이고 위의 글에서 설명한 방식의 reflection 코드로도 나열할 수 없습니다.
자,,, 그럼 어떻게 해야 할까요? 그냥 포기할까요? ^^
이를 해결하기 위해서는 add/remove에 정의된 코드를 직접 살펴보고 이벤트 핸들러를 정의한 내부 필드값을 열람하는 수밖에는 없습니다. 옛날 같으면, 이런 경우 어렵게 .NET Reflector를 사용해야 했지만, 닷넷 프레임워크 소스코드 디버깅 기능이 나온 이후로는 직접 VS.NET IDE 안에서 확인하는 것이 가능합니다. 이에 대해서는 다음의 글을 참고하세요.
VS.NET SP1 + .NET Framework 소스 코드 디버깅
; https://www.sysnet.pe.kr/2/0/623
그래서... 한번 찾아 들어가 보겠습니다. 환경을 갖춘 상태에서, 적당히 아무 이벤트 핸들러나 골라서 "+="가 들어간 코드에서 BP(Break Point)를 잡고 "F11 (Step Into)" 키를 눌러서 닷넷 코드 내부로 진입합니다. (참고로, 여기서 제가 예제로 한 이벤트 핸들러는 트리뷰의 "RequestBringIntoView" 이벤트입니다.)
처음, 진입을 하게 되면 아래와 같이 RequestBringIntoView 이벤트의 add/remove가 정의된 코드가 보입니다.
[그림 2: FrameworkElement.cs - RequestBringIntoView 이벤트 add/remove 코드]
정말 그렇죠? add/remove가 사용자 정의돼 있습니다. 이제 AddHandler 내부로 들어가게 되면,
[그림 3: UIElement.cs - AddHandler 코드]
보니까, EventHandlerStore라는 내부 Property의 AddRoutedEventHandler를 호출하고 있습니다. 딱 보니까, 그거 같죠. 실제로, "UIElement" 타입을 상속받은 타입의 인스턴스를 Reflection을 이용해서 확인해 보면, "EventHandlersStore"가 "Property"로 정의되어 있는 것을 확인할 수 있습니다.
왠지 ^^ 거의 다 온 것 같죠!
이렇게 해서 다시 AddRoutedEventHandler 메서드 안으로 진입해 보면,
[그림 4: EventHandlerStore.cs - AddRoutedEventHandler 코드]
오호... 다음과 같은 코드가 눈에 띕니다.
FrugalObjectList<RoutedEventHandlerInfo> handlers =
(FrugalObjectList<RoutedEventHandlerInfo>)this[routedEvent];
if (handlers == null)
{
_entries[routedEvent.GlobalIndex] = handlers = new FrugalObjectList<RoutedEventHandlerInfo>(1);
}
handlers.Add(routedEventHandlerInfo);
그럼... 끝났군요. _entries가 그 답이니. 이제 위의 자료를 바탕으로 Reflection 코드만 만들어주면 WPF의 특정 이벤트에 걸린 이벤트 핸들러를 나열하는 코드를 만들 수 있습니다. (Reflection 코드가 사실, 기술적이라기보다는 단순 반복적인 코드가 많기 때문에 생략합니다.)
자세한 코드는 첨부된 프로젝트를 참조하십시오.
여기서 끝내려고 했는데, 위의 reflection 코드를 작성하면서 알게 된 사실 하나! ^^ Microsoft의 리스트를 관리하는 내부 코드가 참 재미있네요. 위에서 보면, "Frugal"이라는 수식어가 괜히 붙은 것이 아니었습니다.
예를 들어, 내부적으로 이벤트 핸들러 목록을 보관하는 필드인 "_listStore" 타입이 이벤트 핸들러의 갯수가 증가할 때마다 바뀝니다. 예를 들어, 이벤트 핸들러가 3개 이하인 경우에는,
[그림 5: ThreeItemList 타입]
6개 이하인 경우에는,
[그림 6: SixItemList 타입]
7개 이상인 경우에 그제서야 아래와 같이 ArrayItemList로 관리하는 것을 알 수 있습니다.
[그림 7: ArrayItemList 타입]
사실, 단일 이벤트에 대해서 6개 이상의 핸들러가 걸릴 일은 많지 않기 때문에 첨부한 프로젝트의 코드에서는 ThreeItemList / SixItemList 타입을 기준으로 reflection 코드가 작성되어 있습니다. 물론, ArrayItemList로의 확장은 필요하시면 언제든지 코드를 추가하시면 되겠지요. ^^
휴... 새삼스럽게 한 번 더 느끼는 거지만, 물론 .NET Reflector로도 할 수 있는 일이라고는 해도 역시나 디버거 환경에서 하는 것이 훨씬 더 편하다는 것! ^^
[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]