Question about using TWebPageControl

[Peterson_Terry (Terry Peterson)]

I have implemented a form using TWebPageControl on which one tab has a WebStringGrid with 1k to 10k lines. I find that there is an unacceptable delay in changing between tabs when the grid is populated. The delay grows longer as the number of grid lines increases. I'm guessing that this happens because the grid's HTML table is destroyed and reconstructed each time the active tab is changed.

Part of the annoyance of the delay is due to the fact that there is no visible feedback between the time that the new tab is clicked and when the new page becomes visible. I've tried several tacks to get such feedback, such as "disabling" the tab OnChange or popping up a message in an event or setting the grid invisble, but these don't seem to work.

Is there some way to avoid this delay using TWebPageControl or should I use some other control?

[Peterson_Terry (Terry Peterson)]

Absent a way of removing or reducing the delay in switching tabs when one of them contains a large grid, it would be at least much better if the control could respond to the tab click by changing the tab shading to acknowledge the user's action. Is that possible??

[AndrewSimard]

First, that's a lot of records for a TWebStringGrid. It doesn't have any 'smarts' like a virtual cursor to render only what is visible, so it takes the browser a bit of time to render the display. On my system, it does take 3-4s which is a lot - enough to justify a different approach, certainly. Using another component that does support this would likely make switching much, much quicker. I like Tabulator myself, but there are plenty of others that might be better suited to dealing with so many records.

Second, I routinely use TWebPageControls but I don't much care for the tabs or any other aspect of the UI that is presented - I've always replaced them with buttons or a similar mechanism, and thus have a bit more control over how they are displayed and what transpires when clicking on them. This isn't really the fault of TMS, just how these kinds of controls work. I'm usually after the paging mechanism and not so much the UI as it is. Approaching it this way would allow you to add whatever you like to the display as the page switch is updating.

You could even, for example, have the TWebStringGrid displayed under the TWebPageControl, and just hide the TWebPageControl entirely when selecting that "tab" - and thus not incur any additional rendering delay beyond the initial penalty when it was added to the page.

Naturally this is kind of doing an end-run around the TWebPageControl and won't be all that helpful if you have more than one render-heavy page, but there are always lots of options that can be explored.

[Peterson_Terry (Terry Peterson)]

Thanks, Andrew. I was sort of hung up on the tab solution because this app is intended to be an extension of an existing MSFT Store app whose users will be familiar with that UI. However, I didn't make the leap to using (radio) buttons to actuate the tabbing (and had forgotten about the ShowTabs checkbox in the Object Inspector). I'll give your solution a go.

[AndrewSimard]

In the wide world of web development, we're free to do whatever we like, and there are always options in cases like this. Here's a glimpse at an upcoming blog post where the same approach is used, but with very different buttons. This, too, is controlling a TWebPageControl (which is empty here).

[Peterson_Terry (Terry Peterson)]

Yes I'm still taking only baby CSS steps (and reading your blogs on it for guidance, thanks).

[Peterson_Terry (Terry Peterson)]

I put the WebStringGrid behind the WebPageControl and then hide the latter when the grid's (hidden) tab is selected via a WebRadioGroup button. That does minimize (but not eliminate) the inter-tab switching delay. Perhaps I need to use the sleep trick to make the button presses more responsive. (Edit: Yes, that did it)