Web app "sub screens"

I have a Web app that needs some buttons on the top to navigate various functions that appear on the lower section of the screen. My initial technique has been to create a Webpage with several container controls. Each “sub screen” for the lower section is in a different container on this same Webpage. I start with VISIBILITY = FALSE and ENABLED = FALSE on all of the containers and turn them on one at a time as needed. The Webpage design in the XOJO IDE looks pretty weird and is hard to manage since all of the containers are laying on top of each other in quite a jumble.

Part of this interface was built from a more complex portion of the app that was already working. This is a clinical app that has clinicians and patients accessing the same data. The clinician interface is more complex with many functions (and built first) and the new patient interface is much simpler and omits many of the clinician functions. When you log in to the app it detects if you are a clinician or a patient and takes you to the “main menu” for each perspective.

MY QUESTION

Is the technique described above the best way to approach the problem. I really don’t want separate Webpages that must repaint completely.

ALSO — Because I need to call some methods from different containers it makes life “interesting” to keep properties and methods in scope as they cross over containers. Some of this code was “borrowed” from a different part of the app where methods and properties never were needed outside of a specific container. Would it be best to put all of the methods and properties at the top level Webpage and explicitly reference them with a complete path?

Thanks.

[quote=47764:@Mark Strickland]Is the technique described above the best way to approach the problem. I really don’t want separate Webpages that must repaint completely.
[/quote]

Do you think you’re eliminating flicker with this technique? Or do you think you’re loading things more efficiently? You’re actually not doing either.

i do something similar to you, mark and instead opening the container control full size, i set to to smaller 100x100 pixel and in the code when open adjust it to the size i want in the middle by centralise it.

This was not to control flicker. The original idea was to “simulate” a tabbed style interface with the top part of the screen not changing and lower part showing the desired “tab”. Hiding and showing alternate containers seems to happen nearly instantly after just a very brief delay but certainly not flicker.

I had not thought of resizing the containers.

The biggest problem is putting the common methods and properties in scope for all of the containers. If I had designed this from scratch and not tried to repurpose some existing code that would have not happened in the first place. Most of the methods are attached to specific containers but this interface requires some methods need to be called and properties changed outside of the container where they reside. If I had realized that this would have been a feature to be added on later it also would not have happened because the original design would have accommodated it. Ah the joys of “rework” … even if it is your own code.

I probably just need to reorganize the methods and properties the way it should be and get this done right.

Anyway … thanks.

I guess I don’t see what the gain is other than swapping one small inconvenience (same navigation control on multiple pages) for a bigger one (swapping containers in and out. I’d stick with WebPages because that’s what the framework is designed around. If you have properties or methods that need to be shared among the views, make them Session properties/methods.