Surprised me that this feature request was turned down.
I went looking to see if someone had requested it as it’s my biggest niggle with Xojo, larger products become a mess in the IDE.
You have SO many controls in a single window that they are unmanagable? Perhaps the use of Controlsets, or custom container controls might be a better option.
I have been using Xojo for 13+ years, and never once has this “feature” ever crossed my mind.
Now using folders to organize Images, Classes and Methods… sure… but never “controls” within a window
I did find it interesting that it took Xojo over 7 years to decide to close that Feedback
Yeah I cant say Ive ever wanted that.
It’s a code smell. Organise your stuff into manageable portions. That means a liberal use of container controls and control sets.
[quote=468577:@Dave S]You have SO many controls in a single window that they are unmanagable? Perhaps the use of Controlsets, or custom container controls might be a better option.
I have been using Xojo for 13+ years, and never once has this “feature” ever crossed my mind.
Now using folders to organize Images, Classes and Methods… sure… but never “controls” within a window
[/quote]
I have an app that uses a pagepanel control and has 7 panels. Each panel is unique so container controls are not an option.
I’m not alone as this has come up on the Xojo feedback system, the forum and in other language forums too.
In life I’m a bit OCD about organising stuff so maybe it’s just me but I do often find myself searching for a control in the list and scrolling up and down a lot.
A few organizing methods I use may help.
- make all generic labels member of a control set. I name it “A_Label” so it’s at the top of the list and easily collapsible.
- prefix my controls’ names with a type identifier or other mnemonic. I.e. “cc” for ContainerControl, “tf” for textfield, and so on. Makes them much easier to locate in the list, and to filter on.
- use ContainerControls wherever possible. Aside from visually cleaning things up, it forces me to think about what functionality I need to expose (a mini API if you will).
PS. not sure why you think unique panels preclude the use of container controls.
when you think you need hundreds or thousands of controls STOP and rethink
if some of them form some kind of logical “control” when placed together or used together then extract that into a container control,
put an API on the container control
then use an instance of the container control on the layout
the IDE is more or less arranged that way
there’s a “navigator” pane that is a container, the editor pane - which has many different subclasses, and the inspector & library, and the bottom pane that has the debugger, errors and warning, and find results
its effectively a handful of components that talk to each other mostly through their API’s
[quote=468680:@Tanner Lee]A few organizing methods I use may help.
- make all generic labels member of a control set. I name it “A_Label” so it’s at the top of the list and easily collapsible…[/quote]
Yeah, control sets only really help with organising labels, Paul L says as much in his video on them.
[quote=468680:@Tanner Lee]* prefix my controls’ names with a type identifier or other mnemonic. I.e. “cc” for ContainerControl, “tf”
for textfield, and so on. Makes them much easier to locate in the list, and to filter on. .[/quote]
I do use those conventions,
I do where I can but even so the IDE gets full and difficult to navigate very easily.
I know they don’t preclude them but each panel has a unique interface that cannot reuse a container in this particular app I have.
[quote=468681:@Norman Palardy]when you think you need hundreds or thousands of controls STOP and rethink
if some of them form some kind of logical “control” when placed together or used together then extract that into a container control,
put an API on the container control
then use an instance of the container control on the layout
the IDE is more or less arranged that way
there’s a “navigator” pane that is a container, the editor pane - which has many different subclasses, and the inspector & library, and the bottom pane that has the debugger, errors and warning, and find results
its effectively a handful of components that talk to each other mostly through their API’s[/quote]
I do know how to use container controls and have a few in this app but sometimes you cannot abstract the whole interface.
The fact that we are using kludges such as using a control set just to organise controls in an IDE suggests that folders for any items would be good for people like me who like to organise things.
Rod… the best you can do is file a Feature Request and wait a few years… but don’t hold your breath, as so far you seem to be of a very small minority interested in this.
It doesnt have to be the whole interface
It could be a single “control” - like in the inspector where each “row” is actually a container control that focuses narrowly on ONE type of property to show
Or the navigator rows which are also each a container control
[/quote]
I’ve used RB/XOJO for > 20 years (literally since before version 1 shipped) and I have NEVER used one 
Speaking of folders… i would love to be able to add folders to the methods and property sections to group them by purpose…
Once one gets to more than 10 to 15 of items in a section being able to group them in folders by type/purpose would help to find thing faster in the navigator and even help the class/module be more self documenting.
This one of those things that how visually oriented someone is makes a difference how things work best for them… Longer lists make my eyes glaze over and I find it hard to spot what I want… I notice that others can do that much better than I can so for me it would be very helpful
-Karen
folders everywhere would be a pretty serious overhaul of how a project is represented internally so I wouldnt hold my breath
again IF you find you need to group things by purpose maybe that thing should be a cc or some other kind of embeddable object (class, module, etc) that groups things
that wont always be possible but as a rule of thumb about when to think about splitting things up its been pretty handy over the years
[quote=468732:@Karen Atkocius]Speaking of folders… i would love to be able to add folders to the methods and property sections to group them by purpose…
Once one gets to more than 10 to 15 of items in a section being able to group them in folders by type/purpose would help to find thing faster in the navigator and even help the class/module be more self documenting.
This one of those things that how visually oriented someone is makes a difference how things work best for them… Longer lists make my eyes glaze over and I find it hard to spot what I want… I notice that others can do that much better than I can so for me it would be very helpful
-Karen[/quote]
it looks like us visually oriented organised people are in the minority Karen!
[quote=468734:@Norman Palardy]folders everywhere would be a pretty serious overhaul of how a project is represented internally so I wouldnt hold my breath
again IF you find you need to group things by purpose maybe that thing should be a cc or some other kind of embeddable object (class, module, etc) that groups things
that wont always be possible but as a rule of thumb about when to think about splitting things up its been pretty handy over the years[/quote]
I have wanted that for years… I think I even submitted a feature request for it via REALBugs (IIRC that was the name of the feedback type app they had many years ago before they used Fogbugz )
What I sometimes do if I don’t need strings, is use structures to group things to help neaten the navigator (and debugger!) up.
Oh I’m organized
I just use a different means to organize that also helps me factor things into much smaller manageable & testable chunks
My current project has a lot of container controls much like the IDE does
I can change the guts of any one of them and not affect anything else UNLESS I change the API
And again my main windows has 4 containers - some of which are containers of containers of containers
[quote=468754:@Norman Palardy]Oh I’m organized
I just use a different means to organize that also helps me factor things into much smaller manageable & testable chunks
My current project has a lot of container controls much like the IDE does
I can change the guts of any one of them and not affect anything else UNLESS I change the API
And again my main windows has 4 containers - some of which are containers of containers of containers[/quote]
If something makes sense (to me) to be totally separate I do split it into a separate class…
But since classes can not contain classes and it often does not make sense to create a separate module, so using separate classes for very closely related stuff clutters up the navigator even more, and makes the project harder to work with for me… That is one reason why I want folders in the sections of items…
And while the IDE may not be structured to handle that (I sometimes wonder if the IDE is not full of spaghetti code for how hard it is to change things 
), it would not require any language/compiler changes…
-Karen
its not spaghetti
nor would this require compiler or language changes
it would likely require changes to how the project is represented in memory to hold all those folders and lists of their contents and that would likely have an impact on how projects are saved & written
so its unlikely to be a trivial change