2019r1.1
I am considering building a app which makes use of the principles demonstrated in the Xojo Examples “WebGridContainer” - but I have noticed some odd behaviour with this example, and just want to understand what happens, and when, and why…
If I run this example in debug on my Win 10 laptop - or if I run it on server as a cgi app the results are pretty much identical.
First, startup / run an instance of this example app.
Enter a number for rows (let’s say 20)
The app runs as expected, 20 row containers are created, and each row cell reacts to user input, as expected.
Now start up a second session of this app, but this time enter a fairly high number of rows (let’s say 500).
As you would expect, the creation of 500 containers takes a bit of time… about 3 secs on my laptop.
But here’s the weird bit…
Once the 500 row grid list has appeared (and you can freely scroll up / down the list), Any attempt to update a row cell appears to stall, for around 25secs. This only happens once. Further interaction with row cells responds instantly and normally.
Now, here’s the second weird bit…
If, you enter 500 rows in the second session (like we just did above), and wait 3 secs for the 500 row grid to appear… Now switch back to the first Session (the one with only 20 rows), and try to modify one of the cell contents. Guess what - the update is stalled for around 25secs. Again, this only happens once. (Unless a 3rd person logs in and creates another 500 row grid, in which case this 25sec stall will happen once again).
So what is happening??
It seems that the UI gets the containers drawn reasonably fast (3secs - a bit slower for a remote server) - but this is to be expected. But what is THEN happening after the screen is drawn that seems to totally saturate the server for a good 20 - 30 secs afterwards?? And are there any events I could hook into to that would let me show / hide a progress wheel once the server has recovered?