We would like to use the web list box for commercial purposes, but in the past we deemed it unsuitable due to its numerous bugs and lack of features. Until a recent build, even retrieving the clicked-on record was a challenge. Although we are now considering using it, there are still several unresolved issues that account for over 10% of all confirmed web bugs. Has anyone successfully utilized the web list box for anything beyond a basic list?
I have used it fairly extensively in a “real world” project, the most extensive of which involves loading the listbox with about 80 rows x 150 columns of data, most of which include a WebListBoxStyleRenderer for each cell.
It’s slow, but functional. Here’s a zoomed-out image showing only part of the data:
that being said, the WebListbox has some UI/UX issues that bother me:
no easy way to sort data, other than alphabetically. If you want to sort numbers, you have to pad them with zeros, e.g. 001, 002, 003, etc. to avoid sorting 1, 11, 12, 13…
poor caching? Even after loading the entire 150x80 listbox, when I scroll, the listbox shows the grey striped “no data” cells for a few milliseconds, before refreshing to show the actual data. It seems to me that once the entire listbox has been loaded, scrolling should be instant. (Note: I am not using a WebDataSource — Xojo documentation in this test, just regular listbox data and WebListBoxStyleRenderer )
Interesting - that seems like a design choice that may now be out of date - modern browsers are FAST at rendering HTML/CSS/Javascript, and not caching data is giving a poor UI.
I would expect I’m not alone in thinking “Just load up the WebListbox with data and it should be performant”. Custom Datasources sounds like more of an advanced technique? (I’ve never used one, to be honest)
We gave up on the Weblistbox when we first started with Web 2.0. We switched to Graffitisuite’s listbox and it has worked great. I know it is not an option for some due to cost, so it would be good if Xojo gave the built-in listbox some love.
I haven’t used the new web engine at all other than to test out some basic projects enough to realize I am not ready to upgrade my apps yet.
Maybe this already exists, but it seems like exposing some of the parameters that determine how many rows to cache and when to retrieve more rows would be a simple way of letting individual apps tweak the performance for a particular use case. It would probably be good to be able to change the timing of the loading more data indicator as well.
I’ve tried weblistbox 2 years ago, it was buggy as hell.
so I made my own websdk table using bootstrap tables.
it took a few hours to have it running, and after I updated it with functions as I needed them.
I still need a caching mechanism, as I suppose it would be slow loading thousands or records
but for now I’ve always been able to reduce the amount of records to be displayed, so good for now.
so if you have money and are in a hurry, buy graffiti suite
if not, try the websdk with it, you will learn a lot, and you will always need some websdk control
as all xojo web control there is always something that doesn’t do as you want.
So the issue really depends on what you’re using it for. We had heard lots of complaints from users that they tried to load tens of thousands of rows and the browser would just hang while that data was downloading. That would be true even if you were using php to send data to the browser.
Is it a good design choice for someone trying to show five rows? No, probably not. In my projects I tend to use an htmlviewer for that and just render pure html.
WebListBox won’t receive too much updates in 2023r1, but please let me know if any of you encounter a showstopper with this control, to give it more priority and include a fix for 2023r2.
I went through the list and it seems there are a few that might be already solved by other fixes during 2022 releases. As soon as we ship 2023r1 I’ll review them properly, to reduce the noise.
