Поиск  Пользователи  Правила  Войти
Форумы "Планета Excel" » Курилка
Страницы: 1
RSS
Чем раннее связывание - отличается от позднего
 
#1
21.05.2018 01:29:47
Вопрос к специалистам.

Объясните своими - предельно простыми словами - чем раннее связывание - отличается от позднего ?
И зачем это связывание в экселе вообще нужно ?
 
 
 
#2
21.05.2018 02:01:58
а что Вас не устроило из того что Вы прочитали до этого вопроса о раннем и позднем связывании в инете?
раннее связывание - это точное определение  типа обьекта. это оптимизирует скорость работы компилятора и позволяет более рационально выделять память
Microsoft рекомендует использовать ранее связывание везде, где это возможно
раннее связывание позволяет компилятору понять Вы используете корректные свойства и методы обьекта еще на стадии проверки синтаксиса кода, а не в ходе его выполнения.
отдаленный аналог: Option Explicit
он заставляет программиста с самого начала представлять какие переменные и какого типа ему понадобятся.  
Программисты - это люди, решающие проблемы, о существовании которых Вы не подозревали, методами, которых Вы не понимаете!
 
 
 
#3
21.05.2018 02:07:52
Цитата
ttt480 написал:
зачем это связывание в экселе вообще нужно ?
Чтобы использовать внешние объекты - словарь, регулярные выражения, файловую систему, Ворд наконец.
Тема для курилки однозначно.
Все уже описано много раз: https://www.google.ru/search?q=раннее+связывание+и+позднее+связывание+vba
https://docs.microsoft.com/ru-ru/dotnet/visual-basic/programming-guide/language-features/early-late-binding/
http://wordexpert.ru/forum/viewtopic.php?id=1962
Изменено: Казанский - 21.05.2018 02:08:40
 
 
 
#4
21.05.2018 09:10:13
Писал COM.DLL c dual интерфейсом (раннее связывание и позднее), поэтому кратко,
Цитата
ttt480 написал:
предельно простыми словами
ранее связывание - компилятор/транслятор знает об объекте ДО компиляции/трансляции, т.е. вы можете посмотреть свойства и методы даже в процессе написания кода. Поэтому это связывание на 50% быстрее позднего (оценочно). При позднем связывании компилятор/транслятор ничего не знает о вашем объекте, и работает с ним в процессе выполнения кода (поэтому в отладчике не видно свойств и методов). Но для раннего связывания, что бы компилятор видел ваш объект, нужно его подключить в референсах проекта. Есть объекты, которые работают через раннее или позднее связывание, есть с двойным СОМ интерфейсом - dual.
«Бритва Оккама» или «Принцип Калашникова»?
 
 
 
#5
21.05.2018 10:05:02
А дальше посыплются вопросы: а что такое компиляция  и для чего транслятор :)
 
 
 
#6
21.05.2018 10:35:24
bedvit, а в чем преимущества позднего связывания ?
 
 
 
#7
21.05.2018 12:20:14
Цитата
ttt480 написал:
в чем преимущества позднего связывания ?
В поощрении лентяев, к каким себя отношу, которым лень определить переменные с которыми они работают.
По вопросам из тем форума, личку не читаю.
 
 
 
#8
21.05.2018 12:50:38
Цитата
vikttur написал: а что такое компиляция  и для чего транслятор
:D
Цитата
ttt480 написал: в чем преимущества позднего связывания ?
Более универсально, разрабатывалось в основном для использования в скриптовых языках (VBA считается таким языком), не нужно подключать библу в References, подключается сразу в коде
Код
Dim I As Object: Set I = CreateObject("ИмяБиблы")
Но есть и минусы, скорость, нет инфо о методах, используется только в ограниченном количестве языков (в основном скриптовые).
Можно посмотреть на примере (есть и ранее и позднее связывание).
Написал много, но потом удалил - ибо просили по простому, а здесь нужно немного понимать в (интерфейсы IUnknown, IDispatch, Dual(+COM Automation), таблица адресов методов, маршалинг и т.д. )
Матчасть под спойлером
Скрытый текст
Изменено: bedvit - 21.05.2018 16:59:03
«Бритва Оккама» или «Принцип Калашникова»?
 
 
 
#9
21.05.2018 12:51:18
Цитата
ttt480 написал:
а в чем преимущества позднего связывания ?
при раннем, как уже написали, надо прописывать референс проекта. При позднем - не надо :)
F1 творит чудеса
 
 
 
#10
21.05.2018 12:54:20
Цитата
БМВ написал:
В поощрении лентяев
не только. Если пишем код, в котором обращение идет к тому же Outlook, то при раннем связывании мы обязаны поставить галку в Tools -References. При этом связывание будет именно с нашей версией Outlook. У меня это будет Outlook.Application.16. И если я вышлю свой код кому-то, у кого хотя бы 2013 офис или еще меньше - то код еще при запуске выдаст ошибку компиляции, т.к. не найдет библиотеку Outlook16.
При позднем же связывании мы указываем только имя класса объекта("Outlook.Application") без указания версии и VBA постарается найти любую сборку. Т.е. будет работать и в 2013 и в 2016. Тут останется только писать код так, чтобы использовать только те свойства и методы, которые есть в обеих версиях.
Изменено: Дмитрий Щербаков - 21.05.2018 13:03:40 (опечатка)
Даже самый простой вопрос можно превратить в огромную проблему. Достаточно не уметь формулировать вопросы...
 
 
 
#11
21.05.2018 13:10:18
ttt480, соглашусь больше с bedvit'ом, и Дмитрием.
Рассказывать пользователю, какие менюшки нужно открыть и где галочку поставить/снять, чтобы ваш код заработал будет выглядеть, мягко говоря, очень странно… Программа должна просто работать. Позднее связывание намного более универсально для этого. Однако, в случаях, когда разработчик точно уверен, какие библиотеки стоят/подключены на компьютерах пользователей, правильнее и быстрее (по скорости работы макроса) будет раннее связывание.

Лично я практически всегда (для неродных экселю библиотек) стараюсь использовать именно позднее связывание, ввиду описанных выше нюансов. Бывало и такое, что при вылете с ошибкой xl "снимает галочки" некоторых подключенных библиотек. Для позднего связывания это неважно - само подключит, а вот раннее приведёт к вылету с ошибкой.
Изменено: Jack Famous - 21.05.2018 13:11:34
Во всех делах очень полезно периодически ставить знак вопроса к тому, что вы с давних пор считали не требующим доказательств (Бертран Рассел) ►Благодарности сюда◄
 
 
 
#12
21.05.2018 13:12:30
Дмитрий верно, столкнулся с этим, при переносе с одной версии Excel на другую (с разными операционками) + может быть не зарегестрирован СОМ в реестре и нет ссылки в референсах. Поэтому теперь в коде при раннем связывании обязательно снимаю галку в референсах в конце кода.
Код
ThisWorkbook.VBProject.References.AddFromGuid "{77D79CA3-15A0-4310-B8D8-0BCBE3F72D96}", 1, 0: Continue ' подключаем библу "BedvitCOM" в References - version(1.0) 
'Для раннего связывания сначала включаем в References библу, потом в конце кода отключаем. Для позднего связывания этого не нужно (см.ниже).
'Если BedvitCOM не оключать, могут быть ошибки в этом файле при отсутствии зарегестрированной BedvitCOM - выслали кому-то файл, или открыли из другого ПК и т.д., где не установлеена или не открыта надстройка BedvitXLL (которая автоматом распаковывает и регистрирует библиотеку BedvitCOM в реестре) или не зарегистрированна BedvitCOM вручную
ThisWorkbook.VBProject.References.Remove ThisWorkbook.VBProject.References("BedvitCOM") 'оключаем библу в References
«Бритва Оккама» или «Принцип Калашникова»?
 
 
 
#13
21.05.2018 13:20:36
Jack Famous, не обязательно рассказывать это пользователю (подключения при раннем связывании), можно все делать программно, см. мой пост выше.
«Бритва Оккама» или «Принцип Калашникова»?
 
 
 
#14
21.05.2018 13:21:07
Цитата
Дмитрий Щербаков написал:
Тут останется только писать код так, чтобы использовать только те свойства и методы, которые есть в обеих версиях.
Что-то все быстро так написали ответы и выложить не успеваешь, приходится переписывать, и что вообще добавить, наверное, нечего (при моем уровне), кроме того, что некоторые "лентяи" так об этом и не узнали бы в процессе своего творчества.
Но даже в рамках данного контекста надо просто помнить о скорости, если обращение к Вашей переменной применяется в коде более 10-ков тыс. раз., то вряд ли Вас за скорость поблагодарят Userы
Изменено: AAF - 21.05.2018 13:26:38
 
 
 
#15
21.05.2018 13:39:00
Цитата
AAF написал:
то вряд ли Вас за скорость поблагодарят Userы
ну это да. Но в противном случае, если код не будет работать вообще из-за ошибки раннего связывания с несуществующей библиотекой - то они тоже вряд ли рассыплются в комплиментах :)
Я считаю, что работающий медленно код лучше, чем вообще не работающий :)
Даже самый простой вопрос можно превратить в огромную проблему. Достаточно не уметь формулировать вопросы...
 
 
 
#16
21.05.2018 13:40:15
Цитата
Дмитрий Щербаков написал:
Я считаю, что работающий медленно код лучше, чем вообще не работающий
Безусловно!!!
Но, с предположительной точки зрения ТС, возможно, моя попытка сформировать такой вектор тяги может оказать положительное влияние в определенной ситуации.
Изменено: AAF - 21.05.2018 13:45:34
 
 
 
#17
21.05.2018 13:40:31
Цитата
bedvit написал:
можно все делать программно
видел пару раз такое. Полезный навык и хороший приём - спасибо!  :)
Во всех делах очень полезно периодически ставить знак вопроса к тому, что вы с давних пор считали не требующим доказательств (Бертран Рассел) ►Благодарности сюда◄
 
 
 
#18
21.05.2018 13:52:11
Цитата
Дмитрий Щербаков написал:
не только
Дмитрий, беcспорно. Правильнее было написать  "Например в поощрении лентяев"
По вопросам из тем форума, личку не читаю.
 
 
 
#19
21.05.2018 13:58:51
Цитата
БМВ написал:
"Например в поощрении лентяев"
Ну я думаю, что "лентяйский" код - это не крестовый поход за упрощение, а скорее костыль необходимый для сущности "быстрой" совместимости (ну и, конечно улучшению коммерциализации данного направления и всего что с ним связано)...
 
 
 
#20
21.05.2018 20:46:14
Теперь мне все стало ясно.

Мрак непонимания - окончательно рассеялся.
Спасибо за ответы.
 
 
 
#21
22.05.2018 01:27:30
ttt480, для того форумы и нужны  ;)  :D
Во всех делах очень полезно периодически ставить знак вопроса к тому, что вы с давних пор считали не требующим доказательств (Бертран Рассел) ►Благодарности сюда◄
 
 
 
#22
22.05.2018 17:53:38
Цитата
Дмитрий Щербаков написал:
работающий медленно код лучше, чем вообще не работающий
Это, конечно, только теория, но нельзя ли сначала попытаться сотворить раннее программно,
как писал bedvit, а при фейле — условной компиляцией перейти к позднему?
 
 
 
#23
22.05.2018 18:13:20
Можно. Более распространенная практика: отладка сложного макроса (макросов) с ранним связыванием, а затем замена типов переменных  для объектов из "прицепленных" библиотек на Object и "отцепка" библиотек.
Владимир
 
 
 
Страницы: 1
Наверх