Unbound Mode > How Unbound Mode Works |
When True DBGrid runs in unbound mode, it is not connected to a data control. Instead, your application must supply and maintain the data, while the grid handles all user interaction and data display. For example, when a user covers the grid with another window, then uncovers it later, the grid is completely responsible for repainting the exposed area. Your application does not need to deal with any low-level display operations.
With the grid in control of low-level display, you need to concentrate solely on maintaining your data. In DataMode 1 - Unbound, the grid fires the UnboundReadData event whenever it needs to fetch a row of data. It is up to your application to fill the RowBuffer object, passed as an event parameter, with the requested values on demand. Similarly, when the user repositions the scroll box, the grid may need to determine the bookmark of a row that has yet to be displayed. In this case, it fires the UnboundGetRelativeBookmark event, and your application needs to respond accordingly.
In DataMode 2 - Unbound Extended, the grid fires the UnboundReadDataEx event, which combines the functionality of UnboundReadData and UnboundGetRelativeBookmark. When the grid first loads, it fires the UnboundReadDataEx event to retrieve the bookmark (but not the data) for the first row. If your event handler provides a bookmark, the grid fires UnboundReadDataEx again, this time to fetch the actual data in a block of ten rows. This process continues until the grid has enough data to fill its display or your event handler informs the grid that the end of the dataset has been reached. As the user scrolls through the grid, the UnboundReadDataEx event is fired as needed to obtain bookmarks and data.
In this respect, programming True DBGrid in unbound mode is very similar to writing the event-handling code for a Visual Basic form. You cannot predict when the user will click a button or select an item from a combo box, so your application must be prepared to handle these events at all times. Similarly, you cannot predict when the grid will request a particular data row, or provide a new value to be written to the underlying data source. Therefore, the code that handles unbound mode events such as UnboundReadData and UnboundWriteData should be written so that it performs as little work as possible.
The grid generally limits its data requests to visible cells, although it may also cache other rows in anticipation of paging and scrolling operations. You cannot predict when the grid will ask for data, nor can you assume that data will be requested in any particular order. Furthermore, since the grid does not permanently store the data, data that has been requested once from your application may be requested again. Thus, you must provide and maintain your own data storage, as the grid will not do this for you.
Compare this event-driven approach with the storage mode used by the intrinsic ListBox control of Visual Basic, which is populated by repeated calls to its AddItem method at run time. Although this storage mode is convenient for small datasets, it is neither adequate nor efficient when there is a large volume of data or when the data source changes dynamically.
When running in unbound mode, True DBGrid translates user interactions into events that enable you to keep your data source synchronized. For example, when the user updates a cell, then attempts to move to another row, the grid fires the UnboundWriteData event. If the cell was modified as part of a pending AddNew operation, the grid fires the UnboundAddData event instead. If the user deletes an entire row through the grid's user interface, your application receives notification through the UnboundDeleteRow event.
Conversely, if your application code manipulates the data source directly, the grid will not know that the underlying data has changed, so you need to tell the grid to update its display by using either the Refresh or ReBind method.
To summarize, True DBGrid's unbound mode is a useful tool for communicating with third-party database APIs or avoiding the overhead associated with bound data controls. Although it is not as easy to implement as application mode, unbound mode can provide significant gains in performance, especially when there are many columns.