> **What**
This inspection would aid in alerting users. Users might not know that they can and sometimes must qualify their member calls.
- Severity: Suggestion

**Why**
Without knowing how to fully qualify enum members, adding another enum which contains the same member results in an error. Depending on the coders level of understanding they might not know how to resolve it. When this first occurred to me I didn't know the cause and subsequent resolution.

**Example without naming confl

> Note that there can be cases where the resolution may compile but may not be desirable.

Example:

_Module1_
```
Public Enum Baz
Bar = 1
End Enum
```

_Module2_
```
Private Enum Bizz
Bar = 2
End Enum

Public Sub WhatIsBar
Debug.Print Bar 'Prints 2
End Sub
```

_Module3_
```
Public Sub WhatIsBar
Debug.Print Bar 'Prints 1
End Sub
```

> Addendum: It does not appear that Rubberduck will correctly resolve the enum reference if the enum is not in the same module. In this case, it used a class's enum even though it should be resolving to the `Module1`'s enum.



![image](https://user-images.githubusercontent

> Addendum: It does not appear that Rubberduck will correctly resolve the enum reference if the enum is not in the same module. In this case, it used a class's enum even though it should be resolving to the `Module1`'s enum.

If it's in same module, then Rubberduck is able to resolve it. The problem seems to be that when it's in other module, it needs to give `Module1` higher priority over `Class1`, especially considering that a class (by default) is not globally accessible anyway.

![image