What are the different grid types provided by Objective Grid? Do you have any guidelines when I should use a browser grid, a regular grid or a grid with formulas?

Objective Grid mainly differentiates between two types of grids:

  1. Regular Grid - You fill the grid with data at startup, the user has the ability to edit cells and changes will be stored in the grid.

  2. 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 and you supply data on demand. Objective Grid calls GetStyleRowCol only for the currently visible cells before it draws the cells on the screen. If you want the user to be able to edit cells you need to overwrite StoreStyleRowCol and store the changes back into your custom data source. Objective Grid calls StoreStyleRowCol whenever a cell is changed.

  3. Formula Grid (not available in Objective Grid Lite) - You enable the formula engine at startup. You fill the grid with data at startup. Cells can have formulas that reference other cells. The user has the ability to edit cells and changes will be stored in the formula engine. If a cell is changed that is referenced by a formula, the depending cell will automatically be updated.

  4. Browser Grid (not available in Objective Grid Lite) - Browser Grid is somehow similar to Virtual Grid with the main difference that 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 go to the wanted record. Then you can read data from this current record and change them. 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 in 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 implementations of Browser Grid 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, DBTools from RogueWave 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?

Then you should use the Formula Grid. Check out the formula sample for using formulas. You have to fill the grid with data at startup.

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

There are more issues to consider:

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

    Then you should use the ODBC or ADO Browser Grid implementation. Check out the gxquery and adoquery samples for using this type of grid.

  • Is the external data source record based? I mean should changes in a cell 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?

    Then you should derive from Browser Grid. Take a look at the dbfbrowse sample. This sample demonstrates how to derive from CGXBrowserGrid and lets you browse dbase files.

  • 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.