If you are in need of a WebTabControl consider putting some points behind this feed back case: <https://xojo.com/issue/23041>

Right now, we’re using a WebSegmentedControl and many WebContainers which is making the code more complicated that it could be. With a WebTabControl, we could have our controls directly on the WebPage rather than having to RaiseEvents to communicate with the WebContainers.

Is there a better method than using WebSegmentedControl & WebContainers for now?

You can store the controls off view and move them into view when needed.

My experiments show that a control can be placed up to top = -512. That way it is never visible, yet it is part of the page. For convenience, you can place a series of rectangles above the page that will mock up the panels to ease layout edition.

When needed, move the controls in place.

To hide them back, put them where they were at design time.

The tricky part is to create the methods to hide and show the controls, but the main advantage is that the controls being part of the page, you do away with the complex mechanism needed to address controls in a WebContainer.

That would be perfect, except for the tricky part. :slight_smile: I might be able to use the name of the controls to form groups and then move them around. I’m not sure if it would be more or less complicated to move all the controls around or work with containers…

I could REALLY use a WebTabControl to simplify my code.

We were using Containers to mimic tab content, but it complicated the app more than it needed. To that end, I’ve been spending a ton of time refactoring each tab to a separate WebPage.

If you could use a WebTabControl, please add some points for it. It’s currently 16th which is fantastic, but I’m hoping that if we can get it ranked higher, maybe it could be implemented soon! It’s been in Reviewed Status since November 2012!!!


Just of curiosity, what you find difficult or overkill in a container?
It is only the way you are referring to a control?

We were using containers to hold all the items on a ‘tab’. We also have a SegementedControl which when clicked brings the corresponding container to the front using the ZOrder. From the Page, it’s easy to reach into the Container. From the Container to the Page or another Container we either had to use RaiseEvent or use a Module.

If we had a WebTabControl we could just put controls on each Tab. That would make working with the controls on the page so much easier as the controls would all be on the same page.

I was talking with @Tim Dietrich yesterday and I realized that I could ditch using containers for tabs and used an old trick we used in FileMaker before they added a tab control. The trick was to create separate layouts that had the tab content on it with something like the SegmentedControl placed in the exact same pixel coordinates. The effect was a tab control, but in reality it was changing layouts.

So we moved each Container to a separate Page and it’s so much easier to use with much less complexity.

The problem is that we were using Container to contain tab content, but Containers are so much better for placing the same object in different part of the system. The Containers we use for our Navigation and for the Header between our ‘Tab’ Pages work great, but not as nice for a Tabs…

Hm…we’ve had some pretty complicated tab’s in recent web projects. I don’t think it’s all that complicated. We generally have a method that controls the switching of the tab. This method sets the tabs visibility. And we create events in the containers all the time since we don’t have to ‘know’ what’s in the parent or other containers. But that’s just us.

What really sucks, for us at least, is that web page resize events don’t give you the actual size of the web page. This makes sizing difficult and leads to putting all the tabs in position at design time.

Thank you for your explanation.
I’m not a fan of webpages and I find working with containers more effective.
For me webcontainers are not a simple grouping of visible controls but also a a way to group togheter functionality.

This is my personal experience.


I also have spent more time dealing with the discrepancies of size in open evens vs shown events vs creation time or whatnot for container controls than I would like to admit. For some things on containers it’s simply impossible to have things setup right when they display. You either have to send them invisible and then in the shown event do all your control re-arranging or let them show up all messed up and watch them snap into place some time after they are shown. The lock positions of controls on container controls do not seem to be honored either. There are bug reports for all those things out there.

But yes, It would be great to have a proper tab control for the web interface.

I’m confused why you need to raise events or change Z-Order though. Why isn’t is as simple as just setting the correct container control to visible and the rest to invisible as you click on the segmented control? You’ll have to place the containers to the proper location in the open or shown event of course, but otherwise I’ve never had to do anything more complicated than just control the visibility of the container that I want to work with?


I ran into this bug when using Scrolling Containers when making the Controls not visible: <https://xojo.com/issue/42891>

To get around it, I had to keep them visible, make sure there is background color on each container, and use the z-order in order to keep them visible.

Oh I see, never mind, multiple embedded web containers. On a single level they seem to work OK, but not embedded another level deep. Never mind. Sorry :slight_smile:

It was good question… :slight_smile:

I never had a similar issue as you reported in the feedback case.
I will try to investigate…


Try out the sample project that Robin attached to the Feedback case.

Yes, I have checked the example project attached to the feedback case.

What I find unusual is that something similar does not happens in my applications.
I use a lot of containers embedded in other containers and also I’m using the visible property to hide/show many of them.
My first impression (first impression, I repeat) is that at the server side all is working as intended and there is no (internal to the app) control leak but at the client side (the browser) something is wrong possibly caused by some command not sent by the server.
So the server loose knowledge of the container and it’s contents but the browser has all elements intacts.

I’ll post to the feedback case and on this discussion any news on this.


I have added more infos and, I hope, a working solution to the feedback case you reported.
I also must correct my previous post.
In my applications the problem was unnoticed (the visible side) but fully present (in the browser side).

My applications are running for days without reloading/refreshing the page.
Users randomly are reporting slowness in the application response time after many days of use.
Maybe this is the cause of the problem?

Best regards.

That’s excellent. Thanks so much Maurizio! Maybe @Greg O’Lone can use that info to fix <https://xojo.com/issue/42891>

I gave some thoughts about creating a WebTabPanel or WebPagePanel.

It is quite conceivable to create a control that is part of the DOM and yet works a bit like a sprite sheet, or a gigantic WebListBox, to show through an area panels that are in fact part of a larger area.

It would be necessary to attach other controls to such a panel, the way a TabPanel works on desktop. It can be done with JavaScript and CSS.

Where it becomes impossible is at the IDE level. In Desktop, the TabPanel and PagePanel in the layout editor show you only one page, and hide the others. Even if the WebSDK control can use a picture to show in the IDE, it cannot undertake the same task.

For the moment being, WebContainers seem like a far easier solution. Even if one has to prefix methods and properties to access them.

Thanks for trying Michel!