I migrate my projects from WebKit 1 to 2 now. The application reads data from a MSSQL-Server and creates Lists several hundred rows. This works fine with Chrome / Safari and WebKit 1. I do two steps first I calculate the data within a thread. In the next step (with a timer) I fill the list. This was necessary, because the Listbox crashed with a large number of rows.
Now with WebKit 2 I don’t know if these two steps are still necessary. If not it would make my application much easier.
Does some has experiences with it? Thank you.
For best performance I suggest to use the WebDataSource Interface. There is an Example in the deployed Example Folder of Xojo. This is by far faster than even the good approach to use a WebTimer.
One reason for the gain of the speed is that this interface populates your listbox in chunks as well (using OFFSET and LIMIT), but it looks to me that there are further optimisations implemented in the interface. At least it is always faster than via a timer.
@Greg_O_Lone once said that the weblisbox is based on an internal SQLite db, perhaps the interface is populating that db “directly”. But this is pure speculation. @Greg I’m less interested in how you are doing things internally, but can you confirm that the interface approach is the fastest possible way of populating a weblistbox in web2.0? My tests are by far faster than any timer approach I tried.
When you populate a WebListBox through the AddRow or InsertRow method, the framework generates an in-memory FTS5 SQLite database behind the scenes and sets it to be the datasource for the listbox.
Using your own datasource offers you more control over searching and sorting options.
thank you for the idea. I checked the example and it might work. But other than in the example, I also mustI calculate cells from other values. And I must add information from other DB Server, too. As I see this makes it more complex. And I don’t want to rewrite alle reports again;-)
But as I understand the example, The rows for the list are fetched from the database and stored in the list. This is the same I do. But instead of “WebListBoxRowData” direct to the cell. In the next step the list is shown.
In one of my apps I try it without the t
From what Greg said. it should then be the same performance. I probably didn’t code it clean enough with my timer etc. Once I got into the logic of the interface I was very happy (and I’m populating from a few sources too). But yes I startet from scratch, if I had to port an existing solution, I would most likely not re-invent the wheel in your case either.
I tested today a little bit more. The lists, I create with WebKit 1 are up to thousand lines and 50 rows. So I tested with this nummer of cells. It seems that the creation is much faster when it doesn’t run in a thread. So I think it is a good idea to put only the gathering the data (Select) into a thread - this can be up to half an hour for some difficult reports. So I do it today.
The next problem was the horizontal scrolling. Because of the number of columns, I must scroll horizontal. The new WeblistBox seems to have no possibility to scroll in this direction. My first solution is to put the list into a container. The container can scroll horizontal. It is not the best solution, but it seems it works.
But when scrolling, it takes some time to display the values. It seems the server needs a long time to fetch the data from the internal database. With the version 1, it took also some time until the list was displayed. But when it was active, it scrolled very fast. I must look if my user accept this scenario,.
In the next days, I will test some more. The apps are working with the old Web Framework fine. so I can spent some more time to check all new features…
I tried it with the “WebListBoxRowData” in a test project. and which wonder, it works much more faster. And it also scrolls horizontal automatic. The only problem is that I have to change all reports in my applications.
I think this is the right way…
Thank you! I was already wondering if I’m really the only one making this experience.
Especially as @Greg told us (at least that’s my understanding) that WebListBoxRowData is not doing anything “special”. I played around yesterday with other approaches (though I have to admit that I was again very tired after a hard day), but none of my alternatives via timers and using OFFSET and LIMIT was able to reach the speed of the interface approach.