David Kline : Tips and Tricks

Presentation tip: Showing code

DavidKlineMS — Sat, 22 Dec 2007 21:41:50 GMT

Since MEDC 2005, I have been tapped to present sessions many times. Over the past three years, I have learned a lot and have grown as a presenter.

When I was first getting started, I attended my first speaker training course. Speaker training is a one-on-one class where you meet with your coach and he/she observes your presentation technique. I found the experience extremely valuable and make a point to re-take training every year.

One of the most valuable pieces of advice I was given is in how to best configure Visual Studio for code readability in a presentation hall. This advice applies to all audience and room sizes: from 16 person conference rooms to lecture halls that seat 400 or more.

Whenever I am preparing for a presentation (or am helping a new presenter prepare), I set Visual Studio's Font and Color settings as follows:

Font: Lucida Console
Font size: 16-24 (depending on room size and projector resolution)

Text color: Black
Background color: White

Highlighted text color: Black
Highlighted text background color: Yellow

It is amazing the difference these settings can make in code readability for your audience.

One note on code layout. When using large fonts (20) and small resolutions (1024x768), it is very important to format your code to avoid scrolling as much as possible. Placing each argument on its own line is perhaps the best advise I can give here. This way, the amount of side-to-side scrolling is minimized (there will still be some when enum / variable names are long). The example below shows my typical demo code formatting (it is very similar to what I use on this site).

public DemoMethod(String arg1, Int32 arg2, Boolean arg3) { // local variables try { String result = DemoHelperClass.AStaticMethodWithManyArgs( arg1, arg2, arg3, var1, var2, var3); // additional code } catch(Exception e) { // handler code } }

Ad you can see, the method the demo is calling has a pretty long name. For this reason, all of the arguments are on their own lines. Depending on the resolution of the screen, you may wish to further limit the horizontal scrolling by reformatting as below.

String result = DemoHelperClass.AStaticMethodWithManyArgs( arg1, arg2, arg3, var1, var2, var3);
It may look a bit odd when you are developing the demo, however it will be much easier to read for the audience. And it has a nice side-effect: it's also better for reviewing printed copies of the code.

Take care and Happy Holidays!
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

Quick Tip: Add files to Visual Studio projects the easy way

DavidKlineMS — Wed, 19 Dec 2007 01:58:32 GMT

Here's another in my series of "why didn't I know this feature was there".

While I was doing a technical review last week, I learned about a much easier way to add files to my Visual Studio projects.

In the solution explorer

Select a project
Click the "Show all files" button
Right-click on the desired file (will be shown with an empty document icon)
Click the "Include in project" menu item

This is so much easier than my usual technique (Add | Existing Item...).

Take care!
-- DK

[Edit: fix spelling]

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

Quick Tip: Debugging Smart Device Unit Tests

DavidKlineMS — Mon, 12 Nov 2007 21:54:08 GMT

While browsing MSDN today, I came upon a handy article that I wanted to share. Titled 'How to: Debug while Running a Smart Device Unit Test', it provides step by step instructions on debugging your test projects.

There is one additional step I would like to add to those listed in the article.

WARNING: Using Remote Registry Editor incorrectly can cause serious problems that may require you to hard reset your device. Microsoft cannot guarantee that problems resulting from the incorrect use of Remote Registry Editor can be solved. Use Remote Registry Editor at your own risk.

7. Disable support for attaching to managed processes
To do this, use the Visual Studio Remote Registry Editor:

a. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETCompactFramework
b. Set the value of Managed Debugger\AttachEnabled to 0
-or-
Delete the Managed Debugger node

Take care!
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.
The information contained within this post is in relation to beta software. Any and all details are subject to change.

Quick Tip: Getting the Collection of Checked ListView Items

DavidKlineMS — Mon, 18 Jun 2007 21:09:00 GMT

Have you ever created a ListView control and wanted to get the collection of items that the user has checked? While I was working on my demo for MEDC, that was one of the things that I needed to be able to do. If I were writing my application for the .NET Framework, I would get the collection of items via the ListView.CheckedItems property. When I looked up ListView in the MSDN documentation, I found that the CheckedItems property is not supported on the .NET Compact Framework. As a result, I was going to need to create the collection myself. Or was I?

Since the application that I was writing was a demonstration of the cool new features of .NET Compact Framework version 3.5, I decided to try my hand a using Language Integrated Query, specifically LINQ to Objects. The resulting code was small, worked well and was quite easy to read. Let's take a look at what I wrote.
public static List<ListViewItem> GetCheckedListViewItems(ListView lv) { List<ListViewItem> checkedItems = (from ListViewItem lvi in lv.Items where (true == lvi.Checked) select lvi).ToList(); return checkedItems; }
The method above is based on my Lunch Launcher demo application, as shown during the What's New in .NET Compact Framework version 3.5 session that I delivered at MEDC 2007 last month. How does it work? First, we specify that we are interested in the ListViewItem objects contained within the ListView.Items property.
from ListViewItem lvi in lv.Items
Next, we define the condition under which we are interested in the item, in our case when the item has been checked by the user.
where (true == lvi.Checked)
Then we select the item.
select lvi
Lastly, we call the ToList method to have the selected items returned to us as a List<ListViewItem>.

Pretty neat and much nicer to read than a foreach loop. If you have installed the beta of .NET Compact Framework version 3.5, give LINQ a try and see how it can make your applications easier to write.

Enjoy!
-- DK

[Edit: fix formatting]

Disclaimers:
This posting is provided "AS IS" with no warranties, and confers no rights.
The information contained within this post is in relation to beta software. Any and all details are subject to change.

Quick Tip: Using XPath to find nodes by attribute value

DavidKlineMS — Tue, 13 Mar 2007 21:11:00 GMT

There are some things that I can just remember: phone numbers, locker combinations, and the like. There are others that I have to lookup again and again and again. XPath query syntax is one of the latter items. Today, I'd like to talk a little about XPath queries.

The following XML contains a collection of "Friend" nodes. Each node has attributes for name and birth date. To keep this post to a reasonable length, I am going to limit the XML to 5 nodes.

<MyFriends> <Friend name="Sam" birthMonth="July" birthDay="16" birthYear="1974" /> <Friend name="Pam" birthMonth="April" birthDay="7" birthYear="1967" /> <Friend name="George" birthMonth="February" birthDay="2" birthYear="1981" /> <Friend name="John" birthMonth="April" birthDay="11" birthYear="1972" /> <Friend name="Martha" birthMonth="August" birthDay="3" birthYear="1974" /> </MyFriends>

After loading this XML into an XmlDocument, I can use XPath to query for the nodes of interest.

Since April is coming soon, I would like to get a list of my friends who has a birthday that month. To do so, I query for Friend nodes where the value of the birthMonth attribute is "April".

// load the xml file into an XmlDocument XmlDocument doc = new XmlDocument(); doc.Load("myfriends.xml"); XmlElement rootNode = doc.DocumentElement; // select the friends who have a birthday in April String query = "Friend[@birthMonth='April']"; XmlNodeList friends = rootNode.SelectNodes(query); foreach(XmlElement friend in friends) { // TODO: display a reminder to buy a birthday card }

When the above snippet is run, two friends are returned: Pam and John. The application can retrieve the desired information from the node and display an appropriate reminder.

Enjoy!
-- DK

Edit: Fix grammar

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

No ParameterizedThreadStart? No problem.

DavidKlineMS — Fri, 26 Jan 2007 23:19:00 GMT

The .NET Compact Framework is a subset of the .NET Framework. As such, there are features and functionality that exist in the .NET Framework that do not in the .NET Compact Framework. One such feature is ParameterizedThreadStart.

If your ThreadStart delegate needs data provided by the caller you can create a wrapper object for the method. To get the data to the delegate, you pass the it as arguments to your wrapper object's constructor. The delegate then accesses the data as member variables when performing its work.

//--------------------------------------------------------------------- 
//THIS CODE AND INFORMATION ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY 
//KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE 
//IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A 
//PARTICULAR PURPOSE. 
//---------------------------------------------------------------------
/// <summary>
/// Wrapper object for worker ThreadStart delegate
/// </summary>
class ThreadStartDelegateWrapper
{
    /// <summary>
    /// Number of worker iterations
    /// </summary>
    private Int32 m_Iterations;

    /// <summary>
    /// Constructor
    /// </summary>
    /// <param name="iterations>
    /// Number of worker iterations
    /// </param>
    public ThreadStartDelegateWrapper(Int32 iterations)
    {
        this.m_Iterations = iterations;
    }

    /// <summary>
    /// Worker thread delegate
    /// </summary>
    public void Worker()
    {
        for(Int32 i = 0; i < this.m_Iterations; i++)
        {
            // do some work
        }
    }
} // end of ThreadStartDelegateWrapper class

By creating an instance of the above class, you can pass your desired iterations to the Worker method.

// create the wrapper object, passing in the desired number of iterations
ThreadStartDelegateWrapper wrapper = new ThreadStartDelegateWrapper(15);

// create and start the thread
ThreadStart ts = new ThreadStart(wrapper.Worker);
Thread t = new Thread(ts);
t.Start();

For clarity, the above example was shown on multiple lines. I have often written the above on a single line.

new Thread(new ThreadStart(new ThreadStartDelegateWrapper(15).Worker)).Start();

Enjoy!
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

Quick Tip: Identifing the interfaces that an object implements

DavidKlineMS — Tue, 05 Dec 2006 22:31:00 GMT

Have you ever wondered what type an object is? How about what interfaces the object implements? Using the .NET Framework and .NET Compact Framework, this information is very easy to determine.

The first thing we need to know about an object is it's type. Every object, including Object, has a method called GetType(). For a given Object (obj), I get the Type (objType).

Type objType = obj.GetType();

GetType naturally returns a Type object. The Type object is, to me, one of the most useful objects in .NET. From the Type object, you can determine if the object is public, is a generic type, is abstract, and more. You can also get the name of the type.

String objTypeName = objType.ToString();

When I called the above lines in a simple test application, the value of objTypeName was "System.Collections.Generic.List`1[System.String]", which tells me that obj is a List<String>.

Once we have the type of our object, we can get the list of interfaces implemented by the object (List<String>).

Type[] objInterfaces = objType.GetInterfaces();

To continue my example, by iterating over objInterfaces I see that List<String> implements:

System.Collections.Generic.IList`1[System.String]
System.Collections.Generic.ICollection`1[System.String]
System.Collections.Generic.IEnumerable`1[System.String]
System.Collections.IList
System.Collections.ICollection
System.Collections.IEnumerable

Knowing the interfaces implemented by a type can be useful in a variety of applications; from diagnostic tools to applications supporting plugins and more.

Enjoy!
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

Quick Tip - Sharing code between multiple projects in Visual Studio 2005

DavidKlineMS — Thu, 30 Nov 2006 04:51:00 GMT

I have long been an advocate for putting common code into an assembly that is shared by applications needing the functionality. That said, there are times where the separate assembly approach is not appropriate. For those situations, today's tip may help make code sharing easier.

I have a project (called TestApp) that targets the .NET Compact Framework version 2. In the TestApp project, there is a file called Helper.cs which implements a class containing static methods that I use throughout the TestApp project.

While working on TestApp, I decide that a .NET Framework (for desktop PCs) version would be nice to have. Since I already have Helper.cs written, I would like to use the existing version. I had previously chosen to not use an assembly for these helpers, so I add the existing file to my new project.

I would prefer to not create a duplicate of this file as maintaining changes between the two copies can be time consuming and error prone. Fortunately, Visual Studio 2005 has a great feature to allow for file sharing between projects -- you can add an existing file as a link. Here's how:

In the project where you wish to add the file, right click the project name in the Solution Explorer
Select Add and then Existing Item...
In the Add Existing Item dialog, navigate to the desired file
Click the downward pointing arrow next to the Add button and select Add As Link.
Once added to a project, linked files are easy to identify by the small arrow in the lower-left corner of the file icon in the Solution Explorer.

My new project now has a reference to the original Helper.cs and any changes I make to it, from either project, are reflected in both projects.

Note: It is important to remember that if you are sharing a file between different versions of the .NET Framework, you need to verify that any changes made are compatible with all projects using the file.

Enjoy!
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

Quick Tip: Specifying a field's name when using the XmlSerializer

DavidKlineMS — Wed, 08 Nov 2006 23:33:00 GMT

Last month, I wrote about how to instruct the XmlSerializer to create an XML attribute for fields in an object. Today, I'd like to talk about how to specify the name used to represent a field in the resulting XML.

By default, when an object is serialized, fields are serialized into nodes with names that match the name of the field. When an instance of the example TestData object(below) is serialized

public class TestData
{
    public Int32 TestID;
    public String Description;
}

the TestID and Description fields become

<TestID>0</TestID>
<Description>Sample test description.</Description>

At times, it may be desirable to change the default naming behavior. To change the name, we decorate the TestID field with an XmlElement attribute.

[XmlElement(ElementName="ID")]
public Int32 TestID;

After serialization, the XML contains

<ID>0</ID>

This same technique also works with the XmlAttribute attribute.

[XmlAttribute(AttributeName="ID")]
public Int32 TestID;

Creates an attribute called ID (highlighted in purple) in the TestData node.

<TestData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" ID="0">

Enjoy!,
-- DK

Disclaimers:
This posting is provided "AS IS" with no warranties, and confers no rights.

'const' vs 'static readonly'

DavidKlineMS — Fri, 27 Oct 2006 23:40:00 GMT

I'm a big fan of reusing code whenever and wherever possible. A long time ago, I wrote an assembly that provided common methods and data to some applications I was writing. When I first wrote the assembly, I exposedthe common data as public fields decorated with the const keyword, as shown in the example below.

public class HelperData
{
    public const Int32 Iterations = 5;
}

When I used the field, in my application, I saw the expected results, and checked in my code.

The value of HelperData.Iterations is 5

Later, I needed to update my application (increase the number of iterations), so remembering that I had put the iteration count in my helper assembly, I changed the code and deployed the new dll. When I ran my application, the iteration count did not change, it was still using the old value (5). Scratching my head, I tried building and deploying my dll again with the exact same result.

When I looked at my application's IL, I found my problem.

ldstr "The value of HelperData.Iterations is "
ldc.i4.5

When my application was built, the literal value (5) of the HelperData.Iterations field was compiled into the executable (ldc.i4.5). My application used the original value because it was never actually referencing the field in the helper assembly. This made sense once I thought about it. Because I had defined my field as a constant, the compiler optimized away the assembly reference.

To fix the problem (I really did want the assembly reference), I changed my helper class to expose Iterations as a static readonly field.

public class HelperData
{
    public static readonly Int32 Iterations = 5;
}

After rebuilding the application referencing the updated assembly, I see my expected output.

The value of HelperData.Iterations is 5

When I change the value of Iterations (to 43), rebuild and update just the helper assembly, my application reflects the update.

The value of HelperData.Iterations is 43

Examining the IL shows why.

ldstr "The value of HelperData.Iterations is "
ldsfld int32 [Helper]Helper.HelperData::Iterations

Instead of compiling in the literal value, as was done above, we now see that the IL instructions are loading the field value from the helper assembly (ldsfld int32 [Helper]Helper.HelperData::Iterations).

Enjoy!
-- DK

Disclaimers:
This posting is provided "AS IS" with no warranties, and confers no rights.

Is it a field or a property?

DavidKlineMS — Fri, 13 Oct 2006 23:53:00 GMT

I very much value code reviews, as long time readers can attest. During these reviews, I have often found myself wondering whether a given line references a field or a property. When reading isolated portions of code, properties can be easily mistaken for fields.

Player player = new Player("Someone");
String name = player.Name;
player.Age = 22;

By looking at only the two lines above, is it possible to tell, conclusively, whether or not Name and Age are properties or fields on the Player object? I assert that it is not. Let's take a closer look at fields and properties.

A field is a variable exposed by the object.

public class Player
{
    public String Name; 
    public Int32 Age;
}

Properties are methods (a getter and/or a setter).

public class Player
{
    private String m_Name;
    public String Name
    {
       get{ return this.m_Name; }
    }

    private Int32 m_Age;
    public Int32 Age
    {
        get{ return this.m_Age; }

        set
        {
           if( 18 >= value )
           {
               throw new ArgumentException("Player must be at least 18 years old.");
           }
           this.m_Age = value; 
       }
    }
}

Each of the above examples would allow for code that looks like the original client snippet.

I typically use properties, in part, because they provide my client code with the same easy to use syntax for setting and retrieving values from a class that I get from fields with the added benefit of data validation when setting the value.

Take care,
-- DK

[Edit: fix error in example]
[Edit: add "m_" to private class members]

Disclaimers:
This posting is provided "AS IS" with no warranties, and confers no rights.

Separating Application Logic and Data Presentation layers

DavidKlineMS — Fri, 06 Oct 2006 00:57:00 GMT

I'm a big advocate of separating an application's logic from it's user interface. By keeping the logic separate from the data presentation layer (UI), it becomes easy to swap out either component with minimal impact on the other. In addition to ease of replacing components, keeping the user interface separate from the application logic avoids blocking the UI during expensive operations.

Today, I'm going to revisit the .NET Compact Framework WebCrawler sample from Visual Studio 2005 and show how it uses event handlers to allow the application logic (Crawler class) to communicate with the user interface. The source code for the WebCrawler sample can be downloaded from here.

Simple Status Notification - EventHandler
For simple notifications requiring no data, such as the CrawlFinishedEvent in the WebCrawler sample, an event handler is defined in the application logic class.

public event EventHandler CrawlFinishedEvent;

When the application logic wishes to inform clients that the event has occurred, it checks to see if there are any registered event handlers and, if so, sends the notification.

if (null != CrawlFinishedEvent)
{
    CrawlFinishedEvent(this, EventArgs.Empty);
}

The UI class (MainForm in the WebCrawler) registers for the event.

this.crawler.CrawlFinishedEvent += new EventHandler(HandleCrawlFinishedEvent);

The form implements a method to handle the event.

/// <summary>
/// Process CrawlFinished events
/// </summary>
private void HandleCrawlFinishedEvent(object sender, EventArgs e)
{
    // update the user interface as appropriate
}

Sending Data In The Notification - Creating a Custom EventHandler
If the notification requires some data data, such as the CurrentPageEvent in the WebCrawler sample, a custom event handler delegate will need to be defined.

public delegate void CurrentPageEventHandler(object sender, CurrentPageEventArgs e);
public event CurrentPageEventHandler CurrentPageEvent;

Notice the CurrentPageEventArgs argument -- this is where the custom data is placed. In the WebCrawler sample, the CurerntPageEventArgs is defined as

/// <summary>
/// Class providing the current page address to the CurrentPageEvent handler
/// </summary>
public class CurrentPageEventArgs : EventArgs
{
    private string pageAddressValue;
    /// <summary>
    /// The address of the current page(ex: http://www.microsoft.com)
    /// </summary>
    public string PageAddress
    {
        get
        {
            return this.pageAddressValue;
        }
    }

    /// <summary>
    /// Constructor
    /// </summary>
    /// <param name="page">
    /// The address of the current page
    /// </param>
    public CurrentPageEventArgs(string page)
    {
        this.pageAddressValue = page;
    }
}

As with the above simple status notification example, when the application logic wishes to inform clients that the event occurred, it checks registrations and sends the notification, passing the data in the event arguments.

if (CurrentPageEvent != null)
{
    CurrentPageEvent(this,  new CurrentPageEventArgs(str));
}

Registering for the custom event is similar to the above simple notification example.

this.crawler.CurrentPageEvent += new Crawler.CurrentPageEventHandler(HandleCurrentPageEvent);

The implementation of the event handler method needs to match the custom event handler delegate.

/// <summary>
/// Process CurrentPage events
/// </summary>
private void HandleCurrentPageEvent(object sender, CurrentPageEventArgs e)
{
    // update the user interface as appropriate
}

By building and running the WebCrawler sample under the Visual Studio 2005 debugger, you can watch the event notifications and how the sample handles updating user interface elements in a multi-threaded application.

Enjoy!
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

Quick Tip: Serializing an Object Field as an XML Attribute

DavidKlineMS — Tue, 03 Oct 2006 00:55:00 GMT

The addition of the XML Serializer is one of the reasons I really love version 2 of the .NET Compact Framework. I use the XML Serializer in very nearly every application I write; to save application state, data files, etc. By default, the XML Serializer will create a child node for every field in a type. For example, the following object

public class TestData
{
    public Int32 TestID;
    public String Description;
}

becomes

<TestData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Description>Sample test description.</Description>
  <TestID>0</TestID>
</TestData>

There are times that you may wish to serialize one or more fields as attributes on the object's node (ex: reduce the size of the XML). By decorating the TestID field with an XmlAttribute attribute, the TestID field

[XmlAttribute()]
public Int32 TestID;

now becomes an attribute (highlighted in purple) on the TestData node.

<TestData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" TestID="0">
  <Description>Sample test description.</Description>
</TestData>

Enjoy!
-- DK

Disclaimers:
This posting is provided "AS IS" with no warranties, and confers no rights.

Quick tip: Filtering input to a TextBox control

DavidKlineMS — Mon, 25 Sep 2006 23:57:00 GMT

Sometimes, it's the little things that take the longest to work out, so I thought I'd start a "Quick tips" series. Quick tips are intended to be short and solve a very specific issue.

I was talking with Mark Prentice today and we were looking at filtering a TextBox control so that it only accepted numeric characters. As it works out, this is a very easy thing to do with the .NET Compact Framework.

To filter input that is entered into a TextBox, we need to implement a KeyPress event handler. When you encounter a character you wish to exclude, set the value of KeyPressEventArgs.Handled to true. To determine which characters to handle, the Char type has several handy static methods that help determine what type of character was entered into a TextBox. Since Mark and I were interested in limiting the input to only numeric characters, I will use Char.IsDigit in my example.

private void textBox1_KeyPress(object sender, KeyPressEventArgs e)
{
    // only allow numeric characters
    //  all other KeyPress events are cancelled
    e.Handled = !Char.IsDigit(e.KeyCode);
}

Enjoy!
-- DK

[Edit: fix sentence]

Disclaimer(s): This posting is provided "AS IS" with no warranties, and confers no rights.

Command Line Debugging Revisited - Part 5: The X Command

DavidKlineMS — Wed, 13 Sep 2006 22:53:00 GMT

In the previous installment, I talked about attaching to running processes using MDbg. As part of that discussion, I used the X command. Today, I'd like to spend a little time on X. The X command is one of those great features of MDbg that I think is worth the price of admission by itself.

From MDbg's online help:

mdbg> ? x
abbrev: x
Usage: x [-c numSymbols] [module[!pattern]]
    Displays functions matching [pattern] for a module. If numSymbols is
    provided, the output is limited to the given number. If !regex is not
    provided, all functions are displayed. If module is not provided either,
    all loaded modules are displayed. Symbols (~#) may be used to set
    breakpoints using the "break" command.
Example: x mscorlib!*String*
See Also:
    break

I won't be going into all of the features of X here, rather I will demonstrate the ways that I most often use the command.

I'll use the Visual Studio 2005 WebCrawler sample application to show some of the cool features of X in action. Once connected to the debuggee (via Run or Attach), we are ready to go.

When debugging using command line tools, one of the most challenging tasks is getting the fully qualified names of functions correct when setting breakpoints. Namespaces can get long (as you will see in my examples) and the casing of names must be 100% accurate. X makes this much much easier, as we will see.

Getting the list of loaded modules
In it's simplest form, X will display the modules loaded in your application.

[p#:0, t#:0] mdbg> x
Please specify module.
Loaded Modules:
:0 mscorlib.dll#0 (no symbols loaded)
:1 webcrawler.exe#0
:2 System.Windows.Forms.dll#0 (no symbols loaded)
:3 System.dll#0 (no symbols loaded)
:4 System.Drawing.dll#0 (no symbols loaded)

If you are a user of the Modules window in the Visual Studio 2005 debugger, as I am, this usage will be very familiar and handy. The one useful thing missing from this display is the path from where the symbols were loaded, which the Visual Studio 2005 Modules window provides.

Setting a breakpoint on a function
My favorite way to use X is to help me set breakpoints on functions. As I mentioned earlier, entering fully qualified names exactly right can be challenging, especially when they get long. X really helps here by allowing us to search for functions by name fragments. In the example below, I am looking for anything (methods, classes, etc) with "Crawl" as part of the name.

[p#:0, t#:0] mdbg> x webcrawler.exe!*Crawl* ~0. Microsoft.Samples.NetCF.Crawler.add_CurrentPageEvent(value) ~1. Microsoft.Samples.NetCF.Crawler.remove_CurrentPageEvent(value) ~2. Microsoft.Samples.NetCF.Crawler.add_PageFoundEvent(value) ~3. Microsoft.Samples.NetCF.Crawler.remove_PageFoundEvent(value) ~4. Microsoft.Samples.NetCF.Crawler.add_CrawlFinishedEvent(value) ~5. Microsoft.Samples.NetCF.Crawler.remove_CrawlFinishedEvent(value) ~6. Microsoft.Samples.NetCF.Crawler..ctor(startingPage,noProxy) ~7. Microsoft.Samples.NetCF.Crawler.Start() ~8. Microsoft.Samples.NetCF.Crawler.Stop() ~9. Microsoft.Samples.NetCF.Crawler.PageIsHtml(pageAddress,status) ~10. Microsoft.Samples.NetCF.Crawler.GetPageData(pageUri,pageData) ~11. Microsoft.Samples.NetCF.Crawler.GetPageLinks(pageUri,pageBody,tag,attribute,links) ~12. Microsoft.Samples.NetCF.Crawler.Crawl() ~13. Microsoft.Samples.NetCF.Crawler.CurrentPageEventHandler..ctor(object,method) ~14. Microsoft.Samples.NetCF.Crawler.CurrentPageEventHandler.Invoke(sender,e) ~15. Microsoft.Samples.NetCF.Crawler.CurrentPageEventHandler.BeginInvoke(sender,e,callback,object) ~16. Microsoft.Samples.NetCF.Crawler.CurrentPageEventHandler.EndInvoke(result) ~17. Microsoft.Samples.NetCF.MainForm.HandleCrawlFinishedEvent(sender,e)

When we search by a part of the name, we get a numbered list of symbols that match our fragment. If the list contains our desired function, we can set a breakpoint very easily by specifying the index of the function within the list. The results above returned all methods from the Crawler class as well as the event handler for the CrawlFinishedEvent within the MainForm class. I am interested in debugging the event handler, so I'll set a breakpoint there.

[p#:0, t#:0] mdbg> b ~17 Breakpoint #1 bound (:1!Microsoft.Samples.NetCF.MainForm::HandleCrawlFinishedEvent(+0))

This is much more convenient than retyping the name (Microsoft.Samples.NetCF.MainForm.HandleCrawlFinishedEvent), or using the Mark - Copy - Paste feature of the Windows Command Prompt. It is important to be sure to use the tilde (~) when specifying the list index. Forgetting to do so will attempt to set a breakpoint by line number within the current source file as shown in the example below.

[p#:0, t#:0] mdbg> b 17 Breakpoint #2 bound (line 17 in MainForm.cs)

Enjoy!
-- DK

Disclaimer(s): This posting is provided "AS IS" with no warranties, and confers no rights.