Objective Grid differentiates between several types of grids:

• Regular Grid — You fill the grid with data at startup. The user can edit cells. Changes will be stored in the grid.

• Virtual Grid — The data to be displayed in the grid are maintained in a self-written data structure or in an external file. The grid does not hold any cells in memory. You don't fill the grid at startup. Instead, you override the GetStyleRowCol() function to supply data on demand. Before it draws the cells on the screen, Objective Grid calls GetStyleRowCol() only for the currently visible cells. If you want the user to be able to edit cells, you need to override StoreStyleRowCol() and store the changes back into your custom data source. Objective Grid calls StoreStyleRowCol() whenever a cell is changed.

• Formula Grid —You enable the formula engine and fill the grid with data at startup. Cells can contain formulas that reference other cells. When the user edits cells, changes will be stored in the formula engine. If a cell that is referenced by a formula is changed, the depending cell is automatically updated.

• Browser Grid —A Browser Grid is somewhat similar to a Virtual Grid. The main difference is that the Browser Grid has been designed with certain characteristics of record-based data sources in mind. Take an ODBC recordset, for example. You cannot directly access data in any record. You have to loop through the records in order to access the desired record. Then you can read data from this current record and make changes. When the user starts editing a record, changes should only be written back to the recordset when the user navigates to a new record. Therefore, Objective Grid holds changes to the current record in a buffer and flushes this buffer only when the user moves to a new record. Browser Grid also lets the user easily append rows. The appearance of Browser Grid is very similar to MS Access query views.

  Objective Grid provides Browser Grid implementations for ODBC and ADO. Furthermore, you can easily add your own implementation of Browser Grid for any other record-based data source. For example, you could write your own Browser Grid implementation for SQL Server API, Sybase SQL Server, SourcePro DB from Rogue Wave, or CodeBase from Sequiter.

Here are some guidelines that should help you decide what kind of grid you want to use:

• Do you need formula support?

  If so, you should use the Formula Grid. Check out the Formula sample for implementation details.

• Does your grid have a large number of rows?

  If so, consider using a Virtual Grid.

• Do you maintain data in an external data source or custom data structure?

  If so, there are more issues to consider:

• Do you want to browse an ODBC or ADO recordset?

  If so, you should use the ODBC or ADO Browser Grid implementation. Check out the GXQuery and AdoQuery samples for details on using these types of grids.

• Is the external data source record based? (Should changes in a cell be immediately written back to the data source or should they be held in a buffer and flushed only when the user navigates to another record?)

  If the external data source is record based, then you should derive from CGXBrowserGrid.

• Do you want the grid to directly operate on your data?

  Use Virtual Grid. This has the advantage that you don't have to copy all the data at startup into the grid. The GridApp sample provides a sample for this type of grid. Check out the files browsevw.cpp and browsevw.h.

• Do you want to copy the data into your grid?

  Use Regular Grid. At startup you fill the grid with your data. The 1stGrid tutorial demonstrates this kind of grid.