Scripting Data Grid creation

[Mats Åström]

This is about the DG strategy I choosed.

The task: a data centric application with lots of dB tables (+50) that needed to be presented, some of the tables needed to be cell editable in an ”Excel fashion” (double-click-edit-return), the user be able to specify visible/hidden columns, specify column witdths all to be saved between sessions… and more. 

I had no desire to code a GUI for each table so I dug into the heart of the Data Grid. My starting point was how the .net TableAdapter and DataGridView works. I had never (and have not yet) coded C# .net but the solution I was to upgrade/replace was built in .net and I was handed a Visual Studio project and its (to me) somewhat incompahencible code.

So I went for this:

A generic LC stack method that copy’s the DG template and creates a DG on the fly. The method is passed a number of parameters telling it:
- which dB to connect to
- which table to read from
- the DG size & position 
- an (optional) SQL SELECT statement
- if a menu should accompany the DG
- whether or not update/insert is allowed (in which case the appropriate menu items are shown)
… and more
The method reads the dB table’s column characteristics from the dB schema and sets the DG columns headers (via a column-name-to-header text mapping function) and the DG column alignment sdepending on column data types. It also sets the DG text properties and populates the DG.

All DG:s are thus created programmatically and then deleted when they are no longer visible in the GUI (accomplished by keeping track of the visible DG(s)). Performance is reasonable - a DG with 3-4000 lines takes 3-4 secs. I am not so sure if this approach would be ok on very large tables.

All DG-related scripts, all DG editing and ”db-manipulation-related” code, all DG menus & menu scripts are also created on the fly by extensive use of behaviors.

Even though this might not be the most beautiful code I ever wrote (some of the requirements came in late - at least that is what I will plead in court) the whole ”DG affair” came out manageble through this approach.

It all took a great deal of trial & error because, although the DG documentation is correct, everything was not all that easy to figure out. 
But all in all it was well worth the effort. 
I admit that it came out a bit complex, but it is reusable, stable and still works like a charm.

/Mats