Paul Kimmel's Blog

The word “instrumenting” sounds like a three dollar word. One definition for instrumentation is adding a line of code that keeps track of what your code is doing (or reports on it) for every line of code that solves a problem. Another definition of instrumentation is code that performs tracing, debugging, performance measuring, and logging so an application can be managed by an external management tool. A three dollar word, but a pretty important concept. Knowing an application’s state at given points can be a useful element of debugging, so a mechanism for displaying state can be a an equally useful mechanism.

In the early 1990s, I was writing an application based on EGA graphics rendered using ASCII characters or a third party library to render the GUI. This was a time before multi-monitors were common place. Having read Peter Norton’s book Inside the IBM PC & PS/2 when Norton was writing books, it became clear to me that by writing directly to the CGA video buffer memory I could hook up a second monitor—EGA and a monochrome CGA monitor—and add debugging code and sent it as text directly to the second monitor. The EGA monitor had the ASCII rendered GUI and the CGA monitor had the text, tracking what was going on. All of this was accomplished by re-writing or modifying C++ functions like sprintf and printf and sending additional information to the various video memory addresses. (You can of course still experiment with video buffers directly by opening a cmd window, type debug, and entering hexadecimal values at B800:0 using the e command—see Figure 1. However, a too-long discourse on EGA buffer memory and obscure video layouts is probably like being 40 something and talking about high school baseball glory.)

 
Figure 1: You can still tweak the video buffer directly showing how far we have come and perhaps how much history we are dragging around with us.

What is relevant here is defining a mechanism for tracking what your application is doing is not a new concept, its nom de guerre, “instrumentation”, is relatively new though. In Visual Studio one of the demo solutions in the last few years was an ObjectDumper. ObjectDumper used Reflection to dump an object’s state. I have used a LINQ query to dump object state in more recent publications. Either of these approaches is valid for dumping and debugging an object’s state, but the visual result is usually formatted text sent to the console or debug output window. Perhaps a better refinement is to use DevExpress’ PropertyGridControl in conjunction with some of these other techniques. Simply assign an object to the PropertyGridControl.SelectedObject (or SelectedObjects) property and you have a built in GUI that is as easy to use and as intuitive as Visual Studio’s Property window and a whole lot less code than even using the LINQ dumper—which can be done with a select against an array of PropertyInfo objects.

How you incorporate the PropertyGridControl in your application is up to you, but here is a scenario. Suppose you have a a simple database browser/editor. You elect not to show key fields but for debugging purposes you may want to see them. You could combine an XtraGrid control for the user and a PropertyGridControl for deploy-time debugging scenarios.

This solution is so easy to implement, but I can tell you unabashedly that easy is what you want and what you get. When you work with a service provider—in this case Developer Express—to make your objectives and solutions easier to achieve you want the solution to be easy to assemble. Having spent at least 100 hours re-writing I/O functions for C++ to write to both EGA and CGA memory, it is a comparative breeze to achieve the same sort of “what is the state of my objects” behavior with the PropertyGridControl. To implement the sample solution where the XtraGrid shows some of the data to the user for editing, but not information like keys that can be changed, try these steps:

1. Place a SplitContainerControl on a Windows Form
2. Set SplitContainerControl.Horizontal to False
3. Drop a GridControl on the top half of the splitter
4. and a PropertyGridControl on the bottom half of the container
5. Using the XtraGrid (GridControl’s) smart tags menu add the Northwind database’s Orders table
6. On the XtraGrid click Run Designer and in the Main tab click the Columns button and set the OrderID and EmployeeID column’s Visible property to False—see Figure 2
7. Close the Property Editor for the XtraGrid
8. Click on the OrdersBindingSource component added by the database wizard
9. Switch the Properties window in Visual Studio to the Events view
10. Create a PositionChanged event for the OrdersBindingSource
11. In the PositionChanged event set the PropertyGridControl.SelectedObject to the current object in the BindingSource (see Listing 1)

Figure 2: Hide the OrderID and EmployeeID columns.

Listing 1: The code-behind for this solution is about easy as it gets, but the utility is pretty cool.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

namespace InstrumentingWithPropertyGrid
{
  public partial class Form1 : Form
  {
    public Form1()
    {
      InitializeComponent();
    }

    private void Form1_Load(object sender, EventArgs e)
    {
      // TODO: This line of code loads data into the 'northwindDataSet.Orders' table. You can move, or remove it, as needed.
      this.ordersTableAdapter.Fill(this.northwindDataSet.Orders);

    }

    private void ordersBindingSource_PositionChanged(object sender, EventArgs e)
    {
      propertyGridControl1.SelectedObject =
        ((BindingSource)sender).CurrencyManager.Current;
    }
  }
}

As the user scrolls the PositionChanged event is fired and the (orders) BindingSource.CurrencyManager.Current object—the current row—is assigned to the PropertyGridControl.SelectedObject property and the rest is magic. The current row’s data is displayed in the PropertyGridControl and an administrative user or debug user or independent tester could verify additional information like the hidden key fields. (Look at Figure 3 for the running solution.)

 
Figure 3: The basic running solution showing “administrative” fields as determined by our scenario.

As is if the PropertyGridControl were always visible then the hidden key fields could be updated by updating the values through the PropertyGridControl. In some cases this may be what you want; perhaps an administrative user is permitted to update the EmployeeID of record. If the scenario is that the “administrative” PropertyGridControl view is read-only then set the PropertyGridControl.OptionsBehavior.Editable property to false.

At this point it becomes a fairly trivial or routine problem to hide or show the PropertyGridControl, for example based on login credentials. Also, it really isn’t important what you point the SelectedObject at. If you want a BindingSource or custom objects in an IList you can use the same basic approach: figure out what event means the focused object has changed and update the PropertyGridControl.SelectedObject property, pointing it at that object.