From feedback I have received it seems like Event Spy would be a useful tool to many.
I've now started a codeplex project at http://eventspy.codeplex.com/ - please join and get involved.
There also seems to be interest in ASP.NET support, which I will look into when I have some time
Monday, 10 January 2011
Sunday, 9 January 2011
Secret Project
Well I said I would reveal the secret project I've been working on. 99% of people won't be interested, but if you're a .NET developer you probably will be very interested. Especially if you do a lot of UI work.
I actually came up with this idea 6 years ago and wrote a fairly successful codeproject article on it, but then I abandoned it. I've since started a new job, and wished I had this tool, so built it.
Enter Event Spy -
Event spy is a development/debugging tool that subscribes to all events a .NET object can raise, it then records when events are raised on the object, and allows you to explore the value of any event arguments.
Event spy works on any event of any object, no matter what the event handler type is. It does this by using a combination of runtime code generation through CodeDOM and Reflection.Emit to compile handlers on the fly.
Usage is pretty simple, just add Event Spy as a reference, then call:
var spy = new EventSpy();
spy.Register(o);
where o is any object. Event spy will then start listening to all events the object exposes, and will pop up a window that shows these events in real time. You can even register more than 1 object at once with event spy.
The reasoning behind event spy is that when you're faced with using a new control or API library it's a massive pain to trawl through documentation to work out what events are available, when they are raised and what gets passed to the handler. With this you can simply register the control or object, and play about with it to work all this out.
Event spy works well with multithreaded applications - the main window runs in its own dedicated STA thread (which is handy, as it means you can call from an MTA thread if you wish). The event handlers that event spy generates at runtime run on whatever thread called spy.Register. One issue is that in the parameter explorer at the bottom you may navigate through to some UIElement that isn't on event spys UI thread. I've handled this situation by ensuring that whenever a UIElement is encountered event spy will do the work it needs to on that UIElements associated dispatcher.
A build and the source (VS 2010 project) are below, please give it a whirl and give any feedback.
Roadmap wise the next big feature will be deep cloning of handler parameters using Reflection.Emit.Say you have subscribed to TextChanged of a System.Windows.Control.TextBox, and change type 'hi' in the text box. 2 events will be raised for this - one when you type h, another when you type i. At the minute event spy doesn't do any deep copying of handler arguments, so the sender argument of both events will each point to the TextBox object as it currently stands (with text 'hi') as opposed to a freezed snapshot of the textbox state at the point in time the event occured. This feature will reduce performance a lot, but will be a handy thing to have. That should hopefully be done in the next few weeks. Deep cloning of arbitrary objects (i.e. that may not implement IClonable) should be a pretty interesting problem, so I will post about that when I get around to it.
Build - http://www.box.net/shared/3eds1cpg96
Source - http://www.box.net/shared/o8vlo1zhqs
I actually came up with this idea 6 years ago and wrote a fairly successful codeproject article on it, but then I abandoned it. I've since started a new job, and wished I had this tool, so built it.
Enter Event Spy -
Event spy works on any event of any object, no matter what the event handler type is. It does this by using a combination of runtime code generation through CodeDOM and Reflection.Emit to compile handlers on the fly.
Usage is pretty simple, just add Event Spy as a reference, then call:
var spy = new EventSpy();
spy.Register(o);
where o is any object. Event spy will then start listening to all events the object exposes, and will pop up a window that shows these events in real time. You can even register more than 1 object at once with event spy.
The reasoning behind event spy is that when you're faced with using a new control or API library it's a massive pain to trawl through documentation to work out what events are available, when they are raised and what gets passed to the handler. With this you can simply register the control or object, and play about with it to work all this out.
Event spy works well with multithreaded applications - the main window runs in its own dedicated STA thread (which is handy, as it means you can call from an MTA thread if you wish). The event handlers that event spy generates at runtime run on whatever thread called spy.Register. One issue is that in the parameter explorer at the bottom you may navigate through to some UIElement that isn't on event spys UI thread. I've handled this situation by ensuring that whenever a UIElement is encountered event spy will do the work it needs to on that UIElements associated dispatcher.
A build and the source (VS 2010 project) are below, please give it a whirl and give any feedback.
Roadmap wise the next big feature will be deep cloning of handler parameters using Reflection.Emit.Say you have subscribed to TextChanged of a System.Windows.Control.TextBox, and change type 'hi' in the text box. 2 events will be raised for this - one when you type h, another when you type i. At the minute event spy doesn't do any deep copying of handler arguments, so the sender argument of both events will each point to the TextBox object as it currently stands (with text 'hi') as opposed to a freezed snapshot of the textbox state at the point in time the event occured. This feature will reduce performance a lot, but will be a handy thing to have. That should hopefully be done in the next few weeks. Deep cloning of arbitrary objects (i.e. that may not implement IClonable) should be a pretty interesting problem, so I will post about that when I get around to it.
Build - http://www.box.net/shared/3eds1cpg96
Source - http://www.box.net/shared/o8vlo1zhqs
Saturday, 8 January 2011
Welcome!
Nothing much here at the minute. Working on a pretty cool personal project at the minute though, which I will be open sourcing and posting about shortly.
Subscribe to:
Posts (Atom)