Rubberduck: Code Explorer does not populate an empty Project

[ghost]

The Code Explorer window does not populate the CodeExplorerViewModel with a CodeExplorerProjectViewModel if the referenced VBProject does not contain any VBComponents.

Steps to reproduce:

1. Launch a clean instance of PowerPoint, then Rubberduck.
2. Do not parse the project.
3. Remove any empty modules.
4. Run a Parse.
5. Code Explorer will show no items in it's menu tree.
6. Add a empty module, reparse.
7. Code Explorer will show a Project -> Folder -> Module tree.
8. Remove the module, reparse.
9. Code Explorer will show a single Project item and the Folder and Module will be removed.

Expected Behavior:

1. Launch a clean instance of PowerPoint, then Rubberduck.
2. Do not parse the project
3. Remove any empty modules.
4. Parse
5. Code Explorer will show a single Project item without anything else.

[ghost]

It looks like maybe the DeclarationFinder isn't recording empty projects or isn't returning empty projects when CodeExplorerViewModel gets the collection of UserDeclarations...?

[retailcoder]

I think it's more of a bad assumption in the VM code; declarations are regrouped by project and module... Possibly we're not even looking at actual project declarations.

[ghost]

RubberduckParserState.RefreshProjects adds empty projects to it's collection.

The VM gets AllUserDeclarations from the DeclarationFinder. The project isn't in there (it's empty, whereas it should have at least the project in it.) Same results if I change it to AllDeclarations
-CodeExplorerViewModel.cs line 260

[MDoerner]

The problem here is how the declaration resolver and the ParseCoordinator work. The projects present in the VBE play no direct role in what gets processed. If there is no component, the ParseCoordinator neither parses nor resolves anything.

ProjectDeclarations are only created as a byproduct of generating module declarations in the declaration resolver. Whenever it cannot find the declaration for a project of a module it creates the corresponding module declaration.

So, fixing this issue would entail rewiring the parsing process regarding the treatment of projects.

[ThunderFrame]

An empty project still has references, but they aren't resolved, because nothing uses them?

[ghost]

At what level does the parsing process begin? Does it iterate though all the components?

Doesn't seem like it would be too much effort to iterate though all the projects and create declarations for them first. Does that sound like a viable strategy?