VBA równoważne C# za pomocą VB.NET lub import/Tworzenie aliasów

Question

bazy odniesienia: Ten Code Conversions for VBA, Visual Basic .NET, and C#

Uwaga: już utworzony i zaimportowany *.dll, to pytanie jest oaliasy.

Powiedzmy, że programowa nazwa klasy Test jest TestNameSpace.Test

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

Teraz, powiedzmy rozwiązanie C# został uszczelniony i zebrane w *.dll a ja przedstawieniu go w VBE danego programu Excel. Uwaga: w tym momencie nie mogę zmodyfikować programowej nazwy tak, jakby *.dll nie została napisana przeze mnie.

Jest to VBA: Zamiast deklarowania zmiennej tak:

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

wolałbym to nazwać (wciąż w VBE)

Dim myTest As Test 
Set myText = new Test 

W języku C# byś zwykle mówi się:

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

Uwaga: Załóżmy, że istnieją bez nazw konflikty w projekcie

Pytanie VBA: Czy istnieje odpowiednik rozmowy VBA do C#using lub VB.NETimports aliasy?

Answer 1

Odpowiedź nie jest: nie ma wbudowaną funkcję, która rozpoznaje VBE odniesień dodane do projektu i tworzy aliasów przy starcie (wykonawczego vbe użytkownika), jeśli nie ma kolizji nazwa

W przypadku nazwy konflikty w rejestrze wszystkie kropki zostaną zastąpione kropkamiz _.

» ProgId jest   (Programmatic Identifiers)

COM, jest on stosowany jedynie w późnym wiążące. To, w jaki sposób wykonać połączenie, aby utworzyć nowy obiekt

Dim myObj = CreateObject("TestNamespace.Test") 

» EarlyBinding i LateBinding

Na początku wiązania można określić typ obiektu tworzonego za pomocą słowa kluczowego new. Nazwa twojego obiektu powinna pojawić się w intellisense VBA. Nie ma nic wspólnego z ProgId. Aby pobrać rzeczywiste nazw stosowany dla danego typu obiektów - otwarte Object ExplorerF2 i zlokalizować go tam

This article wyjaśnić, gdzie nazwy pochodzą w wczesnego wiązania Sekcja
używać tego samego link dla Kiedy używać późnego wiązania

dla sekcji MSDN Programowa Identifiers proszę zobaczyć this

Answer 2

Interesujące pytanie (ciągle ich używam, ale nigdy nie myślałem o ich dokładnym znaczeniu). definition of the Imports statement (to samo dla using) jest całkiem jasne: jego jedyną funkcją jest skracanie odwołań poprzez usunięcie odpowiednich przestrzeni nazw. Tak więc pierwsze pytanie, które należy zadać, brzmi: czy w ogóle VBA to coś (przestrzenie nazw)? Odpowiedź brzmi: nie, ponieważ możesz czytać z wielu źródeł; Przykłady: Link 1Link 2

Podsumowując, po nie znalazłszy jednego odniesienia do jakiegokolwiek oświadczenia VBA robi coś podobnego do Imports/using i potwierdziły, że VBA nie uważa „strukturę” uzasadniające ich użycie (nazw), myślę, że jestem w stanie powiedzieć: nie, nie ma czegoś takiego w VBA.

Dodatkowo należy pamiętać, że nie miałoby to rzeczywistego zastosowania. Na przykład: podczas konwersji kodu VB.NET, gdzie może być wykorzystany Imports, jak:

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

kod będzie całkowicie zmieniony, tak, że wynik nie będzie tak długo:

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

Myślę, że jest to dobry graficzny powód wyjaśniający, dlaczego VBA nie potrzebuje takich rzeczy: VB.NET kont dla wielu różnych rzeczywistości, które muszą być odpowiednio sklasyfikowane (przestrzenie nazw); VBA odpowiada za znacznie mniejszą liczbę sytuacji, a zatem może sobie pozwolić na nieprzeprowadzanie tak systematycznej, długotrwałej klasyfikacji.

-------------------------- WYJAŚNIENIE

Imports/using jest tylko nazwa skracanie, czyli zamiast piśmie what.whatever2.whatever3 za każdym razem, gdy używasz obiektu o podanej nazwie w Module/Class, dodajesz na początku instrukcję Imports/using, która zasadniczo oznacza: "dla wszystkich członków przestrzeni nazw X, zapomnij o wszystkie nagłówki bla, bla ".

Nie mówię, że nie można naśladować tego rodzaju zachowania; Podkreślenie, że posiadanie wbudowanej funkcjonalności dla krótkich nazw ma sens w VB.NET, gdzie nazwy mogą stać się naprawdę długie, ale nie tak bardzo w VBA.