WebListbox Pressed Event Row Param is -1 when a WebDataSource is Used

Feel like I’m missing something obvious here…

When I populate a WebListBox using a WebDataSource the pressed event is always returning a row value of -1 (column is correct)

Same for the DoublePressed event.

My suspicion is there’s an error in my class (implementer of WebDataSource), but… I’m not sure how a WebListBox with its DataSource property set determines the row value when a row is clicked?

To be clear, what I’m seeing is this:

(Populated list)

but… the row parameter of the ‘Pressed’ event for the WebListbox is always negative 1 (-1), no matter which row I click.

This only happens if the WebListbox uses a WebDataSource.

If I load the list manually (addrow) then the row parameter of the ‘Pressed’ event has the expected value. (the row which was clicked)

Additional details:

  • Xojo 2024r1.1
  • MacOS Sonoma 14.5 (23F79) (Intel)
  • App is running in the debugger

I don’t know if this will help or not, but you might want to grab the latest build from the Testers category and see if that solves your problem.

Do you get the same problem if you load the sample that comes with Xojo?

if not, then maybe you missed something with your code.

@AlbertoD the sample works fine. (I had the same thought)

I’m trying to understand how the web framework populates the row parameter for the pressed event when a WebDataSource is used.

It seems to me the row parameter must somehow be interrelated to the data source.

The list clearly does have rows, so the “Row” parameter should be the row clicked, and yet…

@Ricardo_Cruz may have to assist if no one else has seen this issue.

I will try using the current beta as @Patrick_Salo suggested. If this fixes the problem, I’ll share that info here.

If you can share a sample we can take a look and try to help.

@AlbertoD - To be clear, my main goal in posting this issue was to make sure I wasn’t missing something obvious. It appears I am not.

I do consider it a bug that the Row parameter of the default Xojo WebListBox class would ever contain -1 when the list has rows and an actual row was clicked. It’s an inconsistent result.

User code shouldn’t be able to “break” a built-in, framework control’s event.

If I can’t figure out the root cause, the next step will to make a stripped down project.

I’m not sure what you mean by this.
We need to edit/add code to the DataSource that matches our database, so any error on that will cause problems.

I was able to ‘break’ the sample and get row -1 the same as you. What I did is in SortedPrimaryKeys comment the invalidate and cache code (basically line 9 to 42) and in UnsortedPrimaryKeys comment lines 8-40. Now when I run the sample I get this:

so yes, if we have the wrong code it will break things.

Hope this helps.

1 Like

@AlbertoD - this is very helpful and I’m 99.9% sure this what my issue is.

But while it may be quibbling, I would say you are “breaking” the WebListBox, at least insofar as the documentation for WebListBox makes no mention of this behavior in its description of the pressed event:

This was more the point I was trying to make. The behavior is inconsistent with the documentation and so it’s going to feel like something is broken.

In general, the documentation for WebDataSource is pretty slim, especially if it’s the preferred way for WebListBoxes to be loaded. (which I think it is??)

If this behavior is somewhere in the Xojo documentation and I just missed it, please point me in the right direction.

I believe I do understand the issue and… as mentioned above your example was very helpful. Thanks so much! :slightly_smiling_face:

p.s. - once I’ve confirmed this is the issue, I’ll mark your post as the solution. :slightly_smiling_face:

1 Like

Yes, the documentation could improve.

From the Issues available it looks like DataSource has received some work and other related improvements may be planned. I guess that Xojo will add DataSource information once all the changes are in place.

I hope you can add the missing code to your project and make DataSource work for you. Good luck.


@AlbertoD @Ricardo_Cruz - everything is working as expected now. :slightly_smiling_face:

Additionally, @AlbertoD, you regularly and patiently assist users on this forum. It’s pretty great. Thank you very much for your generosity to this community. :1st_place_medal:

Some comments/notes/thoughts for posterity and/or future readers.

  • The issues I experienced were with Xojo 2024r1.1, if you’re from the future :woman_astronaut: and using a much later version of Xojo, the following may not apply to you.

  • Something which I don’t think is well explained in the documentation or the Xojo-provided example project is the relationship between primary key data and row data in a ‘WebDataSource’.

  • Specifically:

    • The ‘WebListBoxRowData’ class has a property ‘PrimaryKey’ which is used to uniquely identify it, at runtime, as a distinct row in a ‘WebListBox’ control.

    • The ‘PrimaryKey’ propery must be set when you’re creating the list’s rows in your implementation of the ‘WebDataSource.RowData’ interface method (as an array of ‘WebListBoxRowData’ objects)

    • Every PrimaryKey value assigned to a ‘WebListBoxRowData’ must also:

      • exist in the integer array returned by your implementation of the ‘WebDataSource’ interface method ‘SortedPrimaryKeys

      • exist in the integer array returned by your implementation of the ‘WebDataSource’ interface method ‘UnSortedPrimaryKeys

      • If these three “lists of keys” are in anyway inconsistent with each other, the ‘Row’ parameter in the ‘Pressed’ and ‘DoublePressed’ events will most likely be incorrect (e.g. -1) and any code there will not be able to correctly determine which row was pressed

      • Additionally:

        • the ‘WebListBox.SelectedRowIndex’ property will also return an incorrect value if the “three sets of PrimaryKeys” (in any class acting as a WebDataSource implementer) are not consistent

        • The sorting logic in the implementations of ‘WebDataSource.RowData’ and ‘WebDataSource.SortedPrimaryKeys’ must be IDENTICAL or the clicked row may not return the expected data

In plainer (I hope) English…

‘WebDataSource’ is a class interface, not a class.

It is up to the developer to create a class which implements the ‘WebDataSource’ interface.

An instance of this class is assigned to the ‘WebListBox’ at runtime via the ‘WebListBox.DataSource’ property, e.g.:

myList.DataSource = new myWebDataSourceImplementer

When you attach a WebDataSource to a WebListBox, much of the “normal” row functionality is altered.

The class (the implementer of ‘WebDataSource’ ) assigned as the ‘DataSource’ is now responsible for maintaining all “row data” and “row state data” for the list

Three methods defined by the ‘WebDataSource’ are responsible for controlling/maintaining “Row State”:

  • RowData
  • SortedPrimaryKeys
  • UnsortedPrimaryKeys

These three methods must “share” a consistent list of unique, integer values which act as the “Primary Keys” for the displayed list rows.

The RowData and SortedPrimaryKeys implementations must also have identical sorting logic or the “index” and the “data” for the WebListBox will not match and unexpected results may occur.


@Ricardo_Cruz - I’m not sure why there needs to be a separate list of keys? (the integer array of primary keys vs. the list of keys in the ‘PrimaryKey’ property in the array of ‘WebListBoxRowData’ objects)

It may be a necessary evil for performance reasons, but it’s certainly “a goodly amount” of extra complexity and management for the developer.

I think it’d be a much lower cognitive load for the developer if they didn’t have to maintain “three sets of keys”.

Thanks again,


If only I’d waited a few more days!! :joy: (or even another 30 minutes or so while I was writing my post???)

This is great new @Ricardo_Cruz , and mostly obviates everything I said above. (in the best possible way!! :smile: )

1 Like

@Ricardo_Cruz and the Xojo team. Great work on the improved WebDataSource interface.

I upgraded my project to Xojo 2024r2 and I was able to greatly simplify my implementation and everything is working very well.


1 Like