Is there a way in Web2 when you set the SelectedRowIndex to scroll to that row if it is not currently visible as one of the rows displayed? This used to just happen by default in Web1. It makes searching a large amount of data and finding the the matching row pointless if you can’t make that row visible in the Web UI.
(I’m hoping there is some magical JavaScript line that can go in the opening event to make this work again like in Web1)
Haven’t tried it yet but I hope this helps:
Edit: it looks like we will have that in Xojo2022r2, see #63466
Crossing fingers!
ScrollTo has been fixed in 2022r2, but SelectedRowIndex won’t scroll automatically. While you will be able to workaround it, calling ScrollTo.
It would be nice to have a Feature Request to bring that back from Web 1.0, so the framework can ensure it won’t scroll unless that row is outside of the boundaries.
Filed issue for Feature Request: WebListbox Auto ScrollTo SelectedRowIndex when SelectedRowIndex is out of displayed rows boundaries
https://tracker.xojo.com/xojoinc/xojo/-/issues/68778
So I just tried this and it sort of works. I seem to be encountering some sort of WebListbox bug where the Selected row index ceases to be highlighted or initially doesn’t highlight at all on a very large amount of data. I’m going to see if I can duplicate the behavior I am seeing in my application I am converting in a small sample project.
Thank you!
Yes but is better for us to explain what we want just for them to understand the request correctly.
Maybe in this case it was not difficult to know exactly what is needed but it is not always the case.
Just to clarify, if we find an issue ourselves and there is no feedback case yet, we will create it. But as @AlbertoD said, it’s just better.
I know it’s time consuming and I really appreciate the effort opening the feedback cases.
I believe I have figured out the issues I was having with highlighting and using the Scroll To JavaScript. I apparently wasn’t giving the Listbox enough time to fully load before attempting to do a Find which is why it wasn’t highlighting the row. That is my best guess at least. What I did discover though is that the Scroll To JavaScript appears to be calculating the scroll distance based on the default row height but if rows are taller than the default then the scroll isn’t enough to go to the top of the Listbox. Eventually with enough of these larger row heights the Listbox will no longer scroll to the selected row. I hope that @Ricardo_Cruz fix for R2 will take row height into account because this JavaScript fails for my purposes.
Just out of curiosity: Are you loading the list using your own code or are you using a datasource?
Hector I’m loading the WebListbox using my own code from an array that is populated by a MySQL query. There are multiple different WebListBoxStyleRenderer methods for text Styles/Colors and also for Text Wrap in 24 columns. There is something over 300 rows of various heights due to varying Text Wrap lengths in one of the columns from my test data which is a duplicate of production data from a few weeks ago. The app is a Web 2.0 rewrite of a functioning Web 1.0 app.
The reason I ask is because I was having an issue attempting to do some selection before a weblistbox with a datasource had compleated loading. What I did was add an event definition and raise the event when the RowData method has completed it’s thing. But this doesn’t apply to your case 
The underlying component (which is what ScrollTo will be calling) doesn’t support variable row height, and that’s something that sadly can’t be fixed for R2.
Depending on the kind of data you are displaying, maybe you can set a fixed row height that can work for all of them, or add a text-overflow: ellipsis style, so the text doesn’t wraps.
Could you post a screenshot to see the kind of dynamic content you’re trying to display?
@Ricardo_Cruz Elipsis overflow style would not really work for how this specific Listbox is used in the app. Text wrap is critical for how the WebListbox is used. I’ll PM you a couple of screenshots since company policy will not allow me to share them here publicly due to live customer data in the test data used in the screenshots.
It’s too bad that the WebListbox properties of Row Height and Column Width aren’t exposed so that we could Roll our own scrolling like…
Var sd As Integer
For idx As Integer = 0 To WebListbox.SelectedRowIndex
sd = sd + WebListbox.RowHeightAt(idx)
Next
WebListbox.VerticalScrollDistance = sd
similar thing using Column Widths for WebListbox.HorizontalScrollDistance = (some pixel integer)
This has been today’s Pie-In-The-Sky silliness.
An actual ScrollTo that worked with Variable row heights would be a better solution… Maybe for 2022R3