Вопросы Теги

Удалите пространство имен или имя класса из VB.Net при использовании в VBA [дубликат]

Попробуйте сделать это: 

 awk -v n=3 '/^category/{l++} (l==n){print}' file.txt

Или еще cryptic: 

awk -v n=3 '/^category/{l++} l==n' file.txt

Если ваш файл большой: 

awk -v n=3 '/^category/{l++} l>n{exit} l==n' file.txt
7
задан 10 July 2013 в 12:32
поделиться

2 ответа

Ответ - нет: есть встроенная функция VBE, которая распознает ссылки, добавленные в проект, и создает псевдонимы во время выполнения (время выполнения VBE), если нет коллизий имен

. В случае конфликтов имен в вашем реестре все . точки будут заменяться символами подчеркивания _.

& raquo; ProgId 's & nbsp; (Programmatic Identifiers)

В COM он используется только в позднем связывании. Вот как вы делаете вызов для создания нового объекта 

Dim myObj = CreateObject("TestNamespace.Test")

& raquo; EarlyBinding и LateBinding

В раннем связывании вы указываете тип создаваемого объекта с помощью ключевого слова new. Имя вашего объекта должно появиться в Intellisense VBA. Это не имеет никакого отношения к ProgId. Чтобы получить фактическое пространство имен, используемое для вашего типа объекта, откройте Object Explorer F2 и найдите его там

В этой статье объясните, где имена взяты из раздела Early Binding используют ту же ссылку для . Когда использовать позднюю привязку

для раздела программных идентификаторов MSDN, см. this

3
ответ дан user 22 August 2018 в 19:47
поделиться

Интересный вопрос (постоянно используя их, но не думал о их точном значении). Определение оператора Imports (то же самое для using) довольно ясно: его единственная функция сокращает ссылки, удаляя соответствующие пространства имен. Таким образом, первый вопрос, задаваемый вопросом: имеет ли вообще VBA такую ​​вещь (пространства имен)? И ответ - нет, поскольку вы можете читать из нескольких источников; Примеры: Ссылка 1 Ссылка 2

Итак, после того, как не было найдено ни одной ссылки на любой оператор VBA, делающий что-то похожее на Imports / using и подтвердив, что VBA не рассматривает «структуру», оправдывающую их использование (пространства имен), я думаю, что я могу сказать: нет, в VBA такого не происходит.

Кроме того, вы должны иметь в виду, что у него не было бы реальной применимости. Например: при преобразовании кода VB.NET, где Imports может использоваться, например: 

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

, код будет полностью изменен, так что результирующая строка не будет длинной: 

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

Я думаю, что это хорошая графическая причина, объясняющая, почему VBA не нуждается в таких вещах: VB.NET учитывает самые разные реалии, которые должны быть должным образом классифицированы (пространства имен); VBA учитывает гораздо меньшее количество ситуаций и, следовательно, может позволить себе не выполнять столь систематическую, давно названную классификацию.

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

Imports / using - простое сокращение имени, то есть вместо того, чтобы писать any.whatever2.whatever3 каждый раз, когда вы используете объект данного пространства имен в Module / Class вы добавляете в начале инструкцию Imports / using, которая в основном означает: «для всех членов пространства имен X просто забудьте обо всех заголовках bla, bla" ,

Я не говорю, что вы не можете эмулировать такое поведение; просто подчеркивая, что наличие встроенных функций для коротких имен имеет смысл в VB.NET, где имена могут стать очень длинными, но не так много в VBA.

3
ответ дан Community 22 August 2018 в 19:47
поделиться
  • 1
    Зачем вводить в заблуждение? И что унаследовано от пространств имен? Пространства имен - способ правильно классифицировать все; Наследование - это подход, используемый для ускорения определения данного объекта (например, взять всю информацию из этого другого объекта). Наследование не имеет ничего общего с импортом. – varocarbas 10 July 2013 в 13:17
  • 2
    В одной из ссылок, которые я предоставил, парень предлагает способ подражать пространствам имен. Я не говорю, что вы ничего не можете придумать; Я говорю, что он не слишком сильно использовал бы встроенную функциональность для коротких имен, когда самое длинное имя у вас состоит всего из двух слов. – varocarbas 10 July 2013 в 13:19
  • 3
    о, может быть, я был неясен с моим комментарием. Обратите внимание на встроенную функцию hidden в VBE, которая позволяет вам сказать ("Sheet1") вместо Application.ThisWorkbook.Sheets("Sheet1"). Теперь подумайте о том, как каждый элемент (правая часть точки) должен наследовать свой родительский класс (слева). Поскольку это встроенная функция, она запечатана и поэтому создает свои собственные классы, и участники никогда не позволят вам называть их подобным образом. Вам всегда нужно указать полный путь к вашим классам Class1.Class2.ClassNm, VBE не создаст пространство имен для вас. Помогло ли это понять мой первый комментарий? – user 10 July 2013 в 14:31
  • 4
    Да. С другой стороны, мое предположение (не задумываясь об этом) заключается в том, что эмуляция чего-то вроде наследования может быть действительно сложной (или невозможной). Но может быть возможно эмуляция короткого вызова вызова (например, использование именованных диапазонов при обращении к ячейкам Excel). В любом случае ... говоря, что (логическое) объяснение тому, что у меня нет встроенного способа сократить вызовы в VBA, не слишком длинный путь, звучит довольно разумно для меня. В основном, когда нет реальной невозможности для такой реализации (почему бы не использовать «Word» вместо «Word.Application»?). – varocarbas 10 July 2013 в 14:40
  • 5
    PS: VBA также имеет ту же функциональность, что и в VBE. Вы можете назвать диапазон («A1»), а рабочая книга и рабочий лист неявные. Это в основном то, что делает Импорт. VBA реализует эту опцию в этих условиях, потому что пути могут стать длинными. Он не реализует его вообще, потому что все остальные пути достаточно коротки. – varocarbas 10 July 2013 в 14:46
Другие вопросы по тегам:

Похожие вопросы: