Microsoft MVP성태의 닷넷 이야기
.NET Framework: 114. WPF 이벤트에 속한 핸들러 확인 [링크 복사], [링크+제목 복사]
조회: 12708
글쓴 사람
홈페이지
첨부 파일

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"]
reflection_on_wpf_event_1.PNG

보시는 것처럼, "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 코드]
reflection_on_wpf_event_2.PNG

정말 그렇죠? add/remove 가 사용자 정의되어 있습니다. 이제 AddHandler 내부로 들어가게 되면,

[그림 3: UIElement.cs - AddHandler 코드]
reflection_on_wpf_event_3.PNG

보니까, EventHandlerStore 라는 내부 Property 의 AddRoutedEventHandler 를 호출하고 있습니다. 딱 보니까, 그거 같죠. 실제로, "UIElement" 타입을 상속받은 타입의 인스턴스를 Reflection 을 이용해서 확인해 보면, "EventHandlersStore" 가 "Property" 로 정의되어 있는 것을 확인할 수 있습니다.

왠지 ^^ 거의 다 온 것 같죠!
이렇게 해서 다시 AddRoutedEventHandler 메서드 안으로 진입해 보면,

[그림 4: EventHandlerStore.cs - AddRoutedEventHandler 코드]
reflection_on_wpf_event_4.PNG

오호... 다음과 같은 코드가 눈에 띕니다.

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 타입]
reflection_on_wpf_event_7.PNG

6개 이하인 경우에는,

[그림 6: SixItemList 타입]
reflection_on_wpf_event_6.PNG

7개 이상인 경우에 그제서야 아래와 같이 ArrayItemList 로 관리하는 것을 알 수 있습니다.

[그림 7: ArrayItemList 타입]
reflection_on_wpf_event_5.PNG

사실, 단일 이벤트에 대해서 6개 이상의 핸들러가 걸릴 일은 많지 않기 때문에 첨부한 프로젝트의 코드에서는 ThreeItemList / SixItemList 타입을 기준으로 reflection 코드가 작성되어 있습니다. 물론, ArrayItemList 로의 확장은 필요하시면 언제든지 코드를 추가하시면 되겠지요. ^^

휴... 새삼스럽게 한번 더 느끼는 거지만, 물론 .NET Reflector 로도 할 수 있는 일이라고는 해도 역시나 디버거 환경에서 하는 것이 훨씬 더 편하다는 것! ^^



[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]





[최초 등록일: ]
[최종 수정일: 11/9/2019 ]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer@outlook.com

비밀번호

댓글 쓴 사람
 



2008-12-05 09시30분
[사이 ] 우와 완전 멋지네요. 내용도 좋지만 정책임님께서 차근 차근 문제 해결의 실마리를 찾아나가는 단계가 참으로 인상적입니다. 좋은 글 감사드립니다.
[손님]
2008-12-05 10시27분
문제 해결 단계를 생략하면, 저도 나중에 잊어버리기 때문에 ^^; 같이 기록을 해두는 것입니다. 그럼... 이걸로 "사이"님 과 "anyflow" 님의 요청 사항은 마무리 되었다는.
kevin25

[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12163정성태2/27/202047.NET Framework: 899. 익명 함수를 가리키는 delegate 필드에 대한 직렬화 문제
12162정성태2/28/202043디버깅 기술: 166. C#에서 만든 COM 객체를 C/C++로 P/Invoke Interop 시 메모리 누수(Memory Leak) 발생파일 다운로드2
12161정성태2/26/202010오류 유형: 597. manifest - The value "x64" of attribute "processorArchitecture" in element "assemblyIdentity" is invalid.
12160정성태2/26/202030개발 환경 구성: 469. Reg-free COM 개체 사용을 위한 manifest 파일 생성 도구 - COMRegFreeManifest
12159정성태2/26/202012오류 유형: 596. Visual Studio - The project needs to include ATL support
12158정성태2/26/202044디버깅 기술: 165. C# - Marshal.GetIUnknownForObject/GetIDispatchForObject 사용 시 메모리 누수(Memory Leak) 발생파일 다운로드1
12157정성태2/27/202058디버깅 기술: 164. C# - Marshal.GetNativeVariantForObject 사용 시 메모리 누수(Memory Leak) 발생 및 해결 방법파일 다운로드1
12156정성태2/25/202027오류 유형: 595. LINK : warning LNK4098: defaultlib 'nafxcw.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
12155정성태2/25/202028오류 유형: 594. Warning NU1701 - This package may not be fully compatible with your project
12154정성태2/25/202033오류 유형: 593. warning LNK4070: /OUT:... directive in .EXP differs from output filename
12153정성태2/23/202074.NET Framework: 898. Trampoline을 이용한 후킹의 한계파일 다운로드1
12152정성태2/23/202065.NET Framework: 897. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 세 번째 이야기(Trampoline 후킹)파일 다운로드1
12151정성태2/23/202070.NET Framework: 896. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 - 두 번째 이야기 (원본 함수 호출)파일 다운로드1
12150정성태2/23/202077.NET Framework: 895. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법파일 다운로드1
12149정성태2/20/202059.NET Framework: 894. eBEST C# XingAPI 래퍼 - 연속 조회 처리 방법
12148정성태2/23/2020127디버깅 기술: 163. x64 환경에서 구현하는 다양한 Trampoline 기법
12147정성태2/27/2020119디버깅 기술: 162. x86/x64의 기계어 코드 최대 길이
12146정성태2/18/202094.NET Framework: 893. eBEST C# XingAPI 래퍼 - 로그인 처리파일 다운로드1
12145정성태2/18/202078.NET Framework: 892. eBEST C# XingAPI 래퍼 - Sqlite 지원 추가파일 다운로드1
12144정성태2/23/2020145.NET Framework: 891. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 두 번째 이야기파일 다운로드1
12143정성태2/13/202092.NET Framework: 890. 상황별 GetFunctionPointer 반환값 정리 - x64파일 다운로드1
12142정성태2/27/2020127.NET Framework: 889. C# 코드로 접근하는 MethodDesc, MethodTable파일 다운로드1
12141정성태2/10/2020181.NET Framework: 888. C# - ASP.NET Core 웹 응용 프로그램의 출력 가로채기 [1]파일 다운로드1
12140정성태2/10/2020128.NET Framework: 887. C# - ASP.NET 웹 응용 프로그램의 출력 가로채기파일 다운로드1
12139정성태2/9/2020188.NET Framework: 886. C# - Console 응용 프로그램에서 UI 스레드 구현 방법
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...