How Unbound Mode Works

When True DBList runs in unbound mode, it is not connected to a data control. Instead, your application must supply and maintain the data, while the list handles all user interaction and data display. For example, when a user covers the list with another window, then uncovers it later, the list is completely responsible for repainting the exposed area. Your application does not need to deal with any low-level display operations.

With the list in control of low-level display, you need to concentrate solely on maintaining your data. In DataMode 1 - Unbound, the list 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 list 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 list fires the UnboundReadDataEx event, which combines the functionality of UnboundReadData and UnboundGetRelativeBookmark. When the list 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 list fires UnboundReadDataEx again, this time to fetch the actual data in a block of ten rows. This process continues until the list has enough data to fill its display or your event handler informs the list that the end of the dataset has been reached. As the user scrolls through the list, the UnboundReadDataEx event is fired as needed to obtain bookmarks and data.

In this respect, programming True DBList 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 list 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 should be written so that it performs as little work as possible.

The list 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 list will ask for data, nor can you assume that data will be requested in any particular order. Furthermore, since the list 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 list 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 DBList translates user interactions into events that enable you to keep your data source synchronized. Conversely, if your application code manipulates the data source directly, the list will not know that the underlying data has changed, so you need to tell the list to update its display by using either the Refresh or ReBind method.

To summarize, True DBList'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.