How Application Mode Works

When True DBGrid runs in application 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. The grid fires the ClassicRead event as needed to determine the value of individual cells. It is up to your application to provide the requested value 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 this respect, programming True DBGrid in application 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 the value of a particular cell, or provide a new value to be written to the underlying data source. Therefore, the code that handles application mode events such as ClassicRead and UnboundGetRelativeBookmark 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.

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 application 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 ClassicWrite event. If the cell was modified as part of a pending AddNew operation, the grid fires the ClassicAdd event instead. If the user deletes an entire row through the grid's user interface, your application receives notification through the ClassicDelete event.

Conversely, if your application code manipulates the data source directly, you need to tell the grid to update its display by using either the Refresh or ReBind method.

To summarize, True DBGrid's application mode is a useful tool for dealing with dynamic data. Since it has no inherent storage capability, the grid handles frequently changing data fluidly and easily. A common use of application mode is to provide an interface for viewing and updating the contents of a Visual Basic array. Application mode can also be used with proprietary database formats not supported by the Visual Basic Data control.