Комментарии 44
к последней картинке в прошлом году вышел продолжительный видео-мануал в котором одно сплошное vba
К vbscript заодно сделайте :)
Запуск менеджера пакетов руками в vba это конечно крайний зашквар.
Что можно сделать:
Открыть, что параллельно vba давно работает jscript и там все значительно более современно. Но ставить надстройки только из магазина мелкомягких не всем хочется.
Вспомнить, что офис работает на любом скриптовом языке, который подключается в vba. Питон, vbscript и т.д. vba нужен только для подключения движка этого языка.
Во втором случае код можно хранить в облаке с контролем версий. Управлять им можно из меню Эксель/Ворд , а не из vba.
Я работаю в компании, в которой для того чтобы воспользоваться командой pip install <foo> нужно создавать заявку, если Вы понимаете о чем я?
Да, это печаль, боль. Но вот так.
Поэтому увы эти вещи мне лично не подходят. И поэтому велосипед.
Ну и плюс это интересный опыт.
Запуск менеджера пакетов руками в vba это конечно крайний зашквар.
А как понять запускать руками?
А можно про второй пункт подробнее? А то у меня от VBA и пустого "скрипта" для эксель перевалившего за 5 мб. глаз дергается. А IDE которое не развивается, хочется удалить и забыть, как страшный сон.
Могу поделиться своим опытом.
Использую jscript. Пишу в VS Code. Храню в GDrive. Помогает ейная консольная утилита. Там же менеджер пакетов. Локальная копия для работы офлайн.
Код обновляется по событию без необходимости открытия редактора VBA.
Хранить jscript в standalone gscript project начал потому что там и IDE какое-никакое, и типа аварийный доступ, и что-то вроде линтера. Но наверное все же лучше на гитхабе хранить, если облако вообще нужно для доставки пакетов.
Ко второму пункту стоит отметить, что родные интеропы у ворда/экселя дюже медленные.
Давным давно пришлось писать обход каждой ячейки каждой таблицы в огромном вордовском документе — дёргать напрямую апи ворда занимало где-то около получаса на документ; склеить же конкатенацией строк прям в VBA что-то JSON-подобное на весь документ, отдать в скрипт, обработать, отдать обратно, и в VBA по новой Split'ами разобрать и внести изменения в документ — занимало секунды две от силы.
Видимо, сказывается оверхед на каждый COM-вызов, через который эти интеропы работают, а вызовов в таком сценарии выходило огромное количество.
Если у вас есть мысли, как сделать совмещение версий в одном проекте, напишите коммент.
Может просто номер версии в название ставить?
Например: "Магнезия 1.0.0.cls" и "Магнезия 2.0.0.cls".
Ну а в аттрибутах класса (Attribute VB_Name = "XXXX") можно либо для каждого класса использовать разные имена (и использовать оба класса, "Магнезия_1_0_0" и "Магнезия_2_0_0" в рамках одного и того же проекта), либо одинаковое, тогда какую версию загрузите, такой и будете пользоваться.
Пока что это единственный вариант который я рассматривал ? Но тут есть сложность:
Придется открывать каждый файл, редактировать название этой зависимости (а для начала ее найти там). И если это делать обычным Replace, то боюсь можно зацепить то, что зацеплять нельзя. Поэтому придется городить чтото сложное, а хочется простоты.
Возможно этот вариант в итоге и останется, но хотелось бы что-то более неочевидное и при этом такое же простое.
Я тут медленно и печально пилю свой велосипед (да, я искал для себя альтернативы, но мне они не зашли). Основная идея - для ГитХаб Экселевские файлы это обычные бинарники, отследить изменения которых практически невозможно. К тому же, мои таблички обычно большие (100 Mb и больше). Загружать такое на ГХ только из-за пары изменений в коде - не комильфо. Идея такова, что есть неизменяемый загрузчик (табличка с одной кнопкой "Инсталлировать"), который грузит XML-файлы с конфигурацией листов и все найденные bas/cls/frx - файлы.
MVP в виде таблички там уже есть.
Вбашники всех стран, соединяйтесь. Только не забудьте, что кроме этого вашего эксцеля бывает ещё пара сотен хостов (как слышал). Вот я для корела пишу. Когда я вижу в вба-коде общего назначения вставки чисто из эксцелевской объектной модели, чувствую себя среди вбашников так, как вбашник чувствует себя среди нормальных программистов.
Вот он я если что
https://vk.com/elvin_macro
https://github.com/elvin-nsk
А задумка в целом годная, по крайней мере, я сам задумывался про какую-нибудь систему автоматического обновления, причём не одного файла с макросами, а чтобы с внешними зависимостями. Неудобно все модули в один gms-файл пихать.
Немного расстраиваюсь, когда вижу в вба коде вставки чисто из эксцелевской объектной модели
Не расстраивайтесь) просто конкретно я работаю в excel, поэтому других примеров у меня нет ?
Я не против и всегда открыт для любых вопросов. Тем не менее, ситуация не сильно радужная.
Мы, VBA-шники, народ замкнутый и мрачный, потому что уровень вхождения в язык ниже плинтуса (автоматически записал макрос, сделал вокруг него цикл, и, типа, порядок), а потому и средний уровень макросов по палате близок к поделкам старшей группы детского сада.
Да и сама терминология просто унизительна: на Питоне – программа, на VBA – макрос, хотя оба языка – интерпретируемые и чистый VBA быстрее чистого Питона.
У Питона можно загрузить расширения, а вот чтобы загрузить Add-on для VBA придётся долго лазить по сети. И не факт, что найдётся нужное расширение, и, тем более, что будет работать.
Отдельно добавляют «оптимизма» ежегодные объявления о закрытии VBA и переходе на JS, особенно с новостями, что Office 2021 будет последним, а потом все в Office 365 с его облаками и подписками. Спасибо, конечно, но я хочу (и всегда хотел, даже когда это было не в «тренде») иметь все свои файлы при себе, а не «где-то там».
Хотя, надо отдать Офису должное: то, чем так горды питонисты, Jupyter Notebook, мы имеем с самого начала возникновения VBA (с 1995 года!).
Мои поделки находятся здесь:
Не могу лайкнуть - кармы наверное не хватает - но ППКС.
Что вы имеете ввиду под аддонами для VBA? Для среды разработки VBE IDE? Или для самого языка. Под язык априори не может быть расширения, так как он проприетарный и не подразумевает этого изначально. Но у него есть один просто мегаогромный плюс изначально (он же и минус, если следовать диалектике) - встроенная изначально поддержка COM как наверного нигде более не реализованная! Подключай сторонние объекты и твори из под коробки с их помощью что хочешь. И второй очень большой плюс - простая в общем то поддержка dll. Если кто то постарался и сделал описание API (как есть например почти для всего WinAPI и много чего ещё от самого микрософта), то и библиотеками пользоваться можно. Со скрипом, но я например реализовывал рисование псевдо 3d объектов, с помощью функций GDI WinAPI в окне макроса CorelDraw. Работает со скрипом (мерцает окно формы макроса при перерисовке, так как увы, но в WinForms без дизассемблирования нельзя получить hWnd контрола внутри формы, и по'тому приходится принудительно обновлять всю форму), но тем не менее.
Понятное дело, что это всё не какие то особые достижения именно самого языка, но тем не менее, даже до сих пор, столь быстро и удобно набросать код и получить результат именно с использованием стороннего API или COM объектов, в том же Lua или JS, без танцев с бубном не выйдет, насколько я пробовал. В Питон может быть и попроще, но автоматизация на нём тоже не пряник (пробовал писать свои расширения под Blender и был не сказать что в восторге от предварительной работы, чтобы всё более менее удобно было в том же VS Code)
А что до закрытости тех, кто пишет на VBA, так тут вопрос не в закрытости, а в очень узкой специализации данного языка. Просто мало кто им пользуется, если задуматься и соотнести масштабы распространения самого офиса или того же Корела, и число тех, кто при этом использует автоматизацию.
Под аддонами я имел в виду любые сторонние библиотеки. Да тот же Solver, например. Вот их мало, нет даже места, где я могу поискать подобные библиотеки (а нет, есть, Google называется). Я даже, прикола ради, только что поискал LAPACK для VBA. Нашёл только общие рекомендации скомпилировать сишный код и вызвать из DLL. А если у меня VisualStudio / gcc нет, как тогда?
Закрытость VBA для меня выражается в том, что все копают только в свою сторону. Open source в случае VBA – это разрозненные репозитории и веб-странички, которые сначала надо отыскать.
Узкой специализации VBA я как раз не вижу. Да, большинство использует Эксель для бухгалтерии (им зачастую VBA и не нужен). Использовал его практически для всего (парсинг сайтов через Selenium, обработка звука (wav-файл на входе, wav-файл на выходе), всяческие штуки с матрицами на GPU / CPU, асинхронные вычисления, спецфункции комплексного переменного, вроде функции Эйри).
В качестве псевдокода VBA просто идеален. Можно протестировать любой алгоритм. Но нехватает расширяемости Питона: графики – только какие есть, прямиком из 1997 года, формат самого файла – только бинарный – в ГитХабе изменения не отследишь, сам файл как Jupyter Notebook в ГитХабе не откроешь.
Вот, как-то так. Сумбурненько, но как есть.
нехватает расширяемости
Это непонятно о чем. Несколько направлений для расширений. Сами же признаете, что можно приспособить
практически для всего
Питон в две строки подключается и весь его арсенал ваш. VBA c гитхабом дружат. А то, что xlsx гитхабом не откроешь, так им и банку с огурцами не откроешь, но это же не проблема огурцов.
Графики хоть на d3 стройте, в подтверждение я вот такой график строю
Да, графики у Вас супер. Однако стандартные графики в Экселе застыли с 1997 года. Строил графики в 1999 году на Origin – вот это была просто песня! 3D графики Origin определённо рендерил на OpenGL (блики, плавные цвета, цветовую шкалу, освещённость можно было менять). Обычные графики тоже можно было настроить как хочешь – разрывы в осях, например вставить.
Просто смотрю я с точки зрения даже хотя бы и построения графиков на Эксель и слёзы накатываются. За это время (25 лет с 1997) даже JS получил WebGL.
VBA c гитхабом дружат.
Посмотрел первые ссылок 5 – примерно те же велосипеды на костылях, что и у меня. Думал, на самом деле что-то новое придумали, но нет, всё как всегда.
> нехватает расширяемости
Это непонятно о чем.
Попробую ещё раз. Хотелось бы иметь централизованное хранилище для Экселевских расширений. Типа, хочу красивые графики – вот тебе парочка расширений, хочу LAPACK / BLAS или быструю математику – вот тебе ещё парочка, а не искать по кривым закоулкам интернета.
А то, что xlsx гитхабом не откроешь…
Да Вы и сами знаете, что xlsx это зазипованные XML-файлы. Тут буквально рукой подать до Jupyter Notebook. Но, как видите, у Майкрософта руки не дошли. А ведь могли бы.
Ну опять же, я не понимаю, что значит любые сторонние библиотеки? Зачем делать то, для чего инструмент не предназначен? VBA вовсе не универсальный язык. Писать на нем в принципе ужасно, учитывая какой слабый IDE используется для разработки. Формы там рисовать ну в принципе ничего, но есть куда более быстрые и удобные инструменты для дизайна GUI. Это чисто инструмент автоматизации другого софта, и не стоит его использовать иначе. Для прототипирования, как псевдокод - ну так себе идея. Тоже потом особо не не перенесёшь так просто. Лучше сразу писать на VB или С#, если уж на то пошло.
Я за много лет, что пишу на разных ЯП, пришёл к выводу, которого придерживаются большинство опытных программистов:
Написать всё что угодно, можно на чём угодно. Вопрос только во времен, силах и упорстве. Но вопрос - зачем? Есть специализированные в своей области языки, вот ими и надо пользоваться в конкретной ситуации. Сэкономишь и время, и силы и упорство не перегорит.
Про библиотеки я немного выше отписался. И да, я знаю, что на VBA ОС не напишешь, как впрочем и на Питоне, JS и C# (вот тут уже не уверен). А сторонние библиотеки хочу иметь, чтобы Эксель делал быстро и красиво именно то, для чего он и предназначен – считал и рисовал красивые графики.
Писать на нем в принципе ужасно, учитывая какой слабый IDE используется для разработки.
Вот прямо стало интересно, чем же IDE VBA так не угодило (пишу, в порядке убывания в VS, Xcode и VScode)? Тёмную тему не завезли? /sarcasm!
Для прототипирования, как псевдокод - ну так себе идея. Тоже потом особо не не перенесёшь так просто. Лучше сразу писать на VB или С#, если уж на то пошло.
В том-то всё и дело, что Эксель идеально подходит для прототипирования. Вы в VS можете в дебагере построить график на основе какого-нибудь массива? А потом прибавить к каждому элементу что-то нелинейное и посмотреть формулу подгонки полиномом? А в Экселе это нормальная практика (ну, у меня, а не в бухгалтерии, конечно).
А сторонние библиотеки хочу иметь, чтобы Эксель делал быстро и красиво именно то, для чего он и предназначен – считал и рисовал красивые графики.
Не силён в графиках под Excel, но в целом, есть же более специализированные средства, под графики заточенные. Ну и под обработку и вычленение данных - тоже. Да и мне так думается, что усилия по написанию и отладке всего этого хозяйства на VBА сравнительно большие, чтобы так заморачиваться. Я бы лучше конечные итоговые данные генерировал в специализированном ПО во что-то типа CSV (XML,JSON) , а потом просто бы с помощью VBA рисовал итоговые данные, нежели заморачивался ещё подтягивнием для обработки специализированных библиотек обработки больших объёмов, потом как-то писал к ним интерфейс и ожидал в VBA результатов, и потом только рисовал графики. Ну или, если уж всё надо в рамках офиса делать - то лучше тогда писать все как аддон в офисе на VSTO (VB или C#) и там подгружать искомые библиотеки. Этот путь в итоге явно более перспективен, если касаться больших (или многочисленных однотипных) задач с данными
Вот прямо стало интересно, чем же IDE VBA так не угодило (пишу, в порядке убывания в VS, Xcode и VScode)? Тёмную тему не завезли? /sarcasm!
Сервисом. Очень устаревший, по нынешним меркам. Мало контроля за GUI в формах. Да и сами формы - это уже мягко говоря устаревший механизм. Хотя, я думаю, когда их делали 20 лет назад, никто не ожидал что настолько все затянется с их использованием. На современных IDE писать и удобнее и эффективнее (и темная тема не причем, вообще ею нигде не использую), а просто больше механизмов для ускорения работы. Конечно, частично решается за счет аддонов к самой VBE IDE (типа того же Rubberduck), но не особо то и сильно они что то меняют. Сами механизмы заложенные в IDE просто уже отстали от реалий современного программирования.
Вы в VS можете в дебагере построить график на основе какого-нибудь массива? А потом прибавить к каждому элементу что-то нелинейное и посмотреть формулу подгонки полиномом? А в Экселе это нормальная практика (ну, у меня, а не в бухгалтерии, конечно).
Ну, вообще в VS давно есть механизм собственных визуализаторов отладчика. Причем, их не так сложно написать (или найти готовые, а вдруг есть?) на свой вкус и для своих целей. Если речь идёт о реально необходимом инструменте в разработке и это единственный останавливающий момент не пользоваться VS, то вполне можно поискать и готовые решения (в том числе и опенсоурсные), или примеры по их написанию и адаптировать под себя. Про "добавить неленейное и проверить подгонки полиномами", то опять же, я не специалист, но насколько я касался отчасти таких вопросов, это давно и хорошо сделано в Вольфраме, или в блокнотах Юпитера. Впрочем, опять же всё зависит от многих факторов, которые конкретно к вам применимы. Может ваш путь и оптимальный именно в ваших условиях.
Искушенный читатель сразу заметил отсылку к другому менеджеру – npm. И да, для меня он стал идейным вдохновителем и лекалом всего проекта, поэтому велосипед будет изобретаться по его образу и подобию (со своей реализацией, конечно).
Пакетные менеджеры под node могут хранить файлы любого типа, а не только js код.
Как насчет того, чтобы просто класть vba код в node пакеты и написать кастомный ресолвер повторяющий алгоритм ресолвинга node
https://stackoverflow.com/questions/316166/how-do-i-include-a-common-file-in-vbscript-similar-to-c-include
Тогда и писать ничего не нужно будет. Просто используем npm, yarn, pnpm как есть
Кто-то для ANSI C даже такое делал https://www.npmjs.com/package/dotc
Я думал над этим, и по факту это правильное решение.
Но как я уже ранее ответил другому комментатору — я работаю в компании, где pip install <foo> не работает без сис админа.
Описаный Вами вариант так же не будет работать, так как запрос в консоли зависнет на обращении к серверу (приложениям нельзя выходить в сеть, кроме локальной).
Этим и обусловлено изобретение велосипеда (просто так в эту сложную тему я врядли бы полез, есть же готовый инструмент).
Но они умеют и локально работать, да и админские права не нужны
https://pnpm.io/cli/add#install-from-local-file-system (в зависимости от пакетного менеджера и их версий способ может отличаться, но так или иначе эта фича представлена везде)
Access denied по ссылке
Нужен ip не РФ.
Разрабы pnpm довольно политизированы https://github.com/pnpm/pnpm
Привет! всем! VBA-шникам, по делюсь своим решением, только у меня не пакеты а сниппеты, но смысл тот же можно вставлять маленькие кусочки кода или процедуры целиком
сайт надстройки https://vbatools.ru/macro-tools-vba-addin-excel/
GitHub репозиторий - https://github.com/vbatools/MacroToolsVBA
Код полностью открыт, можите менять на свое усмотрение, буду рад вашим предложениям!)
И не большая плюшка, моя надстройка улучшает стандартное IDE VBA - в ней очень много фишек часть описал в статье хабра https://habr.com/ru/post/720806/
А я Вас знаю! Подписан, правда руки пока не дошли установить, но выглядит красиво. Вместе с RubberDuck будет отличная связка.
!) Тоже так думал, но отказался от этого, так как RubberDuck по сути ни чего нового не дает, у меня больше функционала, основная функция в RubberDuck - сообщение об ошибках, на больших проекта очень сильно зависает - поэтому уже давно не использую его! Делаю свою надстройку - тем более она полностью на VBA - получается VBA-шник может сам ее менять на свое усмотрение!
Прочитал с интересом, спасибо за статью!
Сам я не программист, но по работе периодически автоматизирую что-то в офисе для себя и коллег на VBA (преимущественно в Excel). Установить что-то из интернета без привлечения админа у меня нет возможности, поэтому я не использую в работе JS addins (а хотелось бы).
P.S.: Я признаю, что VBE морально устарел, но для ряда задач связанных с офисом у меня просто нет альтернатив. Если кто-то знает способ писать скрипты для Excel не на VBA и чтобы для последующей эксплуатации написанного разными людьми не нужен был выход в интернет (для скачивания, установки чего бы то ни было), просьба поделиться опытом :)
Немного поделюсь своим велосипедом:
Со временем у меня накопилось небольшое количество ф-ции / процедур на VBA, которые хотелось бы а) где-то централизовано хранить / версионировать; б) легко по ним искать; в) быстро импортировать в Excel файл. В итоге пришел к тому что храню полезные для себя кусочки кода в Github, для поиска по ним сделал простенький сайт. Прочитав вашу статью, я понял, что мне не хватает версионирования "пакетов", а также не задумывался про подобие cli интерфейса, чтобы устанавливать / удалять / обновлять "пакеты" через "вбансоль". Пока что мои пакеты не имеют версий (версия всего одна - самая свежая), а импортировать (включая их зависимости) можно через форму в Personal.xlsb (через "вбансоль" ИМХО было бы удобнее). Также пока нет возможности удалять / обновлять пакеты. После прочтения вашей статьи мне есть над чем подумать и чем занять себя в отпуске :)
Надеюсь, у вас получится доработать ваше решение, с удовольствием почитал бы продолжение! К сожалению, не могу поставить плюс вашей статье, но мысленно поставил. :)
Благодарю за приятные слова)
Крутой сайт, кстати! Пока только с телефона попробовал глянуть, но выглядит очень достойно.
Если кто-то знает способ писать скрипты для Excel не на VBA
Знаю для VBE неплохую замену — twinBasic.
Он слегка глючный и не все до конца работает как надо, но выглядит в общем и целом похожим на vscode. Есть хорошая подсветка кода, автодополнение и прочее. С объектами типа Worbook, Worksheet, Range и тд полноценно взаимодействовать не получится (наверное, я не до конца погружался), но для написания кода без выполнения очень даже хорошо (к слову, debug.print и MsgBox тамрю работает). Если есть желание, покопайтесь, если еще не. Возможно как альтернатива не самая лучшая, но других не имеем, увы.
Делаю Package Manager для VBA