Hello Sam, Are you planning on periodically updating the display as the user interacts with it? Have items pop in and pop out again as they're added or deleted? From your description, the data displayed in the GUI will go stale very quickly. I actually have similar logic in my app and I always append new things to the bottom so, it doesn't affect the current displayed page. Nothing annoys me more than to have items dynamically appearing and disappearing while I'm trying to interact with a GUI.
Monday, May 25, 2009, 4:32:56 PM, you wrote: SC> On Mon, May 25, 2009 at 4:05 PM, Teg <t...@djii.com> wrote: >> Hello Sam, >> >> Paging or scrolling is purely an abstraction you create with the GUI >> itself. If you load up 88 titles into memory and your screen display is >> 40 lines then you have 3 "pages" in memory and you simply replace a >> "page" each time they scroll or page up/down. You seem to be letting >> the back end dictate what the GUI does when in fact it's better to >> abstract the whole thing so, you can change the back end at will and >> not have to change the GUI. For 88 items, I doubt I'd even use a DB. >> Nothing beats a flat text file when you have a tiny data set. SC> I hear you that paging should be frontend logic, normally. The SC> problem is that I have a *DYNAMIC* record set that is constantly SC> changing: SC> The nature of the dataset is that it can grow very quickly early on SC> and at any point after that rows can be deleted through out. It is SC> this last fact that I need the help of the backend to figure out the SC> page. SC> Assume 5 items per page. If there are 88 items in the record set on SC> one call that returns 50 to 55, before the next call, items 3,12, 17, SC> 32, and 42 are all deleted from the record set, Item #55 is now going SC> to be #50. If the front end is simply giving the backend an unique SC> identifier of the item, not the PK, per the recommendations of the SC> ScrollingCursor page, how does the front end learn that it now is SC> getting #50 through #54 rather than #55 through #59? SC> Further, I am assuming this is a problem with paging on any dataset in SC> any database, thus a backend issue :) SC> Sam -- Best regards, Teg mailto:t...@djii.com _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
