Rubberduck: Feature Request: "locate in code explorer"

[daFreeMan]

This would sync the CE to the current procedure in the Code Pane.

I know that the RD toolbar shows me the ModuleName.ProcedureName, but sometimes it's handy to be able to visualize it in the CE, as well.

I _can_ go manually find my way to it, but computers are supposed to do the drudgery for us, right?

[retailcoder]

Definitely a good feature to have - especially in larger projects, and especially with the modules being depicted in a folder hierarchy. I'm 100% behind this one.

[daFreeMan]

In the meantime, would it be easy (easier) to update the RD toolbar to show

Folder.Hierarchy: ModuleName.ProcedureName

I looked at the tool bar to try to identify where I was, then realized that I didn't know where the specified module was to be found. (Existing project, partially moved to a folder hierarchy)

[retailcoder]

Thing is, the toolbar doesn't have much room for it. We need an actual freakin' status bar!

[daFreeMan]

To make the code more efficient than attempting to hook every cursor key movement to keep the CE constantly in sync, enable the currently disabled toolbar button that displays the current ModuleName.ProcedureName so that clicking it syncs the CE to the Code Pane.

_Do not mock my Logitech Trackman writing - I did that with my thumb!_

[retailcoder]

That's a great idea - the irony being, it's hooks that track every cursor key movement that keep that "context status bar" in sync ;-)

[ThunderFrame]

like this?

[retailcoder]

I wouldn't make it sync the Code Explorer (i.e. trigger a reparse - there's the refresh button for that already), rather just select the corresponding node in the CE treeview.

That said, I'm not entirely sold on the idea of making that label clickable; from a UX perspective, it's not very discoverable (and we already have a number of UX/discoverability issues), I'd much rather have a Navigate -> Locate in Code Explorer command button instead.

[daFreeMan]

@ThunderFrame Yes, exactly like that!

@retailcoder I get your points.
A) sync may not be the best word for it, Locate is fine by me
B) If you add the button to the RD tool bar, I'm 100% OK with it. If it's buried under a menu or two or three, even if it's on the right-click, that's way too many clicks to get there. If there's a hot-key for it, that certainly minimizes the pain. (Is Ctrl-L used for anything?)

[retailcoder]

I'd use Alt+Shift+L to mimick R# hotkeys, but hotkeys can easily be configured in the settings window. But yeah, there's definitely going to be a hotkey for it.

[ThunderFrame]

I meant Sync as in make Code Explorer context the same as the CodePane/Designer context.

From a UX persepctive, maybe take a cue from VS and put the Sync button in Code Explorer?

As per VS:

[retailcoder]

Huh, I've never noticed/used that!

[PeterMTaylor]

Someone got to learn something somewhere...

[retailcoder]

The thing with the Solution Explorer is that it navigates with a single click (on selection), so it's actually pretty hard (AFAICT, downright impossible) to select a node in the treeview and then not have the corresponding code in the editor, so that "sync" feature essentially boils down to "select the node for the active document".

Fun fact: selecting a member node in the treeview navigates to that member, but selecting a member and then "syncing" doesn't. R#'s locate in solution explorer doesn't go to member level either. Perhaps Rubberduck's could?

So, I think the feature is taking shape:

• SyncCodeExplorerCommand would be the command
• SyncCodeExplorerCommandMenuItem would be under the NavigateParentMenu
• I'd personally like to have Alt+Shift+L for its hotkey
• The Code Explorer toolstrip can have a button that runs that command
• The command needs to be disabled when:
  
  
  
  • There is no active codepane
  
  
  • The Code Explorer doesn't have a node for the active module
  
  

If we have a node for the module, but not for the member that's selected, then we activate the module node. If we do have a node for the member, then we activate that node.

[retailcoder]

Makes me wonder... the Code Explorer should be able to have at least module-level nodes for everything in the project without having to wait for even the initial parse.

[rkapka]

Does it make sense to include a menu item for this command? Running it will have to open the Code Explorer after syncing, otherwise the user won't see any effect. When the CE is open, it makes more sense to fire the command using its button. So essentially the menu item makes sense only when the CE is not open.

Furthermore, when someone discovers the menu item first, they may not look for an alternative in the CE, which is the preferred way of syncing, I think.

[retailcoder]

@rkapka agreed, the command needs to bring up the CE if it's not shown. IMO a menu item absolutely makes sense (that's how I discovered the corresponding command in R# :smile: ) - having a hotkey for it wouldn't hurt either (Alt+Shift+L? ...whatever)

[rkapka]

Yup, there should be a menu item. I changed my mind 😁

[jhiston]

Can I add a UX thought? The active code pane being 'out-of-sync' with the Code explorer seems to be an issue for me mostly when using VBE's built in "Definition" right-click menu or when debugging - e.g. a compile error is found or (maybe? on following..... not sure...) a break point or unhandled error is hit. VBA stops at the offending line, but the Code Explorer may still be reflecting the previous state (whatever was in active code pane before the break).

The Number 1 place my eyes go to when the break happens to figure out where the heck in the code I now am is...…. the code explorer. Has been source of much confusion over the years.....

So all that to get to the thought..... once the functionality is in place, it would be pretty nice addition if the 'syncing' code could be automatically triggered by the debugger dumping you into a new active code pane so that the code explorer is also helping to identify where in the code one just found oneself (the whole 'orientation' problem)