iOSTable did scroll to bottom

In a iOSTable, I’m searching how to get the “did scroll to bottom” event to load more rows.
That’s absolutely necessary when using a request that send a paginated result (one page of rows of a big query)
I’ve seen this :
But I don’t know how to implement this in Xojo :frowning:

Yes, but is it possible via Declares ?

It would be nice to have ScrollPosition in iOSTable, that would probably solve the issue. But by the same token, there are so many things that seem obvious that are not in Xojo iOS…

A Feature request has been filed in beta over a year ago <>


In theory yes. In reality this would most certainly mean to create a custom tableview from scratch. UITable is a very complex control. In order to catch an event, you need to declare its object class and override the methods like didScrollToBottom to make calls to them fire Xojo events. UITableView itself uses a few helper instances, of which at least one (the dataSource) is more or less like a Xojo interface; you have to fill it with custom code to make it work. The Xojo implementations of them are black boxes, so its a do-or-die situation: Either extend the Xojo control with a few declares but leave the original structure (and the events) which is not sufficient for a really customizable table , or build the whole thing from scratch. Which is a monster.

Thanks guys, I understand.
That’s a real show stopper for me.
Xojo : please make the feedback 36918 case visible to all and I’ll vote for it.

You could create a custom table with a canvas.

Yes Michel, I could also develop my app with Swift :wink:
Seriously, I chose Xojo to develop quickly… if I have to use a canvas each time a feature is missing in Xojo, I’ll loose more time than using XCode.
Even if I think Xojo for iOS can be a good product, I’m worried about the very few evolutions made since one year.

I have a fully operational “xojo like” listbox (NOT a UITable), but it is in SWIFT so doesn’t help much here…
I’m still vastly disappointed in XOJO attention to their iOS product

In the present state of Xojo iOS, lots of things have to be reinvented indeed. And that is a real pity.

If using a canvas bothers you, since you cannot hope for a fixed iOSTable before a couple releases ( AFAIK there will not be hope of iOS significant evolutions before at least 2016R2) the only way to lift the showstopper without custom control is indeed to go Swift, or other iOS tool amicable to your programming skills.

I’ve made <> available to everyone.

FYI: Xojo does include example project that shows how to use Declares to select a specific row and scroll to its position: Examples/iOS/Declares/TableSelectAndScroll

Paul, I believe he wants to know if the user DID scroll to the bottom, not how to force it there.


I may be able to hack this together with some declares. Give me some time…

Try this:
You will have to include iOSKit in your project as well, but quick tests show this does the trick. I might change which event I implement to do this, but it should work for you. I’ll add it to iOSKit in the next few days. If there are other events that people want implemented, please let me know here and I will add them before committing.

While you are at it, if you could provide a way to get the ScrollPosition, I am sure that would be very welcome.

I’m not sure what you mean by ScrollPosition? Like what is visible when they stop scrolling?

Yes. In the Desktop ListBox, it is the first visible row currently displayed.

Paul mentioned the declare in the examples that allows to set that, but there is currently no way to get it.

Incidentally that would enable detecting when the table reaches the end or the beginning as well.

Yes, that should be possible. I’ll take a look at the desktop listbox and see which similar properties can be easily added. Implementing the entirety of UITableView would take a very long time.

The interesting thing with ScrollPosition get/set is that it will enable synchronizing tables in an hypothetical Scroll event or with a timer, effectively providing a way to create multicolumn tables. In conjunction with ContainerControl, and using iOSCellData.Image, one could do pretty much the same as Listbox with the CellBackgroundPaint and CellTextPaint events.

For most uses, it would probably be overkill.

Yes and no. The problem is that without most of the TableView features implemented, even simple extensions are hard to handle, if they can be handled at all. At the beginning of iOS in Xojo, I made a TableView extension using only declares “from outside”. Even coloring rows was unreliable and had to be fixed with a timer changing the color over and over again. That’s no solution for a battery powered device.
In order to change the look of table rows, you have to catch the willShowRow and similar events. In order to accomplish that, you must install a custom datasource class. And that’s unfortunately a big chunk, together with the different necessary subclasses for cells and headers and footers and all.