Rename/Refresh: Code Explorer not updating correctly

[Nesavi]

This issue is probably related to #4056, #3468 and #3469.

Rubberduck version 2.2.6731.26856

Expected behaviour: Rubberduck renames a field in a class AND updates Code Explorer tree AND updates
references ie. on right-click "Open" Rubberduck takes you to the definition of said field.

Actual behaviour: Rubberdack renames a field in a class but does not update Code Explorer tree and does not update references.

Steps to reproduce error:

1. Create a new Excel-file.
2. Alt+F11 to go to VBA editor.
3. Create a class "TestClass" with the following content:
   Option Explicit
Public RenameMe As String
4. Create a named range in Sheet1 of the Excel-file, see attachment "NamedRange.jpg"
5. Back in the VBA-editor create a module "Module1" with the following content:
   Option Explicit
Public Sub ClearNamedRange()
[TestNamedRange].ClearContents
End Sub
6. Save and close Excel.
7. Re-open the Excel file just created and go to VBA-editor.
8. Open Rubberduck -> Code Explorer
9. Rename "RenameMe" -> "Renamed"
10. "RenameMe" still appears in the Code Explorer tree.
11. Shift the line in which "Renamed" is defined one down and define a new variable "private Id As Long".
12. Refresh in "Code Explorer" and nothing happens.

The error seems to be related to the code reference to the named range "TestNamedRange". Indeed, remove the
reference in "Module1" and the treeview in "Code Explorer" updates correctly. That is:

1. In the VBA-editor in "Module1" delete the sub "ClearNamedRange".
2. Save, close and re-open the Excel-file.
3. Renaming now works as expected.

Cause of error:

As far as I have been able to figure out the error shows up when handling changes in state in the method
"private void HandleStateChanged(object sender, ParserStateEventArgs e)" defined in the class
"CodeExplorerViewModel". This method executes the following code:

var userDeclarations = _state.DeclarationFinder.AllUserDeclarations
.GroupBy(declaration => declaration.ProjectId)
.ToList();

if (userDeclarations.Any(
grouping => grouping.All(declaration => declaration.DeclarationType != DeclarationType.Project)))
{
return;
}

On the the first execution of the above code, the GroupBy-statement generates exactly one group, but in
subsequent executions it generates two groups, one containing only the named range in question. This
causes the method to return without updating the nodes of the tree.

Attached are also to logs produced in TRACE-mode, one with the reference to the named range in place and one where the reference has been deleted.

Do let me know if the description above is not satisfactory and I will elaborate as best I can.

RubberduckLog After Removing Reference To Named Range.txt
RubberduckLog With Reference to Named Range.txt

[retailcoder]

Thanks for the detailed report!

[TestNamedRange].ClearContents square bracket notation in a class module is probably a bad idea though: an explicitly qualified Range member call would be less bug-prone, since there's no way to tell what worksheet the expression will be evaluated against.

Square-bracketed expressions are evaluated not by VBA, but by the host application (EXCEL.EXE) at run-time, so you don't get intellisense for further member calls, and VBA will happily compile any typos, regardless of Option Explicit.

That said I have a repro with the .3310 prerelease build (for some reason .3347 is refusing to load referenced type libraries on my laptop). The code explorer's viewmodel state doesn't reflect the parser state, and refuses to acknowledge even the existence of a new module, let alone a new variable. Parser state seems fine though, after a reparse the context status bar behaves as expected:

Note to self: need to fix that broken resource reference #Rename in the bottom panel...

[Greedquest]

Incidentally, I believe my experiences in #4135 and #3704 are also down to this [a1:b5] bug. As well as Code Explorer not updating, the Host-specific bracketed expression is only evaluated at runtime inspection also hangs around in Code Inspections even after the offending statement has been removed.