I settled on using a timer in stages (thanks to Michel Bujardet for the Timer suggestion that led to this approach):
stage 0: update the visible rows, and fire an event to update any corresponding views.
stage 1: update row numbers lesser than those visible in stage 0, in chunks, up to those visible in stage 0.
stage 2: update row numbers greater than those visible in stage 0, in chunks, up to the last row, and fire an event when completed.
This doesn’t show a beachball, and looks fast to the user. The UI is less responsive for a short time while the timer updates in chunks. It’s less responsive than it would be using a thread (note that a thread would also make the UI less responsive, just a bit more responsive than when using a timer), but in my case I really need to avoid using a thread because of the ThreadAccessingUIExceptions problem, and I also needed synchronous events here.
I know I will be told that this means my design is not good. A problem I find is that Xojo Listboxes encourage us to put data directly into the object, rather than use the object as a view for data. In some cases it makes sense, too. But then we have this problem, that working with data in the object means we can’t easily use a thread to do anything with the data. So yes, the better design is abstracted data and view, where processing and display are basically separate, and the ideal solution then is to use a thread.