Freigeben über

Winforms gui on top of Managed debugger sample.

  • Artikel

UPDATE: The source for this sample is now available here. Since this post is closed (it's from Nov 2004), please direct comments to this post.

The MDbg sample ships with some interesting extensions, including a simple winforms gui with some very basic features (gui.dll):

- opens source files in a MDI window.

- redirects console output to a window

- Primitive UI commands for stepping and async-break.

 

Here’s what the original UI looked like:

 

 

I don’t know much about winforms or writing user-interfaces, so I decided to learn more by trying expand the sample gui and put a richer winforms gui on top of the Mdbg sample.

 

I’ve added several features:

- modeless dialogs for the standard debugger windows: Callstack, Threadlist, module list, locals, quick watch.

- A glyph bar on the left with icons for the current statement and breakpoints.

- more UI elements for commands including Launch and Attach dialogs.

- Highlight the current statement.

 

Here are some screen shots of what I have now:

 

 

 

 

 

 

 

My primary goal here was to experiment with winforms. I am not trying to make a production debugger. The CLR team is also not focused on trying to build a debugger, we just focus on building the APIs that let everybody else build debuggers.

 

Everything I did was with the publicly available Mdbg sample, and the publicly available VS Beta 1 (C#). That means that anybody out there could have done the same thing I did (and probably a better job of it).

 

 

Here are some of the things I’ve learned from this experiment:

1) Winforms is awesome at making a 1995 User-interface! I can’t believe how easy it is! I did most of the UI in my spare time over a single weekend. Creating each of the new tool windows and hooking up the functionality only took about an hour per window.

2) I found some bugs in the Mdbg engine layer. I guess I shouldn’t be too surprised since I’m using the mdbg object model in a very different way.

3) I also found some limitations in the Mdbg engine layer. For example, currently the UI has no good way of knowing if a breakpoint was not added with F9 (eg, perhaps an extension command added the breakpoint).

4) In case there was any doubt, threads really are evil. (I already knew this since ICorDebug has lots of thread problems, but this is just another reminder). The only task here even remotely difficult was working out the threading issues between the UI thread and the shell’s worker thread, and that’s been painful.

5) I think it’s given me a better insight as to the pain our consumers have to go through when writing GUIs.

6) It's very easy to write very bad poor or expensive code. For example, the locals window I added goes and dumps a value into a tree view. The actual code to do that is small and appears simple, but it can easily generate huge amounts of work under the covers.

 

Where to go from here?

1) I’ll try to post the source to this blog.

2) We’ll probably roll this UI back into the MDbg sample, so its source will also be available in the next drop of the Mdbg sample.

3) I may use this as a springboard to play around with some other debugging ideas. For example, adding IL-debugging functionality so that you get intergrated source-IL debugging.

4) This may pave the way for some future blogging about how the UI here actually works (showing modeless dialogs + the glyph-bar, making the UI play well with extensions, thread threading problem, etc).

5) People interested in playing around with ICorDebug or using managed-debugging functionality in their current tools should be encouraged by how easy this was.

Comments

  • Anonymous
    November 14, 2004
    > For example, adding IL-debugging functionality
    > so that you get intergrated source-IL debugging.
    >
    That would be great! I can't wait to see this.
  • Anonymous
    November 14, 2004
    I am exited to look at the code, especially how you handled threading, I think its a hard issue for us who are just looking at the Sample, without the knowledge of the undercovers of the engine, And for people like me who don't know a ton about threads ;-)
  • Anonymous
    November 15, 2004
    The comment has been removed
  • Anonymous
    November 15, 2004
    The comment has been removed
  • Anonymous
    August 10, 2005

    The Mdbg (a managed debugging written in pure C#) sample, which includes full source, has now been...
  • Anonymous
    August 10, 2005

    The Mdbg (a managed debugging written in pure C#) sample, which includes full source, has now been...
  • Anonymous
    September 01, 2005
    Previously, I added IronPython scripting support to a real existing application, MDbg (a managed debugger...
  • Anonymous
    June 18, 2006
    PingBack from http://blogs.msdn.com/jmstall/archive/2005/11/08/mdbg_linkfest.aspx