> This very much seems to be an issue with the resolution of enumerations in class modules. They are a bit strange in VBA since they actually work like enumerations in procedural modules, i.e. the scoping is different from that for everything else in class modules.

I will have a look into this.

> Could you give a code example of what exactly you mean by _used as parameters or as default values for method parameters_? With the interpretations I could come up with, I do not get any result for `UndeclaredVariableInspection`.

One more question: do I understand correctly that the enumeration is a public enumeration in another class module in the same project?

> This will be a bit tricky to fix. The escaping happens in the invocation of `VBComponent.Export`.
It seems as if we have to fight the VBE API again.

> This will be a bit tricky to fix. The escaping happens in the invocation of `VBComponent.Export`.
It seems as if we have to fight the VBE API again.

> I have investigated this. The error is not in our code, but in the COM interop library or even the VBE API itself.

The problem is that string literals do not properly round-trip when exporting an imported component. In the reexported file, backslashes in front of most other characters are missing. Exceptions seem to be the backslash itself, `r` and `n`.

Since there does not seem to be a way to round-trip a single backslash followed by most characters, I think we will not be able to fix

> Closes #5336

The problem is that expressions prefer to resolve built-in type names as built-in types in favor of simple name expressions in order to be able to distinguish them. Unfortunately, VBA allows to name declarations like built-in types.

To fix this, whenever the default expression binding context encounters a built-in type, it first tries to bind it as a simple name. It tries to resolve it and if that is successful, it returns the binding. Otherwise, it falls back to the built-i

> Incompatibility might be solvable with a future version of .Net.
The only other practical option to achieve compatibility is probably to use a COM-shim, which will be obsolete in future version of .Net.

So, this is deferred for now.

> the incompatibility with the non-standard interop library might be solvable with a future version of .Net.
The only other practical option to achieve compatibility is probably to use a COM-shim, which will be obsolete in future version of .Net.

So, this is deferred for now.