VBA equivalent to C# using or VB.NET imports / cre

问题:

Base Reference: Ten Code Conversions for VBA, Visual Basic .NET, and C#

Note: I have already created and imported a *.dll, this question is about aliases.

Let's say the programmatic name of a Test class is TestNameSpace.Test

[ProgId("TestNamespace.Test")]
public class Test ...

Now, say a C# solution has been sealed and compiled into a *.dll and I'm referencing it in a Excel's VBE. Note: at this point I cannot modify the programmatic name as if the *.dll wasn't written by me.

This is in VBA : Instead of declaring a variable like this:

Dim myTest As TestNameSpace.Test
Set myTest = new TestNameSpace.Test

I'd prefer to call it (still in VBE)

Dim myTest As Test
Set myText = new Test

In C# you would normally say

using newNameForTest = TestNamespace.Test;
newNameForTest myTest = new NewNameForTest;

Note: Assume there are no namespace conflicts in the VBA project

Question: is there an equivalent call in VBA to C# using or VB.NET imports aliases?

回答1:

Interesting question (constantly using them but never thought about their exact meaning). The definition of the Imports statement (same for using) is pretty clear: its only function is shortening the references by removing the corresponding namespaces. Thus, the first question to ask is: has VBA such a thing (namespaces) at all? And the answer is no, as you can read from multiple sources; examples: Link 1 Link 2

In summary, after not having found a single reference to any VBA statement doing something similar to Imports/using and having confirmed that VBA does not consider the "structure" justifying their use (namespaces), I think that I am in a position to say: no, there is not such a thing in VBA.

Additionally you should bear in mind that it wouldn't have any real applicability. For example: when converting a VB.NET code where Imports might be used, like:

Imports Microsoft.Office.Interop.Word
...
Dim wdApp As Application

the code would be changed completely, such that the resulting string will not be so long:

Dim wdApp As Word.Application ' Prefacing the library's display name.

I think that this is a good graphical reason explaining why VBA does not need to have this kind of things: VB.NET accounts for a wide variety of realities which have to be properly classified (namespaces); VBA accounts for a much smaller number of situations and thus can afford to not perform a so systematic, long-named classification.

-------------------------- CLARIFICATION

Imports/using is a mere name shortening, that is, instead of writing whatever.whatever2.whatever3 every time you use an object of the given namespace in a Module/ Class, you add an Imports/using statement at the start which, basically, means: "for all the members of the namespace X, just forget about all the heading bla, bla".

I am not saying that you cannot emulate this kind of behaviour; just highlighting that having an in-built functionality to short names makes sense in VB.NET, where the names can become really long, but not so much in VBA.

回答2:

The answer is no: there is a built-in VBE feature that recognizes the references added to a project and creates aliases at run-time(VBE's runtime) if there are no name collisions

In case of name conflicts in your registry all . dots will be replaces with _ underscores.

» ProgId's   (Programmatic Identifiers)

In COM, it is only used in late-binding. It's how you make a call to create a new object

Dim myObj = CreateObject("TestNamespace.Test")

» EarlyBinding and LateBinding

In early binding you specify the type of object you are creating by using the new keyword. The name of you object should pop up with the VBA's intellisense. It has nothing to do with the ProgId. To retrieve the actual namespace used for your object type - open Object Explorer F2 and locate it there

This article explain where the names come from in Early Binding Section
use the same link for When to use late binding

for MSDN Programmatic Identifiers section please see this