A Brief Look At SourceGrid 4.x

To implement an interface that somewhat resembles a check register for UvMoney, I’m going to need a list or grid control. I wrote a semi-usable grid control for .NET 1.1 a few years back, but I wanted to test drive a more mature grid for this project.

As you probably know, there are approximately 8,153 different grid controls available to the modern .NET developer. Writing a grid control, like writing a C++ string class, is one of those “rite of passage” projects that all programmers must go through at some point in their careers: Ie. everyone thinks they can build and sell a better grid control, and everyone tries. The result is a lot of grid controls in the marketplace, most of which are not very good.

For this round of testing, I decided to try out SourceGrid. It’s open source, and I remember reading about it some time ago on CodeProject. That, and the fact that it showed up first in a Google search for “open source .net grid control” gave me the confidence to choose it for this test.

The SourceGrid distribution is pretty austere — all you get is a big zip file with a lot of source code and a few binaries — but, really, what else do you need? The documentation is non-existent, but that’s not unusual for an open source project. Thankfully, there are plenty of easily-readable sample projects included. SourceGrid is what I think of as a “flat” grid — that is, you have to plug data into each one of the cells one by one. It has no data binding capability that I’m aware of.

I’ve been using SourceGrid for several weeks now in my prototype project. The API is pretty easy to learn, which is obviously a big plus. There are a few features here and there that don’t seem very intuitive to me, but I’ve seen worse, that’s for sure. Once you get the knack of the Model-View-Controller cell pattern, it’s not hard to modify the appearance of grid cells, and there is almost infinite flexibility thanks to the extensible design. (If you’re willing to write your own model, view, and controller classes, that is.) 

Unfortunately SourceGrid isn’t all roses, as we’ve all come to expect from open source projects. For a project that’s been around for many years, SourceGrid 4.x doesn’t feel very “mature” to me. In other words, there are bugs. To their credit, however, DevAge fixed several bugs quickly in versions 4.6 and 4.7. Presumably this is a trend that will continue.

As an example of the kind of bugs I’m talking about, I’m seeing some problems with layout of tool tip balloon windows. The balloons end up being different sizes even though it’s the same balloon with the same text in it each time.  And I noticed an oddity with scrolling using the arrow keys. I’m not sure if this was intentional or not, but if you hold down the down-arrow key, it jumps from page to page instead of smooth scrolling row by row, whereas it smooth scrolls like you would expect if you hold down the up-arrow key.

There isn’t any Designer support in SourceGrid, so don’t expect to do much dragging and dropping.  For me, that’s not an issue, but some people might not like it. 

Small bugs are tolerable, but this last one is a killer. One of the biggest problems I have with SourceGrid 4.x is the speed. It’s not very fast, to put it bluntly. In fact, undoubtedly due to the emphasis on extensibility, it’s pretty slow. This is apparently a known issue because “improved performance” is one of the planned features, so we can hope that a future version will be a lot snappier.

For the speed reason alone, I would think most people will want to either replace SourceGrid with a faster grid component, or dig deeper into the undocumented bowels of SourceGrid’s GridVirtual class. I for one would rather spend my time writing code than learning how to make someone else’s code work better, so I probably won’t use SourceGrid for this project.