I’ve recently been replacing grid controls within the GUI of the simulation system we’ve been writing. The current task is to retire older grids for Syncfusion’s GridDataBoundGrid. The key reason for it is that we can bind a DataTable to the grid as the data source, and sidestep having to manually write reams of binding code by hand through to the DataTable. Below are notes that I think I’d like to have access to once I’ve forgotten what I did to get it all working.
The DataTable isn’t tightly-coupled to an underlying database table (we use it more for in-memory LINQ queries), so we’re binding the DataTable to the its GridDataBoundGrid dynamically (not via Visual Studio’s designer). Doing this, I soon learned that getting at the columns of the grid proved challenging. I needed to use the grid’s InternalColumns, not its GridBoundColumns. The key insight I missed when pouring through their usage manual was the following quote from Syncfusion support staff:
If you have not explicitly added columns to the GridBoundColumns collection (either through the designer or through code), then the GridBoundColumns (and also grid.GridBoundColumns) will be empty even after setting the grid.DataSource property. In this case, binder.InternalColumns will automatically be populated with the columns from the DataSource at the time the grid.DataSource property is set.
With that behind me, I got by mostly with FAQ entries on typical things people want to do with the grid. I ran into another issue where I’d occasionally have to iterate through rows and/or columns to pull off certain pre-rendering hyjinks. Unhelpfully, the maximum row index number is given via the call grid.GridCellsRange.Bottom. The maximun column index number is given via the call grid.GridCellsRange.Right.
I’d inherited a new sub-class off GridDataBoundGrid to keep grid behaviour reusable across screens. The extra (under-the-hood) properties I’d added began causing me grief once I dropped the grid into a form via the VS designer. The designer would attempt to automatically generate supporting code for the properties, which failed with a dialog stating “Code generation for property ‘SomeProperty’ failed”. After some digging, I discovered that I could influence the designer on what it should do with my non-GUI properties via the DesignerSerializationVisibility attribute. Though I’d set the attribute correctly, the change wasn’t taking in the GUI. I eventually realised that the toolbox was looking at the assembly containing the my new grid control. I’d need to rebuild that assembly explicitly to allow the toolbox to pick up a “latest” DLL containing the grid control.
Finally, the most challenging screen I’ve cut across involved 7 separate tabs, each using a grid that showed a “slice” of a 7000-odd row DataTable. The fist attempt at having a separate grid per tab proved disastrous in terms of GUI initialisation speed, stretching into the minutes. I rewrote it using a sleight-of-hand trick so that there was only one grid. Tab control event-handlers then “yank” the grid to the newly selected tab, and supply a filter over the DataTable that mapped to the given tab. Table filtering was achieved using the RowFilter property of the DataTable’s DefaultView. Because I’m filtering on the actual DataTable, this trick only works if there is only a single grid visible on the screen that has the given DataTable bound as its data source.