In my case I build the tabpanel in the IDE, putting one DesktopContainer on each tab. Then at runtime there is no work to do; the user clicks another tab and that is then what gets shown. No removing or anything.
Yes, that is the basic idea. But it is better if the tabs are also dinamic, something like, a button or menu to add the tab, Embed the container and leave it there until the user closes the tab. But this is a general idea, I cant suggest something specific without knowing the workflow of the app.
Well, Xojo has not the best performance… Better to avoid problems with the control count.
In VB6 was kind of weird the limit of 255 control names per window in VB6, but yes it was possible to have more than that with control arrays.
Have you more than 1,100 controls in those containers???
Perhaps 30 or so, no more.
The initial problem reported here was the IDE being extremely slow, the application was fine. Just using container controls would solve that problem as, within the IDE, the container just shows as a blank slate on the tab panel.
Each container control is then on its own and thus only has the controls on that given panel at IDE editing time. Don’t forget that the IDE has a lot more going on in terms of handles that his running application. It has every control that is visible within the IDE framework along with all the additional items you add to your windows.
That said 1100+ controls on a single window is pushing the limits of sanity.
2 Likes
You do not understand the answer/advice you get.
An application may have far more than one window.
So, you can split (maybe) the controls on many different windows; you can also put your Methods and Functions in a Module (and still all then like you actually do).
I’m not sure this is even supported. Does anyone know? Or is it only tab panels on page panels and vice versa that’s a problem?
Tim, yes, this worked fine. A tab panel on each tab of a (main) tab panel was no problem. That’s what i use already for a long time. Works faster than a menu with sub menu’s. Problem is also not things going slow. After building the app there are no problems.
Xojo freezing and flickering of the (Xojo) menu bar and for example the opened Notepad or the Task Manager happened in design time. When i tried to add some more functions.
With my back-up i tried again and again, sometimes the problems started when removing controls instead of adding more.
But, with all the good advice getting, i understand that there is a limit of controls on 1 window. Dividing the controls over more windows and opening those windows from the main window would be the best solution. Or with containers. Dividing the controls over container. It’s worth trying.
Also, if my design is a BAD design, then i must say that nowhere in the Xojo help pages or other knowledge pages, i found something concerning limitations for using controls on a window. It seems that its not a common problem but with al your advice i should find a solution to add even more controls then 1100 
Not here:
Is there a setting to instruct Xojo to not display the contents of a container when it is in a Tab Panel or as child of other control/window?
There isn’t, but you don’t have to worry about those. Container contents are just pictures when they’re instances on other views.
1 Like
I was going to say, those are not controls, as such, you can’t drag them around or click them at all. As Greg has pointed out it is just a picture of the layout.
I was confusing the blank slate, with a ContainerControl I’ve been using to build a grid control. That has a is primarily a Canvas with a few other controls. That Canvas doesn’t really show on the window editor. My mistake.