(continued)
 |
| Despite an increased focus on project management, an alarming number of IT projects still fail. Common obstacles to successful projects include feature creep, lack of cooperation, and inefficient processes.
Download this Internet.com eBook to learn techniques for overcoming project jams and for improving the way you manage project information.
Topics Include:
Five Steps to Becoming a Strategic Project Manager
Overcoming Project Jams
Using ISO 9000 as a Project Management Tool
Building Reusable Project Templates
Reading GANTT Charts for Fun and Profit
|
 |
|
Register now for your free Internet.com membership to download your complimentary eBook. Membership will also give you access to: |
|
eBook Library
Newsletters |
Whitepapers
WinDrivers |
Webcasts |
|
Click here for a larger image.
Environment: VC6, Win32
Introduction
There are a lot of grid controls available. Why is this one different?
Quite simply, this grid is different because it can be implemented without the overhead of MFC, ATL, or COM. It doesn't even require C++ classes. It is implemented just like a standard listbox or edit control. It uses SendMessage() Win32 API function calls to control and notify messages via WM_COMMAND to communicate back to your application. Quite frankly, this is the control that Microsoft should have supplied as a standard control with your compiler.
One would get the impression that grid controls must be overwhelmingly complicated to produce because nearly all of the commercial ones cost anywhere from from $150 to over $400. To boot, nearly all of them require MFC, COM, ATL, or C++ classes to use.
I have seen many requests on Usenet for a grid control that didn't require this overhead, and was programmable similarly to the standard controls that are available to Win32 API programmers. After a lengthy search and failure to find one, and noting that practically every application I was writing could benefit from one, I took on the task of writing one.
One thing I found from my search is that every custom grid control looks different. I didn't need a grid with a hundred bells and whistles. I needed a grid that looked like a Windows standard control and, at least as importantly, I needed a grid that I could program like I was used to, with the standard Win32 API SendMessage() function calls. Also, I didn't want a grid control that required any additional support files, OCXs, or DLLs that I would have to distribute with my applications. Call me old-fashioned, but I like to have everything all wrapped up in the executable.
Project Goals
Before my grid project began, I realized that I needed to set some strict goals and stick to them. If I didn't, I'd never know when the control was finished. These goals for the control were:
- It had to be created in an application with the CreateWindow() API function.
- It had to respond 100% to SendMessage() API function calls.
- It would send the parent application notifications via WM_COMMAND messages like the standard controls.
- It had to have the look and feel of an Excel spreadsheet.
- It had to be editable by the user.
- It had to support sizeable/hideable columns.
- It had to be extremely customizable.
- It had to support protected cells (read-only).
- It had to make my life as a programmer easier.
That didn't seem to be an unreasonable set of goals. I went for it. Many months later, the BABYGRID project is complete.
I realized in development that knowing what features to leave out of the grid was just as important, if not more so, than knowing what to put in. Too many features would make the grid control too specific and not easily adaptable to any grid application.
I used Microsoft Excel as a model for the grid behavior, so anyone using BABYGRID should feel comfortable with its reaction to a user's mouse/keyboard input.
I didn't want to have to predefine anything about the grid other than the number of visible rows and columns. This meant that any cell in any column might get any type of data, whether numeric, alphanumeric, or boolean. Boolean values are displayed in BABYGRID as checked or unchecked check boxes. This meant that ALL data in the grid would need to be internally represented as NULL-terminated character strings. When data is entered into a cell, BABYGRID determines the type of data that it is, and then displays it accordingly.
I want you to know that this control is not untested. It is already in use in many applications in a manufacturing environment. This is not a declaration that I guarantee it is bug free, only that I believe it to be bug free and of commercial quality. I initially called it BABYGRID because I initially wanted only a grid for reporting purposes. BABYGRID has grown up since its inception. Don't be fooled by the name.
BABYGRID is intended to be compiled as a static library. This is the most logical way to use this control. Just compile "babygrid.cpp" along with its header file "babygrid.h" as a static library. Include the resulting "babygrid.lib" file in your projects, along with "babygrid.h", and you're set to go.
If you don't want to use it as a static library, just include "babygrid.cpp" and include "babygrid.h" in your source project; that will work, too.
There are over 40 BGM_ messages to control BABYGRID and 25 BGN_ notification messages that BABYGRID uses to communicate back to your application. This is WAY too many messages to document here, but I use a good many of them in the sample project downloadable with this article. I'm pretty sure you won't have any difficulty following the source code to see what's happening between it and the BABYGRID control.
Let me show you a code snippet to demonstrate how simple this control is to use:
#include "babygrid.h" //<----- You've got to do this.
HWND hgrid //<----- Define a window handle
// for your BABYGRID
_BGCELL cell; //<----- Use this structure to
// reference cells in the
// grid
// _BGCELL is defined in
// "babygrid.h"
char tbuffer[200]; //<----- A place to put data FROM
// a grid cell
(...WndProc...)
WM_CREATE:
RegisterGridClass(hInst); //<----- Call this one time
// to initialize the
// BABYGRID control.
// Now create a window using the
// registered "BABYGRID" class
hgrid=CreateWindowEx(WS_EX_CLIENTEDGE,"BABYGRID",
"Custom Grid Control",
WS_VISIBLE|WS_CHILD,0,0,500,500,hWnd,(HMENU)500,hInst,NULL);
// A default BABYGRID grid control
// is now visible on your
// application window.
//put "Hello" in row 5, column 3
SetCell(&cell,5,3); //<----- SetCell function is
// defined in "babygrid.h"
SendMessage(hgrid,BGM_SETCELLDATA,(UINT)&cell,(long)"Hello");
// Not that it would make sense
// to do it right now, but this
// is how you would get the
// contents of a cell in the grid
// Get the data (character string)
// in row 5, column 3
SetCell(&cell,5,3);
SendMessage(hgrid,BGM_SETCELLDATA,(UINT)&cell,(long)tbuffer);
// The contents of tbuffer is
// "Hello"
break;
Now, I ask you. Is that simple or what?!
Some Features of BABYGRID
- Dimensionable from 1 to 256 columns and from 0 to 32000 rows
- Optional owner-drawn cell contents
- Sizeable grid title (programmatically or auto-size)
- Sizeable column headers (programmatically or auto-size)
- Sizeable column widths (programmatically or auto-size or user preference)
- Optionally enable or disable user resizing of columns (keep hidden stuff hidden)
- Sizeable row heights (programmatically or auto-size—all data rows are same height)
- Protected cells (read-only)
- Customizable highlight row and color
- Customizable cursor color
- Customizable grid background color
- Customizable gridline color
- Customizable protected cell background color
- Enable or Disable auto numbering of rows
- User definable fonts for title, column headings, and grid body
- Enable or Disable user editing
- Enable or Disable extending last column to fill grid window
All I ask is that, if you find BABYGRID useful and you use it in an application, you e-mail me to let me know. I'd like to know my work has helped you in your work. I'd like to know what the application using BABYGRID does.
Downloads
Download demo project - 30 Kb
Download source - 18 Kb
All
IE 7
Firefox 2.0
