Can someone from Xojo make https://xojo.com/issue/26138 public so others can vote on it?
Thanks!
Well, famous last words. I’ve been around long enough to never assume it’s as easy as it seems. The IDE is incredibly big and the Navigator is more complex that many think. Perhaps they’ve looked at it and making the change will cause other issues…
Well in that case, that would be an unfortunate design… 
You and I really have no idea. Different developers over the course of several years made decisions that may or may not be good ones, looking back, but at the time seemed valid.
Can you tell me that you’ve never made a mistake in a design and had to live with it for a while until you could fix it? I know I’m not that perfect.
[quote=65913:@Bob Keeney]You and I really have no idea. Different developers over the course of several years made decisions that may or may not be good ones, looking back, but at the time seemed valid.
Can you tell me that you’ve never made a mistake in a design and had to live with it for a while until you could fix it? I know I’m not that perfect.[/quote]
Of course I’ve made mistakes - ALL OF THE TIME, still living with some of them!
I don’t know the nuts and bolts of what’s going on under the hood of the IDE. My only point is that it would seem logical in the early stages of design that the user “might” want to sort a list, possibly of several hundred items in multiple ways, alphabetically being one of them. If they did not foresee that and boxed themselves in corner making it a monumental or significant task to allow that then so be it. It is what it is, we’ve learned to live with it thus far, although unfortunate.
I was merely suggesting that indeed, I thought it was a good feature request by Kimball. I also offered some possible way to accomplish that task which in hindsight was a mistake because I didn’t fully understand the behemoth the IDE is, for this I apologize.
No worries - no need to apologize. You’re talking to a guy hated by more than a few developers for my rants about the Navigator. 
Bob, you got it mixed up: You’re talking to a guy loved by more than a few developers for my rants about the hated Navigator.
You were one of the few alpha testers who didn’t sleep during the alpha period.
Thanks for your your explanations which you called rants.
Everybody has their own perspective. Right or wrong (in the long run) I was saying what was on a lot of minds.
If you stop your programming business, you allways can become a diplomat.
Ug. 2nd time that’s been said to me in less than 24 hours.
I’d like to think I have more morals than your average politician.
I’d say the main reason it doesn’t exist is because it didn’t exist in the previous IDE. The 2005 IDE had a ListBox handle the sorting, but the actual content order in the project file didn’t change. So there was no need for a command to change the sort order of the actual contents.
The navigator is not a ListBox. Sorting does not come “for free” and is managed completely differently than a ListBox. Source lists don’t usually handle sorting, and there was no command to port, so it just didn’t happen.
[quote=65009:@Norman Palardy]I mostly just modify it
I’m not saying we can’t alphabetize the list
Just that with the things available in the new UI trying to use it exactly like the old IDE may not be the best approach
It’s not the old UI so working the same way you always have will feel like a constant fight
Trying an alternative may work well or even better[/quote]
You know, using this argument, there isn’t any need to even display the items in the project in the navigator. If the user interface is only intended to be searched - and browsing is extraordinarily and unnecessarily difficult - then we can simply dispose of the visual list altogether.
Otherwise, alphabetize it. You’re mistreating your users by not doing so.
And while I’m up on this soapbox: I’m a firm believer that the user interface drives the engineering in software, not the other way around. If you cannot do something correctly due to a technical constraint, you don’t do it UNLESS the product is untenable without the feature. And then you bury the feature deep in the interface so the casual user doesn’t stumble upon the ugliness.
Personally i am not in favour of automatic alphabetizing lists in the navigator. The example shown in the first post i think you can move every window in the list to the place you want. In that way you are free to alphabetize the list yourself or what i prefer, organize them in a logical way and you only have to be carefull when choosing the name of the window. If you alphabetize that list it’s logically a chaos and if you organize them logically it’s alphabetically a chaos. Now you have the choice which chaos you prefer.
I’m with Andre on this one. Granted, I’ve only been a Xojo programmer for one year now, but have programmed in various other languages for almost 40 years (yea … good ol’ Fortran back in college with submitting your card decks was one of 'em … and yep, I’m old as dirt). While I wouldn’t mind the “availability” of an alphabetize feature, 95+% of the time I use the “drag the stuff around the navigator manually to sort them in a logical manner” method which serves my eye better for finding things. Adding to this, I selectively use folders to group “like” items (e.g., all windows that deal with a similar operational part of the program, container controls that relate to a particular program function, etc.). Now, what I DO wish for is the ability to use folders down deeper in the nested structure (not just at the “App level”), like to group text field controls within a given window … that would immeasurably clean up my Navigator, especially when I have 30 or more text fields in a window or container, and make it even easier to zero in on the specific things I need at that moment in time.
Use Containers to do this. We use them a lot.
You threw me there, Bob. Maybe I didn’t state that right … Are you talking about using containers (in lieu of folders) in the Navigator to organize controls? If so, how do you do that? I already use container controls in my applications like they’re going wild … couldn’t do without them. I’m looking for the ability to “organize” controls for appearance and orderliness sake in the Navigator.
If you have a busy UI (say 30 controls), use containers to break it up. Put these 30 controls (and logic) in a new container. Then add that container to the window. The navigator only sees 1 control even though there are 30 there.
Thanks for that response, Bob. I do that now. My problem is when I hit the expand button in the Navigator on that “1 control” (Container), if I have lots of controls in that container (not uncommon to have 50 or more), the contents of that “1 control” fills the Navigator window from top to bottom forcing wild scrolling up and down to get to other stuff in the Navigator, especially if the listing is particularly long. And unless something has changed very recently, you can’t grab an item at the bottom of the Navigator and drag it upwards beyond what is currently displayed (the topmost displayed item) in the Navigator listing … if where you want to drop it is above the current top item displayed in the Navigator (which may be far from the actual location (or top) of the actual total listing, you have to start closing anything you expanded to be able to “see” the top of the listing (or wherever you’re trying to drop the control). I’d like to take the controls in that “1 control” and be able to use folders to further organize them to keep things more orderly. Say, one folder for labels, one for text fields, one for buttons, etc.
I hope that all makes sense.
The ability to alphabetize would be a “nice to have”… but ONLY if it were an option. I do not want someone else workflow forced on me any more than necessary 
Some projects I like to alphabetize. Others I arrange methods and classes based on relationships… it all depends…
Ah, but on the Window you’ve added it to only expands to show the container events you’ve added. NOT the individual controls. The individual controls only show in the Layout editor when you’re on the container.