Ive seen how to lazy load desktop but can you do the same on a webapp. The desktop example uses a seperate scroll bar which is not available in web. I thought of using the container control but unable to figure it out.
So… is it posible and any pointers how
Have you checked WebDataSource ?
I’ve been looking at it following your post but not sue I understand how to use it …yet
Will keep trying Ta
Just so you understand, the WebListBox always lazy loads. Even when you use AddRow, it creates a SQLite database in the background and loads the rows on demand
If you want to do that yourself, check out the examples. There’s at least one on the topic of a DataSource.
Ok got it reading my db … now just need to get it to write as addrow cant be used as ‘normal’
the example dose not show how.
Look for a method called RowData in that example.
The basic idea is that the listbox is going to “ask” for data as it needs it. The RowData method is called with a starting point, a number of rows and a piece telling you what order.
I’m a bit surprised by this - does the compiled app really create the database and the table to hold the rows and never once reuse it? Hmm, maybe that is super fast but still my impulse would be to just create records in that table holding the rows on the fly and reuse the db and the table as much as possible. Just curious.
First of all: I do not know.
But I know how you can check that:
create a large data base (use many Columns with large strings and many rows; far more than 1000 rows, so you will have a better idea on how fast the Web application can be. And if still fast with 1000 Rows, add 1000 more Rows… (or more)… ypu may add many users for the speed testings…
There certainly exists other ways to check for data base display speed.
BTW: I cannot test that.
It really does. The thought at the time was that we had so many web 1 users that would want to continue using AddRow without having to think about a datasource was going to be extraordinarily high. Couple that with the fact that one of the major design changes in web 2 was to lower the amount of traffic between the server and the client as much as possible and making all list boxes be on-demand made a lot of sense.
FWIW, it creates an in-memory database which means it’s very, very fast, but yes, if you have a lot of users, the overhead could become a problem. IMO, that’s the point at which you should be looking at doing your own datasource anyway.
One of the most common tech support calls I dealt with regarding the web 1 listbox went something like this:
“I have a weblistbox on my page and I’m only loading 100,000 rows. Why does my app slow to a crawl when a user goes to that page?”
We were trying to make things like that not happen.
FWIW, It also means that your listbox has sortable columns by default, just like the desktop.
I’m only loading 100,000 rows… that was me.