Suppose I have two WebContainers. Each container has a WebListBox that loads data from a SQLite database on the containers Shown event. Only one container is ever embedded in WebPage1 at any moment. Whatever container is embedded is determined by what segment the user presses in a WebSegmentedControl. When the user changes containers this way, whatever container was previously embedded is closed by calling a CloseMe method (Me.Close) I have assigned its superclass, before embedding the newly chosen container.
I find that a JavaScriptError can arise if the user too quickly changes containers (via the WebSegmentedControl mentioned above) before the currently embedded container finishes its Shown event (where it loads its WebListBox, among other things). This makes sense to me. So I’m trying to come up with a way to prevent the WebSegmentedControl from switching containers if the current container’s Shown event (or any other event in that container, for that matter) isn’t finished.
I’m thinking of adding a property to the superclass of those containers, called, say, OkayToSwitch (As Boolean) which is set to False when this or that method begins, and set to True when that method finishes or returns midstream. Then the WebSegmentedControl.Action event will be coded to watch that property before swapping containers.
Instead of dynamically embedding the WebContainers, why not add them in the IDE and alternate their Visible property. This works really well for me often with 5-10 WebContainers on one WebPage.
When the WebSegmentedControl Action is called I hide all the WebContainers then in a Select Case statement I make one visible and refresh its content.
[quote=392809:@David Cox]Instead of dynamically embedding the WebContainers, why not add them in the IDE and alternate their Visible property. This works really well for me often with 5-10 WebContainers on one WebPage.
When the WebSegmentedControl Action is called I hide all the WebContainers then in a Select Case statement I make one visible and refresh its content.[/quote]
So then you don 't close WebContainers that aren’t visible? Doesn’t it use a lot more memory keeping them all open?
I see that I already use David’s method within a particular WebContainer, where I have a WebSegmentedControl within that container, and that SegControl loads one of 5 possible subcontainers via the container’s Visibility property, making the other 4 not Visible. However these are much smaller and less involved containers than the ones I mentioned above. The ones mentioned above are essential full blown Web pages, though they’re containers of course. I’ll think more about this, considering it I want to use this approach with the containers mentioned above.
I was thinking of using a Timer as an alternative, and have that Timer watch the state of the OkayToSwitch property mentioned above when selecting a SegControl selection. But that is certainly more complex than the Visibility approach.
Won’t invisible containers that are chocked full of controls and data, including listboxes filled with data, increase the round trip expense, even though they’re invisible?
I bet what you’re going to say is invisible containers take up the same amount of memory has visible ones, but invisible containers, and the controls inside them, don’t participate in the round trip to the browser.
A proposal without a timer:
You could disable the SegmentedControl once it is used to switch to another container.
Have the Container fire a “InitializationFinished” event once it is done drawing, preferably decoupled from the Shown event by a Xojo.Core.Timer.Calllater call or similar.
In the event handler, enable the SegmentedControl again.
The alternative is re-embedding them as required causing more traffic. I have never found the memory to be an issue even when running my WebApp on an iPhone in Safari. Despite this, it does take a little longer to launch after login as it sets up all the containers and controls, but runs fast once loaded.
Thats true in terms of user interaction, but they do have to be delivered initially and if they contain controls like running timers they certainly do affect bandwidth.
If youre going to do this my suggestion would be a hybrid approach. Use embedWithin to add the panel when you need it, use Visible = False and turn off any timers to hide it when another panel is shown (so itll still be there if the user comes back) and Close it when the page is closed.
[quote=392945:@Greg O’Lone]Thats true in terms of user interaction, but they do have to be delivered initially and if they contain controls like running timers they certainly do affect bandwidth.
If youre going to do this my suggestion would be a hybrid approach. Use embedWithin to add the panel when you need it, use Visible = False and turn off any timers to hide it when another panel is shown (so itll still be there if the user comes back) and Close it when the page is closed.[/quote]