Code Explorer should allow folders for groups of items

[bclothier]

OOB, the CE will list all objects in a single flat list.

Compared to VBA Object Explorer, that's kind of a step backward because at least in the OE, we had folders for component types --- a folder for modules, another for class, another for userforms, and yet another for documents (e.g. Access has Form_ and Report_ all together in its own folder).

Seems to me that OOB, the CE should at least offer the option to group component types and provide folders.

Bonus: give a folder for Access' Forms and Reports. In lot of Access databases, the amount can be quite numerous so it can be pain browsing through long alphabetical list of forms before you can get to the first report.

Obviously, this only applies if there's no @Folder annotations. Getting this OOB would help a bit with keep things organizing, and we can then sic the annotation to our hearts' content.

[retailcoder]

I'm kinda torn here. I want to agree with you - but grouping modules by component type is just so utterly, completely wrong that I simply can't get myself to make that the default: seems it would do nothing but send the (wrong) message that "hey it's ok if you don't want to bother with figuring out what's supposed to go with what, forms go with forms and modules with modules and classes with classes anyway".

The current default is by "namespace", where everything that doesn't have a @Folder annotation gets dumped into the default "project namespace"... which is indeed somewhat annoying when you're looking at a rather large, existing project.

A step backward... yes and no. linking #3307 - if sorting worked as intended, you would be able to keep forms with forms and modules with modules and classes with classes, albeit under the same default folder (or does that work?); the idea is to completely step away from taking the component type into consideration, since it makes absolutely no sense to group things that way.

Group modules by functionality, not by component type. Same reason I cringe when I see an Enums namespace in a .net project.

[retailcoder]

I think I'm willing to allow it, but not to make it the default.

[bclothier]

No, the sorting are not really the same. In the OE, we have a general order of document modules, then forms (AKA userforms), then standard modules then finally class modules.

In CE, it's now standard modules, document modules, class modules. (not sure where forms would go as the project I'm looking at doesn't have any userforms).

If your objective is to get nimrods like me to do The Right Thing™, then may I suggest that you consider making it absurdly easy to create folders - right-click to create folder, drag'n'drop, etc. (which would simply result in writing the @Folder annotation without me having to visit each module and adding it).

OR - add a search bar so I don't have to care about the one big ugly flat list, where i can type in a word and match all modules that contains the word in its name.

[retailcoder]

Folders don't really exist though - a folder is rendered when there's a module under it, because there's a module under it; an empty folder simply can't exist in the first place.

I agree folders' usability needs to improve - a lot.

As for search... have you tried the find symbol command (default hotkey Ctrl+T)?

[bclothier]

I didn't know about that, thank you but unfortunately, no.

Compare to the search bar on navigation pane:

I don't need to have complete word but it'd list me all modules. In a large project, it is very probable that you'll have several forms, reports, and modules that has similar keyword somewhere in the name. This search bar functionality would make it easy to quickly find related items without having to create the annotation.

PS come to think of it, this also would make folder creation easier. Search to narrow down the list, then apply folder annotation en masse....

[retailcoder]

Find Symbol would list and navigate to any module, procedure, property, enum, constant, variable, line label - heck, anything that has a name can be searched and navigated to.

That said I haven't used MS-Access in years, I have to say this search box is rather nifty.. but correct me if I'm wrong, that's an Access feature, not a VBE feature. We could definitely have a similar search/filter functionality in the Code Explorer... but I'd make that another, separate issue: this one here is about a component type grouping.

[ThunderFrame]

FWIW - unlike Goto Definition in VBE, RD's Find Symbol and Goto Implementation should also take you to controls on forms, and ultimately controls on document modules.

[retailcoder]

@ThunderFrame not currently though. Needs an issue 😉

[bclothier]

IMPOV, if we implement the search bar as described in issue #3329, there's less need to want grouping by component type, as this would cater to more scenarios than give us 3-4 folders that don't try to group functionalities. At very least, we should fix the sorting for CE to use same order as OE does because as I pointed out, CE has the document modules in the middle of the list, whereas in OE, it's in the first folder.

[ghost]

Improvements to CE's sorting functionality will be landing RSN... Grouping by type should work properly. :)

[daFreeMan]

@retailcoder - I have to say this search box is rather nifty.. but correct me if I'm wrong, that's an Access feature, not a VBE feature.

You are absolutely correct, that is an Access feature. You don't ever need to open the IDE to take advantage of that feature. And I've seen people write "Access Macros" that are not VBA, and they use that feature.

[mansellan]

OK, so as the new guy here, here's my new "new user experience":

When I launched RD for the very first time, I obviously noticed the striking similarity between PE and CE. However, the minor differences made me wonder if they were surfacing the exact same thing or not. With the same top-level folders, I would have thought "Oh, cool! This is just a prettier PE", and closed PE for the new shiny. With the differences though, I erred on the side of caution and left both open.

Totally understand the reluctance to make the 'wrong way' the default, but I think there's a way to square the circle.

IMHO, the optimal UX would involve:

1) Adding the top-level folders, and making them display by default 2) Adding the ability to add \ delete folders from the CE (note 1) 3) Adding the ability to drag \ drop code modules between folders in the CE (note 2)

1: I know that folders aren't 'real' at the moment. But is there some way we could make them more so? I'm thinking about having somewhere that RD could store project metadata - perhaps in a (hidden?) module that contains nothing but RD attributes?

2: This way, users could start with their familiar top-level folders then when they discover the new folder capability they can drag\drop to suit.

[bclothier]

FWIW: I disagree about displaying by default the component type. As @retailcoder points out, it's the wrong thing. Besides, though I did open the issue, I would much much rather see #3329 and #3332 implemented which will address the current gaps and help with encouraging the users to do the right thing.

With that, I'll close the issue.