Я знаю, какое у вас сейчас лицо:
Но на самом деле идея не нова и изначально я даже думал не изобретать велосипед, ведь есть по описанию неплохой vba-blocks, с открытым исходным кодом. Бери не хочу.
Увы, так вышло, что я не умею писать скрипты в powershell, а у меня при установке какой-то из этих скриптов не отрабатывает и падает.
Если, кстати, кому-то интересно, попробуйте поправить, расскажите хоть как оно?
Ну а я беру палки и колеса, и начинаю лепить творить все же лепить.
Прежде чем мы начнем
1. Я не программист, я музыкант. Но сейчас моя профессия – разработчик VBA. Я не знаю как правильно писать код. Но учусь, кажется. И когда я делюсь своими мыслями – я тоже учусь. Если вы хотите помочь мне научиться, я буду только рад ????
2. Далее пойдет многобуквенный текст о том, как автор делает для себя инструмент для упрощения работы с VBA. Кода нет. Вернее у меня то он есть, но его много и какие куски сюда добавлять я не знаю (да и надо ли оно).
3. Здесь вы не увидите очень крутую штуку, которую точно-приточно надо быстрее запихивать в мой проект, оспаде, как же я раньше жил без этого.
Это, по сути, личный инструмент автора, про который он (кто он? я, получается) решил поведать всемумирухабру.
Так что если вы сюда за святым граалем — Thank you Mario! But our princess is in another castle!А всем остальным приятного время провождения.
Что такое PackageManager
Не буду нудить скучными вырезками из википедии и постараюсь своими словами объяснить.
Package Manager – это npm, и pip, и nuget, и composer etc.
Ну вы поняли.
Нет? Тогда вот вам википедия под катом:
Информация из Википедии, свободной энциклопедии
Система управления пакетами (также иногда «менеджер пакетов» или «пакетный менеджер») — набор программного обеспечения, позволяющего управлять процессом установки, удаления, настройки и обновления различных компонентов программного обеспечения. Системы управления пакетами активно используются в различных дистрибутивах операционной системы Linux и других UNIX-подобных операционных системах.
Программное обеспечение представляется в виде особых пакетов, содержащих, помимо дистрибутива программного обеспечения, набор определённых метаданных, которые могут включать в себя полное имя пакета, номер версии, описание пакета, имя разработчика, контрольную сумму, отношения с другими пакетами. Метаданные сохраняются в системной базе данных пакетов.
Исходя из того, что делает менеджер пакетов, можно вывести список того, что же нам предстоит разработать.
Ну, вроде все просто:
Нужно создать консольное приложение, которое будет парсить....
...Так, стоп
Всё, да? Приплыли. Консольное. А как же в excel/word/access открывать консоль-то? Отдельно чтоли? Это же неудобно!
А Immediate Window только и умеет, что выводить информацию через Debug.Print.
Да, но не совсем. Immediate (я буду называть ее вбансоль, чтоб понятней было) умеет выполнять процедуры и функции:
Ну, то есть, есть у нас какая-то функция, мы ее в вбансоли вызываем, она нам выдает какой-то результат. Уже можно парсить аргументы, получается.
Попробуем еще раз пройти по списку?
Нужно создать
консольноевбансольное приложение, которое будет парсить аргументы и исходя из переданной команды выполнять некие действия:
1. Инициализировать проект (init)
2. Находить и устанавливать пакеты (install)
3. Публиковать пакеты в некое хранилище (publish)
4. Обновлять уже установленные пакеты (update)
5. Удалять установленные пакеты из проекта (uninstall)
Ну это база.
А зачем козе баян?
Нет, а действительно, зачем? Разве макросы настолько большие, что туда постоянно нужно что-то импортировать?
Да. Причем на моей практике таких макросов много. И так как VBAшники работают в современных IDE, а сам VBA – современный язык программирования, для которого как крупные компании, вроде google, так и энтузиасты пишут кучу разных пакетов/библиотек/фреймворков, ими нужно как-то управлять.
...
Ладно, на самом деле всё чуточку плачевней.
Откровенно говоря, я действительно в каждый проект импортирую кучу кода, который специально пишу для переиспользования. И да, все это пишется только для себя, как и любые VBA инструменты (надстройки не берем в расчет, наверное, как удобно; вы можете взять в расчет, а я не хочу).
Самый частый гость в моих проектах – класс модуль CRegExp, который помогает взаимодействовать с регулярками (напишите в комменты, если интересно глянуть как он выглядит, закину на GitHub |=| там по сути обертка для VBScript.RegExp, так что наверное ничего интересного |=| я передумал, короче, не пишите в комменты).
И подобных гостей много. И импортировать все это каждый раз руками... я что, не программист чтоли?
До недавнего времени, для импорта пакетов я пользовался... Ни за что не догадаетесь... изобретенным для себя велосипедом в виде надстройки, которую подключал к проекту. В ней есть несколько функций, вызывая которые в вбансоли, можно было импортировать код, заранее сохраненный в какую-нибудь папочку, в подключенный проект и спокойно им пользоваться.
Очень удобно, поверьте.
И вот сейчас кодовая база моих пакетов начала разрастаться и ими стало неудобно управлять.
Отсутствует нормальное версионирование, например. Неудобно прописывать зависимости для того или иного пакета (а так как код переиспользуемый, некоторые пакеты ссылаются на другие пакеты).
И вот тут я понял, что настало время нового велосипеда...
А что это за кружочки?
???? – реализовано
???? – в процессе реализации, но уже что-то работает
???? – пока даже класс не создал
????Нулевая задача - а как звать то?
Итак, с чего начать новый проект?
Правильно – с названия. Я потратил на то, чтобы придумать название менеджера пакета для VBA почти полчаса, но теперь оцените:
ipm– Immediate Package Manage
А? Каково?
Думали vpm (vba package manager) увидеть, а вот и нет.
Искушенный читатель сразу заметил отсылку к другому менеджеру – npm. И да, для меня он стал идейным вдохновителем и лекалом всего проекта, поэтому велосипед будет изобретаться по его образу и подобию (со своей реализацией, конечно).
????Первая задача - модуль Package
Вспоминаем, что там у нас идет первым делом:
Инициализировать проект (
init)
Вот с init и начнем.
При вызове этой команды, вбансоль должна запросить:
Имя пакета
Версию
Автора
Описание
и записать все эти данные. В npm они хранятся в файле package.json.
И что, опять стоп? Как вбансоль диалог то делать будет?
Отставить панику, я все придумал.
Материал из лучшего телеграм канала о VBA по версии его админа – Дневник VBAшника
PackageManager: диалог в Immediate Window
...
Так вот, думал, как бы сделать аналог консольного диалога (в npm, например, после вызова команды init происходит диалог с пользователем, после чего из полученных данных формируется package.json). Immediate Window не совсем для таких вещей сделали. Но выдумать, таки, получилось.
Суть простая:
Пишем основную процедуру, в которой будет вызван диалог.
Заканчиваем выводом сообщения с названием следующей функции и нижним подчеркиванием, в которую ожидаем аргумент от пользователя.
Примерно так все выглядит:
Sub Start()
Debug.Print «Продолжить диалог?(y/n)»
Debug.Print «Continue _»
End Sub
Sub Continue(ByVal Choice As String)
If Choice = «y» then
Debug.Print «Продолжаем, следующая функция!»
ElseIf Choice = «n» then
Debug.Print «Ок.»
Else
Debug.Print «Неизвестная команда!»
End If
End SubВ итоге в Immediate Window получаем такой диалог:
Start ' жмем Enter
=> Продолжить диалог?(y/n) Continue _
' курсор будет находиться на этой строке, нужно будет ввести ответ в кавычках, например «n» и нажать Enter
=> Ок.Причем ответ можно писать не в полных кавычках («y»), а только с первой («y). Работает одинаково.
Вот такая имитация cli диалога. Не думаю, что кому-то пригодится, но кажется что штука забавная????
Далее, файл package.json.
Мы, как прогрессивные программисты, в VBIDE создавать файлы не можем, поэтому для этих целей будем использовать стандартный модуль и комментарии.
Выглядеть все должно примерно так:
Заметили последнюю строку? Ее на вкусное оставлю, затрону позже.
Тут, в принципе, все просто. Спарсили команду, создали (или нашли) модуль Package, записали полученную информацию.
Но.
В npm каждый импортируемый пакет идет со своим package.json. То есть таких файлов в проект импортируется ровно столько, сколько пакетов и их зависимостей будет импортировано.
А у нас что?
На этом все. Подписывайтесь на канал, ставьте лайки.
Первое решение, которое пришло мне в голову – лепить к названию модуля имя пакета. И думаете я придумал еще парочку и выбрал лучшее? Глупости какие.
В случае с примером будет CRegExpPackage.
Это имя для экспорта.
А для init, чтобы отделить основной пакет от импортных (шутка про импортозамещение), будем называть модуль ThisProjectPackage.
Даже нативно получается.
????Вторая задача – пакетик нужен?
Идем дальше по списку:
Находить и устанавливать пакеты (
install)
Ох, как тут все неоднозначно.
Во-первых, где хранить пакеты?
Ну в текущей итерации, ForMyselfMode, вполне достаточно и локального хранилища.
Для того, чтобы первично задать путь к этому хранилищу, я решил сделать доп команду config в которой нужно будет прописать значение опции --rootpath – путь к папке со всеми пакетами.
Команда парсит путь и записывает его в переменную окружения PACK для текущего пользователя .
Во-вторых, а как быть с версиями?
И вот над этим я сейчас скрипящими и кипящими мозгами думаю.
Вот вам синтетический пример:
Есть пакет Четверочка, на который логотип наносит компания РисуемНаПакетах версии 1.0.0.
А еще есть пакет Магнезия, на который логотип наносит та же компания РисуемНаПакетах, но более поздней версии – 2.0.0.
Мне нужны в проекте оба этих пакета, но они за собой потянут компанию РисуемНаПакетах, и вот тут произойдет конфликт версий (придется брать версию 1.0.0 и 2.0.0).
В npm это решается очень просто – создается новая папка node_modules внутри папки загружаемого пакета и уже в нее импортируется нужная версия.
Внимание вопрос.
Если у вас есть мысли, как сделать совмещение версий в одном проекте, напишите коммент.
Вот тут правда, честно. Вообще не представляю.
И напоследок, в-третьих, при импорте пакета, информация о нем должна записаться в файлмодуль ThisProjectPackage, а именно в раздел '@dependencies, ну чтобы понятно было, какие пакеты используются в проекте. Более того, туда же нужно записать версию пакета, ну чтобы понятно было, какая версия пакета используется в проекте.
Выглядеть это должно примерно так:
Интересный факт (нет)
На текущей итерации у меня небольшой баг в этой команде – в зависимости основного проекта попадают пакеты и их зависимости (а должны только сами пакеты, т.к. их зависимости прописаны в их модуле Package), но это поправимо.
Не знаю зачем вам эта информация, просто решил рассказать. Вы же зачем-то аж сюда дочитали????
????Третья задача – пакет с пакетами
Публиковать пакеты в некое хранилище (
publish)
Какие тут могут быть проблемы?
Берем модуль, сохраняем в папку. Готово.
Ну в целом то да, но как зависимости то не сохранять в папку с основным пакетом?
У нас же задача в чем? Настроить удобное управление пакетами, то есть их импорт, экспорт, изменение и т.д.
Вот чтобы изменение было легко производить, нужно отделить мух от котлетзависимости от основного кода.
А что, а как?
А Rubberduck! нам на что?
Раз уж я очень крепко прикипел к этому аддону, решил задействовать его в своей надстройке.
Для тех кто не в курсе:
Ну уж про Rubberduck вы должны были слышать! Так ведь?
В общем для своего Code Eplorer'а этот аддон добавляет в каждый модуль комментарии.
Один из таких комментариев – '@Folder.
Как следует из названия, он отображает информацию о том в какой папке лежит модуль (ну как папке... ну вы поняли).
Вот эту инфу мы и будем парсить.
Всего лишь нужно экспортируемый/публикуемый код поместить в папку src в корневом каталоге. ThisProjectPackage выносим в корень:
Всё, мухи отдельно, котлеты отдельно.
Еще одно обязательное условие, перед экспортом переименовать ThisProjectPackage в [NameOfProject]Package, а потом, и это не менее важно, вернуть название обратно.
Ну и, естественно, в нашем хранилище должна создаваться папка с названием пакета, в которой должна создаваться папка с номером версии, в которой должна создаваться папка src, в которую мы экспортируем весь проект + package модуль.
Зачем src? На самом деле не зачем, просто раньше я выносил package отдельно от основного кода.
Возможно надо фиксить, но мне пока лень и вдруг в этом есть смысл?
Устали? Ща побыстрому пробежимся по последним пунктам.
????Четвертая задача – у нас новые пакетики
И вот вы уже почти уснули, а я начинаю предпоследнюю главу своего умопомрачительного повествования.
Обновлять уже установленные пакеты (
update)
Тут, как обычно, все очень просто.
Парсим package модуль, ищем там нужный нам пакет, проверяем до какой версии можно обновить, обновляем.
Самая короткая задача, наверное. Поправьте меня, может я ошибаюсь?
????Пятая задача – выкинь ты этот пакет
Удалять установленные пакеты из проекта (
uninstall)
А вот тут есть что сказать по сложностям. Одно слово – зависимости.
Нужно пройтись по всем установленным пакетам и их зависимостям. Еще раз, по всем пакетам и по всем их зависимостям, гуглим Dependency hell.
И че? И где?
Как вы поняли, ipm пока в разработке. Буквально вчерашняя ночь прошла в отладке трех команд из-за переименования модуля package. Но результат того стоит.
Сам проект я выложу в open source по завершению и отредактирую статью.
Если вам не понравилась статья, ни за что не подписывайтесь на мой телеграм. Не надо, правда. Ссылка еще в профиле есть.
А вы изобретаете велосипеды в VBA?
Комментарии (37)
caballero
01.04.2023 22:38К vbscript заодно сделайте :)
ArtCapCorn Автор
01.04.2023 22:38Не пишу на нем и не знаю тонкостей, увы) Что за IDE там?)
Robastik
01.04.2023 22:38Запуск менеджера пакетов руками в vba это конечно крайний зашквар.
Что можно сделать:
Открыть, что параллельно vba давно работает jscript и там все значительно более современно. Но ставить надстройки только из магазина мелкомягких не всем хочется.
-
Вспомнить, что офис работает на любом скриптовом языке, который подключается в vba. Питон, vbscript и т.д. vba нужен только для подключения движка этого языка.
Во втором случае код можно хранить в облаке с контролем версий. Управлять им можно из меню Эксель/Ворд , а не из vba.
ArtCapCorn Автор
01.04.2023 22:38+7Я работаю в компании, в которой для того чтобы воспользоваться командой
pip install <foo>нужно создавать заявку, если Вы понимаете о чем я????Да, это печаль, боль. Но вот так.
Поэтому увы эти вещи мне лично не подходят. И поэтому велосипед.
Ну и плюс это интересный опыт.
Запуск менеджера пакетов руками в vba это конечно крайний зашквар.
А как понять запускать руками?
Robastik
01.04.2023 22:38запускать руками
Открывать редактор VBA имелось в виду.
pip install
Это позволяет изменять код в редакторе VBA?
ArtCapCorn Автор
01.04.2023 22:38Это позволяет изменять код в редакторе VBA?
Это я про ненужность велосипедного менеджера и возможность использовать npm.
NAI
01.04.2023 22:38А можно про второй пункт подробнее? А то у меня от VBA и пустого "скрипта" для эксель перевалившего за 5 мб. глаз дергается. А IDE которое не развивается, хочется удалить и забыть, как страшный сон.
Robastik
01.04.2023 22:38Могу поделиться своим опытом.
Использую jscript. Пишу в VS Code. Храню в GDrive. Помогает ейная консольная утилита. Там же менеджер пакетов. Локальная копия для работы офлайн.
Код обновляется по событию без необходимости открытия редактора VBA.
Хранить jscript в standalone gscript project начал потому что там и IDE какое-никакое, и типа аварийный доступ, и что-то вроде линтера. Но наверное все же лучше на гитхабе хранить, если облако вообще нужно для доставки пакетов.
vladkorotnev
01.04.2023 22:38+1Ко второму пункту стоит отметить, что родные интеропы у ворда/экселя дюже медленные.
Давным давно пришлось писать обход каждой ячейки каждой таблицы в огромном вордовском документе — дёргать напрямую апи ворда занимало где-то около получаса на документ; склеить же конкатенацией строк прям в VBA что-то JSON-подобное на весь документ, отдать в скрипт, обработать, отдать обратно, и в VBA по новой Split'ами разобрать и внести изменения в документ — занимало секунды две от силы.
Видимо, сказывается оверхед на каждый COM-вызов, через который эти интеропы работают, а вызовов в таком сценарии выходило огромное количество.
Krasnoarmeec
01.04.2023 22:38Если у вас есть мысли, как сделать совмещение версий в одном проекте, напишите коммент.
Может просто номер версии в название ставить?
Например: "Магнезия 1.0.0.cls" и "Магнезия 2.0.0.cls".
Ну а в аттрибутах класса (Attribute VB_Name = "XXXX") можно либо для каждого класса использовать разные имена (и использовать оба класса, "Магнезия_1_0_0" и "Магнезия_2_0_0" в рамках одного и того же проекта), либо одинаковое, тогда какую версию загрузите, такой и будете пользоваться.
ArtCapCorn Автор
01.04.2023 22:38+1Пока что это единственный вариант который я рассматривал ???? Но тут есть сложность:
Придется открывать каждый файл, редактировать название этой зависимости (а для начала ее найти там). И если это делать обычным
Replace, то боюсь можно зацепить то, что зацеплять нельзя. Поэтому придется городить чтото сложное, а хочется простоты.Возможно этот вариант в итоге и останется, но хотелось бы что-то более неочевидное и при этом такое же простое.
Krasnoarmeec
01.04.2023 22:38+1Я тут медленно и печально пилю свой велосипед (да, я искал для себя альтернативы, но мне они не зашли). Основная идея - для ГитХаб Экселевские файлы это обычные бинарники, отследить изменения которых практически невозможно. К тому же, мои таблички обычно большие (100 Mb и больше). Загружать такое на ГХ только из-за пары изменений в коде - не комильфо. Идея такова, что есть неизменяемый загрузчик (табличка с одной кнопкой "Инсталлировать"), который грузит XML-файлы с конфигурацией листов и все найденные bas/cls/frx - файлы.
MVP в виде таблички там уже есть.
dolfinus
01.04.2023 22:38GitLFS?
Krasnoarmeec
01.04.2023 22:38Хотелось бы видеть реальные изменения в табличке, например: значение в ячейке C3 поменялось с "123" на "345". Буду очень удивлён, если GitLFS может такое.
Gray_Apple
01.04.2023 22:38+3Вбашники всех стран, соединяйтесь. Только не забудьте, что кроме этого вашего эксцеля бывает ещё пара сотен хостов (как слышал). Вот я для корела пишу. Когда я вижу в вба-коде общего назначения вставки чисто из эксцелевской объектной модели, чувствую себя среди вбашников так, как вбашник чувствует себя среди нормальных программистов.
Вот он я если что
https://vk.com/elvin_macro
https://github.com/elvin-nsk
А задумка в целом годная, по крайней мере, я сам задумывался про какую-нибудь систему автоматического обновления, причём не одного файла с макросами, а чтобы с внешними зависимостями. Неудобно все модули в один gms-файл пихать.ArtCapCorn Автор
01.04.2023 22:38+1Немного расстраиваюсь, когда вижу в вба коде вставки чисто из эксцелевской объектной модели
Не расстраивайтесь) просто конкретно я работаю в excel, поэтому других примеров у меня нет ????
Krasnoarmeec
01.04.2023 22:38+3Я не против и всегда открыт для любых вопросов. Тем не менее, ситуация не сильно радужная.
Мы, VBA-шники, народ замкнутый и мрачный, потому что уровень вхождения в язык ниже плинтуса (автоматически записал макрос, сделал вокруг него цикл, и, типа, порядок), а потому и средний уровень макросов по палате близок к поделкам старшей группы детского сада.
Да и сама терминология просто унизительна: на Питоне – программа, на VBA – макрос, хотя оба языка – интерпретируемые и чистый VBA быстрее чистого Питона.
У Питона можно загрузить расширения, а вот чтобы загрузить Add-on для VBA придётся долго лазить по сети. И не факт, что найдётся нужное расширение, и, тем более, что будет работать.
Отдельно добавляют «оптимизма» ежегодные объявления о закрытии VBA и переходе на JS, особенно с новостями, что Office 2021 будет последним, а потом все в Office 365 с его облаками и подписками. Спасибо, конечно, но я хочу (и всегда хотел, даже когда это было не в «тренде») иметь все свои файлы при себе, а не «где-то там».
Хотя, надо отдать Офису должное: то, чем так горды питонисты, Jupyter Notebook, мы имеем с самого начала возникновения VBA (с 1995 года!).
Мои поделки находятся здесь:
Gray_Apple
01.04.2023 22:38+2Не могу лайкнуть - кармы наверное не хватает - но ППКС.
ArtCapCorn Автор
01.04.2023 22:38+1Дал Вам немного кармы на лайк ????больше нельзя, увы
Gray_Apple
01.04.2023 22:38+2Спасибо. На лайк всё ещё не хватает, но вчера подписался на телегу, так что сердцем и душою я с вами :)
starfair
01.04.2023 22:38+1Что вы имеете ввиду под аддонами для VBA? Для среды разработки VBE IDE? Или для самого языка. Под язык априори не может быть расширения, так как он проприетарный и не подразумевает этого изначально. Но у него есть один просто мегаогромный плюс изначально (он же и минус, если следовать диалектике) - встроенная изначально поддержка COM как наверного нигде более не реализованная! Подключай сторонние объекты и твори из под коробки с их помощью что хочешь. И второй очень большой плюс - простая в общем то поддержка dll. Если кто то постарался и сделал описание API (как есть например почти для всего WinAPI и много чего ещё от самого микрософта), то и библиотеками пользоваться можно. Со скрипом, но я например реализовывал рисование псевдо 3d объектов, с помощью функций GDI WinAPI в окне макроса CorelDraw. Работает со скрипом (мерцает окно формы макроса при перерисовке, так как увы, но в WinForms без дизассемблирования нельзя получить hWnd контрола внутри формы, и по'тому приходится принудительно обновлять всю форму), но тем не менее.
Понятное дело, что это всё не какие то особые достижения именно самого языка, но тем не менее, даже до сих пор, столь быстро и удобно набросать код и получить результат именно с использованием стороннего API или COM объектов, в том же Lua или JS, без танцев с бубном не выйдет, насколько я пробовал. В Питон может быть и попроще, но автоматизация на нём тоже не пряник (пробовал писать свои расширения под Blender и был не сказать что в восторге от предварительной работы, чтобы всё более менее удобно было в том же VS Code)
А что до закрытости тех, кто пишет на VBA, так тут вопрос не в закрытости, а в очень узкой специализации данного языка. Просто мало кто им пользуется, если задуматься и соотнести масштабы распространения самого офиса или того же Корела, и число тех, кто при этом использует автоматизацию.Krasnoarmeec
01.04.2023 22:38Под аддонами я имел в виду любые сторонние библиотеки. Да тот же Solver, например. Вот их мало, нет даже места, где я могу поискать подобные библиотеки (а нет, есть, Google называется). Я даже, прикола ради, только что поискал LAPACK для VBA. Нашёл только общие рекомендации скомпилировать сишный код и вызвать из DLL. А если у меня VisualStudio / gcc нет, как тогда?
Закрытость VBA для меня выражается в том, что все копают только в свою сторону. Open source в случае VBA – это разрозненные репозитории и веб-странички, которые сначала надо отыскать.
Узкой специализации VBA я как раз не вижу. Да, большинство использует Эксель для бухгалтерии (им зачастую VBA и не нужен). Использовал его практически для всего (парсинг сайтов через Selenium, обработка звука (wav-файл на входе, wav-файл на выходе), всяческие штуки с матрицами на GPU / CPU, асинхронные вычисления, спецфункции комплексного переменного, вроде функции Эйри).
В качестве псевдокода VBA просто идеален. Можно протестировать любой алгоритм. Но нехватает расширяемости Питона: графики – только какие есть, прямиком из 1997 года, формат самого файла – только бинарный – в ГитХабе изменения не отследишь, сам файл как Jupyter Notebook в ГитХабе не откроешь.
Вот, как-то так. Сумбурненько, но как есть.
Robastik
01.04.2023 22:38нехватает расширяемости
Это непонятно о чем. Несколько направлений для расширений. Сами же признаете, что можно приспособить
практически для всего
Питон в две строки подключается и весь его арсенал ваш. VBA c гитхабом дружат. А то, что xlsx гитхабом не откроешь, так им и банку с огурцами не откроешь, но это же не проблема огурцов.
Графики хоть на d3 стройте, в подтверждение я вот такой график строю
Krasnoarmeec
01.04.2023 22:38Да, графики у Вас супер. Однако стандартные графики в Экселе застыли с 1997 года. Строил графики в 1999 году на Origin – вот это была просто песня! 3D графики Origin определённо рендерил на OpenGL (блики, плавные цвета, цветовую шкалу, освещённость можно было менять). Обычные графики тоже можно было настроить как хочешь – разрывы в осях, например вставить.
Просто смотрю я с точки зрения даже хотя бы и построения графиков на Эксель и слёзы накатываются. За это время (25 лет с 1997) даже JS получил WebGL.
VBA c гитхабом дружат.
Посмотрел первые ссылок 5 – примерно те же велосипеды на костылях, что и у меня. Думал, на самом деле что-то новое придумали, но нет, всё как всегда.
> нехватает расширяемости
Это непонятно о чем.
Попробую ещё раз. Хотелось бы иметь централизованное хранилище для Экселевских расширений. Типа, хочу красивые графики – вот тебе парочка расширений, хочу LAPACK / BLAS или быструю математику – вот тебе ещё парочка, а не искать по кривым закоулкам интернета.
А то, что xlsx гитхабом не откроешь…
Да Вы и сами знаете, что xlsx это зазипованные XML-файлы. Тут буквально рукой подать до Jupyter Notebook. Но, как видите, у Майкрософта руки не дошли. А ведь могли бы.
starfair
01.04.2023 22:38Ну опять же, я не понимаю, что значит любые сторонние библиотеки? Зачем делать то, для чего инструмент не предназначен? VBA вовсе не универсальный язык. Писать на нем в принципе ужасно, учитывая какой слабый IDE используется для разработки. Формы там рисовать ну в принципе ничего, но есть куда более быстрые и удобные инструменты для дизайна GUI. Это чисто инструмент автоматизации другого софта, и не стоит его использовать иначе. Для прототипирования, как псевдокод - ну так себе идея. Тоже потом особо не не перенесёшь так просто. Лучше сразу писать на VB или С#, если уж на то пошло.
Я за много лет, что пишу на разных ЯП, пришёл к выводу, которого придерживаются большинство опытных программистов:
Написать всё что угодно, можно на чём угодно. Вопрос только во времен, силах и упорстве. Но вопрос - зачем? Есть специализированные в своей области языки, вот ими и надо пользоваться в конкретной ситуации. Сэкономишь и время, и силы и упорство не перегорит.
Taraflex
01.04.2023 22:38Искушенный читатель сразу заметил отсылку к другому менеджеру – 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 как есть
Taraflex
01.04.2023 22:38Кто-то для ANSI C даже такое делал https://www.npmjs.com/package/dotc
ArtCapCorn Автор
01.04.2023 22:38Я думал над этим, и по факту это правильное решение.
Но как я уже ранее ответил другому комментатору — я работаю в компании, где
pip install <foo>не работает без сис админа.Описаный Вами вариант так же не будет работать, так как запрос в консоли зависнет на обращении к серверу (приложениям нельзя выходить в сеть, кроме локальной).
Этим и обусловлено изобретение велосипеда (просто так в эту сложную тему я врядли бы полез, есть же готовый инструмент).
VBATools
01.04.2023 22:38+1Привет! всем! VBA-шникам, по делюсь своим решением, только у меня не пакеты а сниппеты, но смысл тот же можно вставлять маленькие кусочки кода или процедуры целиком
сайт надстройки https://vbatools.ru/macro-tools-vba-addin-excel/
GitHub репозиторий - https://github.com/vbatools/MacroToolsVBA
Код полностью открыт, можите менять на свое усмотрение, буду рад вашим предложениям!)
И не большая плюшка, моя надстройка улучшает стандартное IDE VBA - в ней очень много фишек часть описал в статье хабра https://habr.com/ru/post/720806/
Krasnoarmeec
01.04.2023 22:38А я Вас знаю! Подписан, правда руки пока не дошли установить, но выглядит красиво. Вместе с RubberDuck будет отличная связка.
VBATools
01.04.2023 22:38!) Тоже так думал, но отказался от этого, так как RubberDuck по сути ни чего нового не дает, у меня больше функционала, основная функция в RubberDuck - сообщение об ошибках, на больших проекта очень сильно зависает - поэтому уже давно не использую его! Делаю свою надстройку - тем более она полностью на VBA - получается VBA-шник может сам ее менять на свое усмотрение!
asked2return
к последней картинке в прошлом году вышел продолжительный видео-мануал в котором одно сплошное vba
ArtCapCorn Автор
Что за мануал? Не слышал, глянул бы.