Inside Technique : Client-side Data Access : Using the Tabular Data Control

Now that the user has selected the file, the next step is to open and read it. Since the game data file, despite it’s extension of .lvl, is essentially a text file, we decided to use the Tabular Data Control to manipulate the data stored in the file. Originally released with IE4, the TDC remains even today the simplest and most efficient means to access tabular data, and more importantly, it works seamlessly in both on-line as well as off-line mode.

Those of you who are unfamiliar with this control, or need to jog your memories a little, could take a dekko at the official Microsoft TDC overview page, or the more comprehensive TDC reference. SiteExperts.com has covered advanced usage of this control in the Data Binding section. Therefore, rather than covering this extemely useful control from scratch, we will look at how it was used in the Sokoban game.

The biggest advantage of the TDC is that it allows both sequential and random access of data. The standard sequential access loop looks like this:

TDC1.recordset.moveFirst() ;
while (!TDC1.recordset.eof) { 
      // Do your sequential processing here 
     TDC1.recordset.moveNext();
     }

To randomly access a record based on it’s position within the recordset, set the absolutePosition property of the recordset like this:

TDC1.recordset.absolutePosition=n

Now for the interesting part. The TDC is signed as safe for scripting because it cannot write data back to the data file. This does not mean that the TDC recordset is readonly, however. You can alter the value of individual fields like this:

TDC1.recordset.Fields(n).value='my data'

You can also insert and delete records by using the AddNew and Delete methods of the recordset. All changes made to the TDC’s recordset remain in a local cache, and therefore last as long as the page is displayed in the browser. The moment the user moves to another page - boom - all changes are lost.

Which is a big problem, because we wanted to include several features which would require that changes to the data be preserved across page accesses. In the next section we will look at the approach we used to preserve the changes made to the recordset, by writing these changes to the client disk. It is, unfortunately, not the most elegant solution, but it happens to be the only safe approach for IE4.

© 1997-2000 InsideDHTML.com, LLC. All rights reserved.