Comments 34
Для построения сложных макросов или редактирования записанных, используется интегрированная в приложение среда разработки (IDE - Integrated Development Environment ). IDE устарела, но до сих пор предоставляет все необходимые базовые возможности по разработке и отладке.
Базовые? Эта IDE до сих пор является лучшей среди всех IDE для макросов присутствующих среди всех офисных пакетов!!! Особенно по сравнению с Р7 (он же OnlyOffice). Кроме того из-за того что разработчики офисного ПО (за искл. Libre/OnlyOffice, а так же их форков, и полумифического VBA в WPS Office и то только в платной версии и то только под винду) блокируют обращение к диску, а в некоторых случаях даже к системному времени (МойОфис привет). Из-за чего без использования внешних языков программирования невозможно создавать/править файлы макросами, что резко сужает возможности малой автоматизации и, как следствие, приведет к падению индивидуальной эффективности сотрудников, основанной на наработках прошлого. Для многих это будет означать (в случае импортозамещения ПО на рабочем месте с 01.01.2025, а местами уже сейчас) проблемы, как следствие возрастание рисков для организаций - работодателей.
Различия между языками программирования (VBA и JavaScript) потребуют наличия специалистов, хорошо разбирающихся в особенностях программирования макросов на VBA в MS Office и JavaScript в Р7-Офис при переходе между офисными пакетами. Тем не менее, для большинства задач такой процесс возможен, хотя и с указанными выше оговорками и ограничениями.
только полное переписывание кода c выносом его за пределы офисного пакета программ, например python/php/Lazarus/java/и т.д. и т.п., или замена MS Office на Libre/OnlyOffice, в случае если принципиально офисное ПО из реестра, то использование форка AlterOffice, который в реестре есть.
Libre/OnlyOffice
наверное имелось ввиду Libre/OpenOffice ? а то вы сами себе противоречите в эмоциях =)
в случае импортозамещения ПО на рабочем месте с 01.01.2025,
Это точно? Я просто смотрю в вакансиях Ростелекома и других около-государственных контор встречаются вакансии на спецов по MS Office+VBA.
Это точно? Я просто смотрю в вакансиях Ростелекома и других около-государственных контор встречаются вакансии на спецов по MS Office+VBA.
Указ Президента Российской Федерации от 30.03.2022 № 166
Защищать должны КИИ на каких то технологических площадках или где хранятся данные представляющие ГосТайну? Или даже в бухгалтерии ЖЭКа нужно импортозамещаться?
Я просто смотрю в вакансиях Ростелекома и других около-государственных контор встречаются вакансии на спецов по MS Office+VBA.
Одна из таких вакансий: то ли они не знают что в январе за MS Office в работе можно забыть?
Защищать должны КИИ на каких то технологических площадках или где хранятся данные представляющие ГосТайну? Или даже в бухгалтерии ЖЭКа нужно импортозамещаться?
Если организация/фирма/предприятие относится к КИИ, то иностранное ПО должно быть полностью замещено на отечественное или "отечественное", главное что бы оно было в реестре отечественного ПО.
При этом написано в указе, что запрещено использовать такое ПО на объектах КИИ, это косвенно налагает ограничения и на Подрядчиков, которые будут выполнять такие работы.
Одна из таких вакансий: то ли они не знают что в январе за MS Office в работе можно забыть?
Есть Указ, т.е. нормативный акт, но он не будет работать пока за него не начнут спрашивать. И так с любым Законом или нормативным актом.
Возможно, для 90% сотрудников таких компаний импортозаместят MS Office. Но для оставшихся 10% - будет доступен MS Office, так как во многих крупных компаниях до сих пор имеются инструменты на VBA, разработанные много лет назад, но до сих пор вполне успешно решающие некий круг задач.
Особенностью использования VBA в Microsoft Office является то, что макросы не могут использоваться отдельно, вне документов. Для своего использования макрос должен быть сохранён в составе документа, и для повторного использования он должен быть открыт в редакторе.
Если требуется независимая от документов дополнительная функциональность, следует создавать расширение (add-in) и инсталлировать его с помощью средств офиса.
Мне кажется, забыли про Personal Macro Workbook, который и используется, когда "требуется независимая от документов дополнительная функциональность" на VBA.
Еще лучше - один ReadOnly-файл "надстройки" *.xlam, расшаренный по сети LAN и подключенный на всех Excel/Calc у пользователей. Это по сути сетевая "корпоративная" библиотека макросов, в которой может быть автоматизировано большое число бизнес-процессов, не привлекая внимания СБ, IT и санитаров.
VBA-разработчики неспешно правят *.xlam (напрямую или правят свой и обновляют файл с заменой и восст. реквизита ReadOnly), а другие пользователи - незаметно для себя читают его при каждом открытии Excel/Calc. Это CI/СD.
Еще правильнее развернуть локальный Gitlab и собирать *.xlam из *.bas-файлов (исходных кодов) с автотестами.
Поясню за OpenOffice|LibreOffice Calc: сам он не поддерживает механизм "надстроек", но прекрасно читает макросы из XLAM-файлов (ведь это обычные xlsm-файлы с другим расширением). Совместимость VBA-кода для Calc - высокая, ~80%.
Если при работе макрорекордера не суетиться и избегать записи неподдерживаемых в Calc VBA-методов - делать кросс-офисные макроcы можно с прежней скоростью: очень быстро. По сравнению с классической разработкой - мгновенно.
Хотя язык VBA и не является полноценным объектно-ориентированным,
Вообще-то является. Есть возможность создавать классы - Class Module, в них определять Функции (Function), Процедуры(Sub), Свойства (Property Get, Set, Let), переменные класса, и даже события (Events) и потом использовать это в своем коде.
Особенностью использования VBA в Microsoft Office является то, что макросы не могут использоваться отдельно, вне документов.
При небольшой доработке могут - это называется VBScript, который имеет еще дополнительные объекты по сравнению с VBA вроде словаря, регулярок и т.д. VBScript-у для выполнения скриптов под Ms Office конечное же нужен будет установленный Ms Office на компе.
Это не ООП в полном смысле этой парадигмы. Просто более удобный способ описания модулей в виде обобщенной структуры данных и функция, для обращения к ним через префикс. Но в целом, так же можно обращаться по имени модуля, и получим почти те же самые "классы"
Но в целом, так же можно обращаться по имени модуля, и получим почти те же самые "классы"
Что за пургу вы несёте, не побоюсь этого слова? Тут ниже я распинался расписывать аргументацию об отличие VBA от VBS, но судя по таким заявлением, у вас знаний о технологии на уровне «слышал звон».
Абсолютное ахинею вы написали.
Модули это просто способ сгруппировать процедуры и переменные по организаицонному принципу, и сделать некий скоуп, чтобы внутри него можно было сделать Public сущности, видимые внешнему миру и Private сущности, которые доступны только внутри модуля.
Всё. Время жизни модульных переменных соответствует времени жизни проекта.
Классы же — это натурально классы как в любых других языках программирования. Их можно инстанциировать, то есть порождать экземпляры класса. У каждого класса будет своя копия всех его переменных полей/членов. Можно создать 10, а можно создать 1000 экземпляров одного класса. У разных классов будут разные значения полей, разные внутренние состояния. А модули это просто модули. Нельзя создать экземпляр модуля или несколько экземпляров модуля.
У классов, а точнее экземпляров классов есть время жизни, основанное на подсчёте ссылок. Объекты (экземпляры классов) уничтожаются, когда счётчик ссылок достигает значения 0. О модулей нет никаких счётчиков ссылок и никакого уничтожения.
Экземпляры классов «адресуются» по ссылками. Может быть один объект, но 10 разных ссылок на него из разных мест. Ссылки на объекты можно передавать в другие DLL (написанные на других языках). Благодаря OLE ссылки на объекты можно передавать в другие процессы или даже на другие компьюреры — обращения к членам таких объектов по таким ссылкам будут работать через RPC-механизмы.
Ссылку на COM-класс написанный на VB или VBA можно передать в любой другой язык, поддерживающий технологию COM (явно или неявно, как C или C++) и из любого другого языка дёргать методы или обращаться к полям. И наоборот, с объектом, реализованным на совершенно другом языке, можно работать в VB/VBA, если объект импементирован по правилам COM. Модули так не могут. Нет никаких ссылок на модулей или на экземпляры модулей, потому что не бывает экземпляров модулей.
Классы в VB/VBA могут поддерживать интерфейсы, то есть, в частности, могут поддерживать множество интерфейсов. И не обязательно это должны быть интерфейсы, определённые в том же VB/VBA-проекте, это могут быть совершенно сторонние COM-интерфейсы. Модули не могут поддерживать интерфейсы, потому что модули это не объектные сущности.
Классы в VB/VBA могут быть источниками событий, на которые другие объекты могут подписываться, причём подписка на события всегда может быть множественной: на одно событие одного объекта-источников может быть целая гора listener-ов. О модулей нет никаких событий, модули не могут генерировать события.
И после этого вы говорите, что классы это те модули? Алё, очнитесь.
Класс:
' Класс CSample
Public Foo As StringКакой-то код где-то:
Dim jaa as CSample
Dim bau as CSample
Dim sir as CSample
Set jaa = New CSample
Set bau = New CSample
Set sir = New CSample
jaa.Foo = "Крокодил"
bau.Foo = "Телевизор"
sir.Foo = "Мурманский полуостров"
' Сейчас существует три объекта, три экземпляра класса
' и каждого своё собственное значение свойства «Foo»
Set bau = sir
'
' А теперь осталось в живых только два объекта:
' «Крокодил» (на него есть 1 ссылка) и
' «Мурманский полуостров»' (на него теперь есть 2 ссылки)
' тогда как «Телевизор» только что уничтожился, так как не него
' не осталось ни одной живой ссылки.
'
И что тут общего с модулями? Как после этого сниппета можно утверждать, что классы и модули это одно и то же?
При небольшой доработке могут - это называется VBScript, который имеет еще дополнительные объекты по сравнению с VBA вроде словаря, регулярок и т.д
VBScript это не расширение VBA, это совершенно другой продукт, который разделяет с VBA ту же торговую марку и очень похожий по синтаксису но несколько иной язык.
Что касается словаря, регулярок и прочего — это не часть VBScript-а, это реализованные в отдельной ActiveX DLL библиотеки классы, которыми вы с лёкостью можете пользовать точно так же и из VBA, и из VB6, и из C++, и из Си, и из PHP собранным с модулем-расширением, дающим поддержку COM в PHP.
Добавлено позже:
Точнее класс для регулярок таки часть VBScript, а вот словарь нет. Что не мешает пользоваться классом для регулярок из под VBA (или откуда угодно ещё) так же, как вы пользуетесь классом для словаря из VBScript (и так же, как им можно пользоваться откуда угодно ещё).
скриптовый язык VBA
ОН НЕ СКРИПТОВЫЙ!
Чем докажите? Чем он по сути использования отличается от того же java script, который в названии даже имеет скрипт? Он так же выполняется не отдельно, а в составе некой среды. Служит для описания взаимодействия пользователя и ядра программы и т.п.
Давайте тогда прежде чем я буду приводить пруфы, вы приведёте чёткое и однозначное определение скриптового языка и его отличий от не-скриптового.
Тем хотя бы, что отличие по использованию от того же VBS в общем то, только в отсутствии типизации данных и небольшого дополнительного синтаксического сахара, типа "объектов" и визуальных форм. То что это всё добавили, чтобы из скриптового языка внешней автоматизации (VBS),майкрософт сделал скриптовый язык внутренней автоматизации (VBA), не делает чем то особо иным, чем он есть по своей сути.
Сложно передать степень фейспалмовости, которое я получил от прочтения ваших убеждений. И такое чувство возникает, прямо между строк читается, будто вы сами обманываться рады.
Будем надеяться, что это искренние заблуждения.
Во-первых, вы вероятно считаете, что между VBA и VBScript совсем небольшая разница, а классический VB (например VB6), который компилируемый, который в EXE-файлы компилируется, который x86-машинный код даёт на выходе стоит где-то в стороне.
Это в корне неверно!
На самом деле, всё наоборот. VB и VBA это практически одно и то же. Образно выражаясь, их генетических код сход на 99%, а в реальности оба продукта собраны из одних и тех же исходников, но с разными ключами условной компиляции.
А вот VBScript это совершенно другой проект, у него абсолютно своя кодовая база, он разрабатывался (по видимоу) другой командой, и единственное, что его роднит с VB и VBA это то, что маркетологам в Microsoft захотелось, чтобы новый скриптовый язык что-то роднило с уже раскрученным брендом.
VBScript это реально скриптовый язык. Он интерпретируется в момент запуска. Он абсолютно безтиповый. У него ОБЩЕЕ ядро с JScript (майкрософтовская имплементация JavaScript).
VB и VBA это совершенно иная история. Во-первых, это уникальный продукт, в котором код хоть и отображается в виде привычного кода, но под капотом среды перестаёт существовать в виде текста уже в момент написания — сразу после того, как программист перевёл каретку на другую, условно говоря, строку. В этот момент код подвергается синтаксическому разбору, по нему строится синтаксическое дерево, оно анализируется, по нему строятся другие бинарные структуры, отражающие семантику написанного. Текстуальное представление кода при этом вообще отбрасывается — когда IDE хочет отрисовать цветной код на экране или отдать его в буфер обмена, она воссоздаёт исходный код ровно для этой цели. Уже это делает VB/VBA языками, которые не имеют ничего общего с интерпретируемыми языками.
В отличие от интерпретируемых языков, которые разбираются и анализируются по мере исполнения программы, здесь разбор кода происходит даже не в момент запуска, а в момент набора кода!
Далее из высокоуровневых древовидных и графовидных структур, которые IDE использует для хранения кода внутри себя, нужные процедуры по принципу JIT компилируются в P-код — так называет байт-код виртуальной машины VB/VBA.
Результаты выполнения, если процедура не менялась, между перезапусками «проекта» не перекомпилируются.
VB же вдобавок умеет компилировать не в P-код, а в Native-код, то есть в машинный код x86-процессоров.
Если вы отбросите своё пренебрежительное отношение и реально захотите разобраться, то вам стоит прочитать несколько статей и несколько моих комментов, в которых я немного раскрыл тайны внутреннего мира VB.
Статьи:
Почему меня называют «отцом Visual Basic'а»
Перевод статьи Алана Купера о том, как он придумал технологию под названием Ruby (не путать с языком программирования Ruby), и как потом она стала частью VB (но не VBA)§ 10. Ruby + EB = Visual Basic
Статья о том, как появился на свет VB как результат слияния двух технологий(опционально) § 12. Сколько строк кода и файлов в исходниках самого VB?
Thunder... рождение Visual Basic
Перевод статьи одного из разработчиков VB о том, как они создавали Thunder, который позже стал VB со многими инсайдерскими фактами.
Комментарии:
https://habr.com/ru/articles/582566/comments/#comment_23578554
https://habr.com/ru/articles/582566/comments/#comment_23589108 (продолжение)
И ещё раз под конец: между VBA и VBScript общего намного меньше, чем вам кажется. По сути что-то общее есть толкьо на уровне названия и фасада, который виден пользователю. Изнутри это абсолютно разные продукты.
Две чашки хорошего кофе этому человеку, который расшифровал то, что я хотел сказать.
А может быть, что vbs ближе к jscript? Т.е. как мне казалось, движок у них один, с той лишь разницей, что vbs заточен под ie и напиханы встроенные функции для обработки дат и какие-то числовые конвертации.
Особенностью использования VBA в Microsoft Office является то, что макросы не могут использоваться отдельно, вне документов. Для своего использования макрос должен быть сохранён в составе документа, и для повторного использования он должен быть открыт в редакторе
Всегда можно сохранить в vbs и в начале дописать "стартовый" объект - приложение. Это если совсем вне офиса запускать.
И да, есть Личная книга макросов Экселя или основной шаблон Ворда, чтобы не было привязки к документам.
Причем тут VBS? Речь идёт о конкретнs[ парадигме в составе средств автоматизации и чем отличаются они в Р7 и MSO. В Р7 тоже есть конструктор документов и к нему апи, но по сути это совсем не то, что требуется для тех же СЭД.
Какая парадигма? Было, по сути, ложное заявление:
Особенностью использования VBA в Microsoft Office является то, что макросы не могут использоваться отдельно, вне документов. Для своего использования макрос должен быть сохранён в составе документа, и для повторного использования он должен быть открыт в редакторе
Макросы могут запускаться вне документа. Более того, для макроса документ (даже текущий) это лишь элемент коллекции. Например, можно запустить из личной книги макросов любой код не имея открытой книги-документа. Конечно, если он будет ссылаться на документ, то будет ошибка (а если поставить обработчик, то не будет). Но если он будет оперировать свойствами и методами объекта Application, то никаких проблем не будет.
Более того, код можно сохранить в виде файла vbs. И если в начале указать объект все того же типа Application (Word, Excel, Outlook и т.д.), то можно запустить этот же самый код VBA в режиме консоли (ВАУ!). Например, это вполне успешно применяется для пакетной обработки офисных файлов. И винда (как минимум ап ту 10) прекрасно справлялась с подобной задачей "из коробки".
Ну,внешние файлы-коллекции для макросов, это сравнительно позднее нововведение в Exсel. И что то я его не встречал для Word, к примеру. А в том же CorelDraw, там макросы изначально внешние файлы (gms) и просто физически их нельзя включить в состав документа. Такое использование скорее лишь частные случаи А то, о чем пишете вы, конечно имеет место быть, но в повседневной практике это скорее исключение, нежели правило, если рассматривать макросы в Excel
Макросы - зло. Вселенское. Если вдруг компания начнёт расти - эти миазмы "малой автоматизации" вырастают до раковых опухолей. Я за время работы в МойОфис такого навидался, что глаз до сих пор дёргается. Целые ERP и системы бухгалтерского учёта были построены на этом зле. Файлы с макросами разбухали до 100-400мб и десятками выгружались в общий сетевой диск, и потом другой документ с супер-макросом всё это обрабатывал ради... 1 странички с диаграммой для топ-менеджмента. Пользовались этим адом сотни сотрудников. И если выходило какое-то обновление - то не все его видели/получали. И это всё регулировалось регламентами компании. И, думаю, не надо упоминать, что происходит, когда у сотрудника "не так версия отчёта". А уж если про ИБ начать общаться... Ммм...
Если необходимо автоматизированное создание документа, в идеале надо перестать быть локальными кодерком, включить внутреннего архитектора и сциентиста. Обучиться разработке на любой платформе автоматизации, которая внедрена в вашей компании (1С как минимум у всех есть) и автоматизируем всё там. И уже там всё реализовать. Централизация в таких вопросах крайне важна. Ну и про преемственность технологий тоже забывать не стоит. Как много разработчиков макросов/плагинов для офисных пакетов? И как много разработчиков под любые корпоративные системы?
Если необходимо автоматизированное создание документа, в идеале надо перестать быть локальными кодерком, включить внутреннего архитектора и сциентиста.
На такое способны лишь все
Целые ERP и системы бухгалтерского учёта были построены на этом зле
Не думаю, что до такого доходит большинство компаний. А как средство "малой автоматизации" очень выручают!
У всех этих решений, которые круче MS Office Есть одна проблема - неудобные интерфейсы ввода, которые крадут тучу времени на вводе по сравнению с фронтендом на базе тех же электронных таблиц, зато быстрее обрабатывает, ничего не теряет и все такое.
В отличие от VBA, не меняющегося с 1995 г., та же 1С, ее маркетологи, сделали всё (новыми версиями платформ и чехардой конфигураций), чтобы доморщенных автоматизаторов свести в 0, и чтобы "в одно лицо" невозможно было сделать ни один весомый IT-проект в ней. Без чисел нехорошо, поэтому вот: сколько должно быть таблиц в БД учетной системы? 100? 1000? А не хотели 10000, как в УПП?! Вы можете представить DBA-человека c пониманием этой схемы данных?
VBA хоронят каждый год примерно с 2000-х. Разработчиков на VBA несколько десятков миллионов, и через 20 лет их будет столько же. А вот что будет с 1С - посмотрим. Их монопольное положение и мышление - пагубно. И в конечном итоге приведет к появлению простого и мощного конкурента, который свергнет лидера. Лимит усложнения систем от 1С исчерпан. "Всё реализовать внутри 1С" не вышло ни у кого, пройдите по заводам. Говорю об этом с горечью, надежды в эпоху 7.7 и первых 8-к были.
И микроскопом можно убить, если использовать не по назначению.
приглашаю в сообщество разработчиков макросов Р7 / OnlyOffice
https://t.me/R7JavaScript
Как же я люблю VBA. Сколько рутины он перелопатил за годы моего использования.
Отличия разработки на VBA для MS Excel по сравнению JavaScript для Р7-Офис