Комментарии 45
VBA сейчас уже архаичный язык. Несколько раз для заполнения и форматирования таблиц Excel использовал скрипты на PHP и библиотеку для работы с xslx, получилось быстрее и проще.
получилось быстрее и проще
У каждого свой любимый микроскоп ;)
Не согласен. Подобное высказывание часто звучат у персон, не знающих всех возможностей VBA. С 1997 по 2006 писал на VBA - word, excel. Потом был PHP по 2015 а теперь Python. Я скучаю по vba. Скрапинг и запросы во внешние базы никогда не были такими простыми. Сейчас иногда пишу скрипты расчета цен в оптовых таблицах. Ну кайф же. Думаю на спад пошло из за проприоритарности "компилятора". Сам же язык очень дружелюбный к пользователю, не похож он на архаику. Пишу это как автор программы учёта грузоперевозок 1997-2004 под Excel
Вот где-то на уровне 1997-го года редактор VBA и застыл. С тех пор не развивался. И даже надежды не было и нет на то, что что-то изменится.
И нет, на VBA писать не кайф. Костыль на костыле.
А примеры костылей VBA можно?
Мне просто интересно, это не сарказм.
Я, наверное, преувеличил чуток, когда написал, что "костыль на костыле", потому что примерами не смогу завалить. Давно не писал на VBA, поэтому это больше мое воспоминание прошлой боли, чем что-то, что я могу доказать аргументами. Думаю, если тема интересна, на профильных форумах легко завалят примерами того, чего не хватает в VBA.
Но для 1997 года это был очень мощный редактор. И даже для уровня 2010-х это вполне достойная среда разработки - но нужно потратить время, чтобы освоить горячие клавишы и приём
Какие у вас проблемы с редактором VBA? Последний раз писал в Блокноте, когда он не различал символы переносов строк. Возьмите IDE vscode с дополнением VBA.
Да самое простейшее, что сейчас приходит на ум, это когда начал писать строку кода, а затем решил перескочить в другое место и там что-то поправить, если в строке содержится синтаксическая ошибка, то выскакивает модальное (!) окно с выбором "Ок" и "Справка". Бесит неимоверно. Закомментировать блок кода - нужно вытащить тулбар с этими кнопками на панель редактирования и шоткатов на это, кажется, нет. А если есть - неудобные и переназначить их нельзя. И таких мелочей множество. Уже все привыкли к хорошему. Всякие рефакторинги - нет их. Для удобств нужн использовать что-нибудь типа Rubberduck (и еще один плаг есть, не вспомню название сейчас), который построен на тех возможностях, что ему предоставлены API редактора, поэтому для многих операций ему нужно сканировать код проекта целиком.
Редактор VBA сам по себе IDE. С функциями отладки по месту. А плаг к вскоду только синтаксис подсвечивает. И зачем оно такое надо?
про дружелюбность языка и среды согласен. Для него есть развитие, к вопросу - Silverlight, например.
Как мне кажется, статья опоздала лет на 20-25. :)
А с помощью с# можно гораздо больше чудес, недоступных для VBA, с офисными документами вытворять.
Мы, кстати, в приложении на С# работаем с документами Word напрямую, как с архивом xml-файлов. При генерации по шаблонам большого количества документов или многостраничных документов работа выходит гораздо стабильнее.
Чтобы с архивом xml-файлов работать надо быть опытным погромистом. У макросов word или exel ориентация на другую ЦА. На офисных клерков с базовыми знания на уровне школьных урокови информатики. Которые так могут себе довольно неплохо автоматизировать многие задачи.
А запрягать для этого высокооплачиваемых мастеров до-диеза, умеющих корчевать xml'ки, зачастую слишком долго, дорого, и для большинства простых офисных работников вообще недоступная роскошь.
умеющих корчевать xml'ки, зачастую слишком долго, дорого, и для большинства простых офисных работников вообще недоступная роскошь.
к вопросу, вот только один раз за много лет потребовалось корчевать xml - когда из какого-то госреестра выгрузили нереального размеры реестр в xml и не смогли его прочитать. Но я со средними своими знаниями даже не взялся - просто слишком много возни кусками делить и преобразовывать, и ресурса компа не хватало.
Можно пример чудес?
Я себе думал так, что с помощью C# можно подключиться к нутрянке офиса и делать то, что доступно в рамках объектной модели офиса. Т.е., ровно то, к чему есть доступ у VBA.
Я года полтора ничего не делал из этой области, но в предыдущем ответе на мой комментарий указывается на более стабильную работу - это в первую очередь. А во вторых - офис написан на с#, только везде начальные и простые команды описываются. Вспомнил, делать расчеты математические с оформлением формула-подстановка-вывод результата + построить и вставить график... в VBA было никак, ну ладно рисования ждать не приходилось, но то, что проблемы с оформлением формул очень плохо. То есть используются все возможности c# для создания объектов и работы с ним, а потом он делает с word все, что мы делаем мышкой и клавиатурой. Первый опыт был - оформление решения квадратного уравнения.
программирование под word в VBA и какие результаты это дало
Если человек повторяет одну операцию в третий раз, значит, эту операцию должен делать за него макрос. Макросы для офиса в сотни раз упрощают и ускоряют работу.
Вариант 1.
регулярность_использования_Word = True
большой_объем_обработки = False
вы_владеете_VBA = True
вы_владеете_другим_инструментом = False
>>> VBA хороший выбор.
Вариант 2
вы_владеете_VBA = False
вы_владеете_другим_инструментом = True
>>> Зачем вам VBA?
Вариант 3.
вы_владеете_VBA = False
вы_владеете_другим_инструментом = False
>>> VBA не лучший выбор. Быстрее разобраться с тем же питоном, он и в других задачах сгодится.
Вариант 4.
большой_объем_обработки = True
>>> VBA не лучший выбор. Питон с его numpy, scipy, etc - тут явно удобнее.
И так далее. Получается, что VBA может понадобиться в основном (но не ограничиваясь) тем, кто его уже знает и использует. Появления новых поклонников у данного инструмента в сколь-нибудь существенных количествах ожидать не приходится. "Демографический" тренд здесь понятен.
Я точно так-же могу питон с хаскелем сравнить и везде, за исключением Варианта 1, не в пользу питона.
поддержу. Мне много раз писали, что нафиг VBA, юзай питон. Но я лично никаких существенных преимуществ не вижу - по удобству работы и величине\слодности кода разницы нет, а вот для пользователя гораздо удобней VBA. Когда у меня вордовский скрипт у пользователя выдает ошибку, то я вижу и что за ошибка,где и почему, по скрину. А с питоном что он мне пришлет?
Возможно, что питон быстрей обработает какие-нибудь огромные массивы и сожрет меньше ресурсов. Но это достаточно редкий случай - как правило, ресурсов железа за глаза хватает.
Если вы правы относительно питона и хаскеля, то со временем мы увидим тот же тренд. Если не правы - то не увидим. Лично я считаю, что низкий порог вхождения и прочие особенности питона позволят ему еще долго быть весьма востребованным инструментом.
Относительно же VBA - выводы можно делать уже сегодня.
К варианту 3: корпоративная политика безопасности не позволяет пользователям устанавливать никакой софт или запускать его с флешек. Единственный выход - писать на тех языках, которые встроены в ОС или Офис. Увы.
К сожалению, MS не заинтересован в развитии VBA, они туда JS уже долго и безуспешно пропихивают. При этом начиная с Офиса 2013 убирают фичи нужные, хотя у огромного количества компаний валятся из-за этого скрипты. То есть пилят сук...
Замечу, что через упомянутые внешние библиотеки получится сделать далеко не все, и для некоторых операций понадобится запущенный экземпляр приложения и активное окно (работа со встроенными объектами и т.п.).
Как программировать в MS Word
Программировать в VBA лучше в Экселе. А ворд дергать, только чтобы создать по нужным данным документ для распечатки. И то, иногда проще и его в Экселе сделать. Все таки объектная модель в Ворде местами более чем странная, а возможности VBA в ней сильно ограничены
соглашусь. Мне Word более требуется для автоматизации Outlook'a. Потому что создавать в нем красивые письма с картинками лучше не через попытки написать html программными средствами, а через GetInspector. Объектную модель можно было бы и получше разработать.
ну, понимаете, вот присылает вам заказчик форму для заполнения в Word'е. Вам ее надо заполнить из экселевской таблички.
И есть 2 пути:
Соорудить аналогичную форму с точностью до миллиметра в экселе и заполнять ее
вызвать Word с готовым шаблоном и, хватая из таблички данные. вставлять их в Word через вордовскую объектную модель.
Кстати, а как вы места в шаблоне для вставки помечаете?
Я изначально в Word'e хотел, но не нашел как эти placeholder'ы обозначить и сделал в Excel
P.S.
А на защите диплома демонстрировал формирование отчета из своей программы на Delphi в Excel «на лету» (т.е. перед изумленной публикой сам открывается MS Excel, создается первый лист, вносятся данные в ячейки, всё это форматируется, потом создает второй лист, переключается на него и там еще данные и форматирование ). Делал по книжке Флёнова.
Не знаю как кому там с VBA, но тот же германский think-cell кучу лет занимается разработкой всякого на C++. И вот я не очень понимаю как они до сих пор цветут и пахнут в своей нише.
В 200х делал БД на MS Access для отца - травматолога. Тогда в больницах никакого безбумажного учета пациентов не было (у нас в Н-ске, по крайней мере). VBA оказался просто прелесть. Особенно в связке с Access - костылями на VBA все необходимое сделал. Пользуется до сих пор (для себя - отчеты ежегодные и тп, хотя и "внедрили систему учета пациентов" - параллельно с ней работает (написал макрос выгрузки из системы данных в эту БД)).
Плюс VBA в том, что оно (вместе с IDE и справкой) доступно сразу из MS Office.
Минусов тоже хватает. Нет связи с VCS (в 21 веке без этого просто странно). Не очевидно, как эти макросы deploy'ить (возможно, у winadmin'ов есть своя уличная магия).
В какой-то версии Rubberduck вроде была фича, что можно легко выгружать структурированный код и потом его коммитить в git. Жаль, потом выпилили
Лет эдак N — просто другого не было. Вообще. А сейчас просто дорогой рудимент.
Исключение — у кого исторически завязанная система с развитой логикой, которую дешевле поддерживать, чем переписать…
В современных условиях нужно, чтобы мс-офис, купленный десять лет назад, смог быстро выполнять типичные операции. Пример: вы построили график, и чтобы оформить его правильным цветом и шрифтом, нажимаете одну кнопку. Пример: вы нарисовали таблицу, и чтобы оформить её правильным цветом и шрифтом, нажимаете одну кнопку. Пример: вы устали менять дефисы на тире и убирать двойные пробелы, и чтобы всё это сделать, нажимаете одну кнопку.
Эта кнопка запускает ваш макрос.
Веб-приложение? То есть надо на локальной машине поставить веб-сервер, настроить брандмауэр и написать веб-приложение?
меня всегда умиляли подобные рекомендации. Типа, если партнеры не могут интегрировать системы на уровне серваков - напиши веб-приложение.... Ага, так мне и позволили веб-приложения писать в корпорации :) Мне вон программную отправку писем на системном уровне закрывали, не то что вебку писать.
Единственная к статье претензия - а что, так можно было?
Я вот лично всегда думал, что автоматизация офиса средствами VBA, причем на начальном уровне - это какой-то примитив, недостойный статьи, потому что интернет им переполнен.
Меня тут упрекали за отсутствие технических статей, но если так тоже можно, то вот я сейчас развернусь :)
Ну, тут дело такое: я всегда исхожу из "презумпции незнания" :-). По умолчанию, я считаю, что кто знает - пройдёт мимо. Кто не знает - тому будет полезно. В любом случае, структурированная информация, за бесплатно - думаю, это не вредно.
А то на каком то уровне (по себе сужу) - не знаешь про что писать, так как "вроде да кому это надо то!". А на самом деле - надо. Все на разном уровне...
Программирование в Word: зачем, почему?