I’ve been building a reasonably sized, single window app which has been my learning ground as I’ve been getting to grips with Xojo. It’s a multi purpose app that does various in house management jobs for our company. So, some client management, some CMS, some audio export/conversion stuff, royalty accounting etc.
It has 1 master PagePanel with 13 panels (so far). Some of these have 2 or 3 PagePanels within them and there are quite a lot of controls. Example
My problem is that adding new controls (or renaming them) is getting slower and slower to the point where it now takes nearly a minute to add a new control and then the same again to name it. So the page in that example would have entailed nearly an hour in total of watching the beachball!
So, if I were to redo the app from scratch, what could I do to avoid this? Would love to hear your suggestions for how you’d do it better.
(BTW I’m on OSX, 10.9.5, 2009 MacPro 8 Core and using 2013 3.3 as I need a build for 10.6.8)
you might also want to consider multiple windows as your workflow instead… If you have 13 panels so far, and some of those have subpanels, that one window has to maintain the overhead of ALL that stucture… and while container controls might make it “easier”… that really doesn’t change the actual application overhead at all… since a container control is basically a “window” inside a “window” as opposed to a “panel” within a “window”
Yes, adding a lot of controls inside layers of PagePanels can slow down the Xojo GUI. It too have this in some projects. I wouldn’t say it takes minutes but up to 10 seconds before a control is selected.
As Eli pointed out, using Containers helps a bit (but not that much though).
one of my test projects has 1500 windows, 1500 containers, 1500 menu bars & some pages have as many as 1500 controls, 1500 constants, 1500 properties, etc
The best advice I can give you with one window & hundreds / thousands of controls ?
Don’t do that
I have a small suggestion, something I did in the past and it worked beautifully. It may not be enough to avoid a re-write, but it’s something to keep in mind for future.
I see in the screenshot you have 6 sets of information for composers with three items each. (web, PRS and split). I would consider making a container control for these three things with plus and minus buttons to allow the user to add and remove a set as needed. You can do this using the embedwithinpanel functionality. (See the “Rules” tab in Apple Mail preferences. To see what I mean click “Add Rule”)
This will reduce the overall control count for the window by 36. If you have enough similar kinds of setups it could help with the sluggish Xojo IDE.
Otherwise I would move some functionality to a modal window, like that “Edit Composers” button looks like it may be a good candidate for a modal window.
[quote=194063:@Richard Brown]I’ve been building a reasonably sized, single window app which has been my learning ground as I’ve been getting to grips with Xojo. It’s a multi purpose app that does various in house management jobs for our company. So, some client management, some CMS, some audio export/conversion stuff, royalty accounting etc.
It has 1 master PagePanel with 13 panels (so far). Some of these have 2 or 3 PagePanels within them and there are quite a lot of controls. Example
My problem is that adding new controls (or renaming them) is getting slower and slower to the point where it now takes nearly a minute to add a new control and then the same again to name it. So the page in that example would have entailed nearly an hour in total of watching the beachball![/quote]
Looks good. Instead of adding more and more controls in panels, you may want to start using different windows for different screens. If you display a new window with exactly the same size and position as the previous one, to the user, it looks as if he did not change window. For your app in the IDE, it will be much lighter.
You can even start from your existing window and make several new ones out of it, not by adding, but by subtracting. Then instead of switching panels, you switch windows.
Think about it when you need to add new functionalities.
Or to minimize on the opening and closing of windows (could lead to flickering) you could just embed a container control as it is needed and then “close” the existing container control… One window, just swap out the interface as needed…
