EDN Admin
Well-known member
Greets,
I just wanted to let others who may be interested know that I have uploaded a user sample on GotDotNet which Ive used personally as a debugging tool:
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=B2C906A6-B322-4D44-81CD-501209C68ACA http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=B2C906A6-B322-4D44-81CD-501209C68ACA http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=B2C906A6-B322-4D44-81CD-501209C68ACA
In a nutshell, it is used to dynamically generate an assembly that is loaded into the current AppDomain; said assembly contains a manager class and dynamically generated event handler classes at run-time (using Reflection and Reflection.Emit namespaces). The code will dynamically create event handlers for events that have any type of delegate function signature and, if used in a control container (after the controls have been initialized, such as InitializeComponents() in a Form) will hook the events for all controls as well.
Only one callback is made for all events (it is one interface), which passes back the event name and all of the parameters to the event delegate (properly boxed if necessary) in an object[] array. Very handy for looking at in a watch window.
There is an initial post with the sample code that notes a change to the testing application included in the solution; please read that for background. The default event handler code dumps the event information to the output window in the debugger.
Ive personally used this to debug complex UI projects with which I was not familiar in order to track down bugs in cases where several events had taken place. It saves a lot of time when you dont know where you need to look in the source code directly (i.e. you didnt write it) and if you dont know what events took place to lead to the problem. It is also a little more friendly than just stepping through the code from the beginning to determine what button was clicked and where it exists in the code.
I would certainly appreciate any feedback on this project, as I intend to write an article on its creation and would also like to incorporate it into other debugging/testing tools.
Regards,
Joe
View the full article
I just wanted to let others who may be interested know that I have uploaded a user sample on GotDotNet which Ive used personally as a debugging tool:
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=B2C906A6-B322-4D44-81CD-501209C68ACA http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=B2C906A6-B322-4D44-81CD-501209C68ACA http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=B2C906A6-B322-4D44-81CD-501209C68ACA
In a nutshell, it is used to dynamically generate an assembly that is loaded into the current AppDomain; said assembly contains a manager class and dynamically generated event handler classes at run-time (using Reflection and Reflection.Emit namespaces). The code will dynamically create event handlers for events that have any type of delegate function signature and, if used in a control container (after the controls have been initialized, such as InitializeComponents() in a Form) will hook the events for all controls as well.
Only one callback is made for all events (it is one interface), which passes back the event name and all of the parameters to the event delegate (properly boxed if necessary) in an object[] array. Very handy for looking at in a watch window.
There is an initial post with the sample code that notes a change to the testing application included in the solution; please read that for background. The default event handler code dumps the event information to the output window in the debugger.
Ive personally used this to debug complex UI projects with which I was not familiar in order to track down bugs in cases where several events had taken place. It saves a lot of time when you dont know where you need to look in the source code directly (i.e. you didnt write it) and if you dont know what events took place to lead to the problem. It is also a little more friendly than just stepping through the code from the beginning to determine what button was clicked and where it exists in the code.
I would certainly appreciate any feedback on this project, as I intend to write an article on its creation and would also like to incorporate it into other debugging/testing tools.
Regards,
Joe
View the full article