The way I draw tables when there is a database involved and I want to scroll
through the data showing 10 or 11 records at a time is pretty much follow
what Neil Rhodes does in his book. Tables are hard to program and even
harder to explain how to program but I think Neil did a good job. The
secrtet is storing the index numbers of database records in the row ID
member of each row's structure.
Here are the general steps:
1. Figure out what database records needs to appear in the visible rows of
the table.
2. Store their dbRef index numbers in the rowID member of each row.
3. Have your drawing function read what the index numbers are in each row,
query that record and extract the data and draw it into the row's columns.
This only requires one db read per row instead of one read per column.
You also need to be keeping track of what actions the users does to move
through the table: keyup, keydown, dragging the elevator car etc. and using
that information to constantly recalculate what those db index numbers are
for the records you want to display before you call your drawing function.
Hope this helps.
> -----Original Message-----
> From: Gordon, Douglas [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, February 10, 2000 7:51 AM
> To: Palm Developer Forum
> Subject: Table drawing technique
>
> I have a table with four columns that uses custom draw procedures. Each
> row
> is associated with a database record, and various fields in a record are
> used to display information in that row. The issue is that my custom draw
> procedure is called for each column in a particular row, so currently it
> has
> to query the record, lock it, get the data for the specific column, and
> unlock it. That's four record accesses to display each row. This seems
> like
> excessive overhead that could be avoided. What I was thinking was that if
> I
> can assume (dangerous word!) that the column draw procedures are always
> called in ascending sequence, then the draw procedure for column 0 could
> save the display information for the other columns in a static structure,
> and I would only have to do a record access once per row instead of once
> per
> column per row.
>
> On the other hand, assumptions like these are what can get you into
> trouble.
> It may work like this today, but not be guaranteed to work that way in a
> future O/S release. Any ideas?
>
> Doug Gordon
>
> --
> For information on using the Palm Developer Forums, or to unsubscribe,
> please see http://www.palm.com/devzone/mailinglists.html
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
