Code explorer does not automatically track "active" codepane

[Dob4115]

When moving between codepanes during debug, I lose track of which one I am in because code explorer does not automatically highlight the active module (unlike the VBE). (Yes, the window titlebar updates, but sometimes I forget which project I am in... memory being what it is!)

Double clicking on a module is not a problem (though it would be nice to have it remember the last position a la #4700) since I just clicked on it. This is only really a problem for me during debugging.

I dont know if this discussion speaks to how hard it would be to figure out which codepane is active: #2671.

[retailcoder]

Oh, not just for debugging... I want that all the tiime!

Thanks for taking the time to open an issue for this!

[MDoerner]

Although finding the currently active code pane is really simple using the VBE API, tracking changes is not. The API simply does not expose events for the change.

However, we might be able do track the active code pane by intercepting window messages, propably the focus change message for the code pane. But that needs some investigation.

We do something similar already to enable the auto completion feature. In that case, we intercept the keystrokes and have to figure out which code pane they belong to.

[MDoerner]

Thinking a bit more about this, we already track the selection for the Rubberduck command bar. So, we should be able to use the SelectionChangedService to provide the information needed.

[Dob4115]

Do you think it would be possible to highlight the function/sub/method? RD has so much more capability than the native explorer, it would be nice to keep the experience consistent.

I also understand that the update rate/overhead required to keep the explorer in sync at the function level might be too great. Especially if you have multiple codepanes and are actively clicking between them.

Don't know. Just furthering the idea a little.

[retailcoder]

Do you think it would be possible to highlight the function/sub/method?

Yup. Using the SelectionChangedService like Max suggested, we could even select treeview nodes for enum members and module variables if that's what's selected in the current code pane. I think it's a great idea!

[Dob4115]

Continuing to think this through a little bit... what would happen during parsing (my other ticket!)?

Assume you could populate the code explorer with all the projects/modules super-quick so people could at least navigate around while the parsing finishes. RD would have to know to only highlight the module, not look for the function, etc. I assume this would just be choosing the closest node in a tree, but it's still part of the consideration.

I dont want this to slow down the ability to use the explorer while parsing completes!

[bclothier]

Ref #3697

[MDoerner]

I do not want to spoil the enthusiasm here, but I have my concerns with selecting the member. The primary problem I see is that once the user starts to edit the module, we have no idea where members start and end until the next reparse.

[retailcoder]

@MDoerner you're right (@bclothier brought it up in chat earlier) - member-level is a bit of a can of worms with regards to stale parse trees.

[bclothier]

FWIW, a stopgap solution would be to allow selection of procedures, which can be trivially found using VBIDE API. The declaration level variables and other elements would have to be ignored (placing the user at the top of the declarations section).

The ideal solution likely requires reducing the granularity of the parsing level from module to procedure which may enable real-time parsing, which is not possible until we solve other problems (e.g. creating our custom code panes).

[MDoerner]

If we really consider going to a selection on the member level, can this please be a separate enhancement issue?

[Dob4115]

Agreed. The most important thing is to indicate the module and that will allow a first pass at the mechanics required to get the feature right, such as opening the correct path in the tree GUI, scrolling the tree to bring the active module into view, etc.

[ChrisBrackett]

Oh, not just for debugging... I want that all the tiime!

Thanks for taking the time to open an issue for this!

Yes, thanks @Dob4115! This has the potential to enhance the experience for -EVERY- RubberDuck user! I would love it if the Code Explorer could show:

1. The active module
2. The active procedure (which i assume could auto-display the '@Description attribute if in a procedure or the '@ModuleDescription if not)

Regarding selection at the member level, any chance of doing this in real time or semi-real time? Could RD run a sparse parse of the active code pane in the background to identify start and end line numbers for each procedure? Code changes during the parse shouldn't matter if RD rechecks the code pane at time intervals or on whichever events make most sense.

[retailcoder]

Side note, the RD commandbar means to address part of the concerns here: its content is selection-dependent and does display whatever docstrings exist for the selected member/module.

[ChrisBrackett]

Another side note, I just discovered what that blue left/right-arrow-button on the Code Explorer does. I didn't realize this feature is already available albeit in manual form. Is there a keyboard shortcut for "Sync with code pane"?

[retailcoder]

@CHR-IS-B been a while since we added new kb shortcuts.... Very good idea!