7

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?

2 Answers2

3

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.

Community
  • 1
  • 1
varocarbas
  • 12,354
  • 4
  • 26
  • 37
  • Why misleading? And what has inheritance to do with namespaces? Namespaces is a way to classify everything properly; inheritance is an approach used to speed up the definition of a given object (e.g., take all the information from this other object). Inheritance does nothing to do with Imports. – varocarbas Jul 10 '13 at 12:17
  • In one of the links I provided, the guy is proposing a way to emulate namespaces. I am not saying that you cannot come up with something; I am saying that it wouldn't have made too much sense implementing an in-built functionality to short names when the longest name you have consists in just two words. – varocarbas Jul 10 '13 at 12:19
  • 1
    oh maybe I was unclear with my comment. Notice a *hidden* built-in feature in VBE that allows you to say `("Sheet1")` instead of `Application.ThisWorkbook.Sheets("Sheet1")`. Now think about how every element(right side of dot) must inherit from its parent class(left side). Since this is a built in feature, it is sealed and therefore creating your own classes and members will not ever allow you to call them in a similar manner. You always have to specify a full path to your classes Class1.Class2.ClassNm,VBE will not create a namespace for you. does this help understand my 1st comment? –  Jul 10 '13 at 13:31
  • Yes. On the other hand, my assumption (without having thought much about it) is that emulating something like inheritance might be really difficult (or impossible). But emulating a shorted calling proceeding might be possible (like, for example, using named ranges when referring to Excel cells). Anyway... saying that the (logical) explanation to not having an in-built way to shorten the calls in VBA is not having too long paths, sounds pretty reasonable to me. Mainly when there is no true impossibility for such an implementation (why not allowing to use "Word" instead of "Word.Application"?). – varocarbas Jul 10 '13 at 13:40
  • PS: VBA has also the same functionality you refer in VBE. You can call range("A1") and the workbook and the worksheet are implicit. This is basically what Imports does. VBA implements this option under these conditions because the paths can become long. It does not implement it generally because all the other paths are short enough. – varocarbas Jul 10 '13 at 13:46
3

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