Комментарии 50
Есть и другие причины использования VBA. В корпоративной среде (чем крупнее компания - тем запретнее) пользователям запрещено ставить ПО разработки, а сами ИТ не хотят что-то автоматизировать и тогда бизнес-пользователю с навыком программирования (или без, но с желанием) приходится использовать лишь то, что есть на его рабочем месте (инструменты разработки).
Поэтому, чтобы самому себе помочь (даже не по инженерным задачам) приходится использовать то, что есть на каждом ПК: VBA, JS (браузерный), bat. Подобную проблему \ решение читал и в западных историях.
Самое главное достоинство VBA - низкий порог вхождения!
Включил макрорекордер на запись
Сделал что нужно используя пользовательский интерфейс
Остановил запись
Допилил напильником код для повторного использования
PROFIT…
Пункт 4 как раз требует достаточно приличных знаний. Ибо макрорекордер ну просто хлебом не корми - дай на Selection опереться. И именно по этой причине сплошь и рядом записанный макрос то работает как надо, а то такого наворотит, что всемером не разгрести. А всего-то юзер случайно мышкой кликнул...
Пункт 4 как раз требует достаточно приличных знаний
Понятное дело, что прям сразу на пользователя не свалится готовое решение в виде кода)
Выпускники технических ВУЗов и даже тетушки из бухгалтерии вполне в состоянии с этим разобраться...
Еще из плюсов VBA, что пользователю можно пользоваться системными константами (Enumerations), того приложения под которое пишется код.
что есть на каждом ПК: VBA, JS (браузерный), bat.VBA зависит от наличия установленного офиса, а вот VBScript точно из коробки имеется.
Простите, но как Ваш код на VB.NET решает описанные в тексте применительно к C# проблемы? Куда Вы его предлагаете пользователю "скопипастить в docx-документ", ведь в VBA используется классический VB, а не .NET? У Вас получилось ровно то же самое решение, что можно было бы сделать на C#, со всеми его недостатками, только с другим синтаксисом. А чтобы реализовать это же на VBA, код надо переписать под другую версию языка.
Сталкивался с подобной автора проблемой, но для автоматизации на CorelDraw. VB в целом более "толерантен" к изменениям API, нежели С#. Почему - не стал разбираться, ибо просто не было особой нужды. Но в целом - факт остаётся фактом, на VB (а тем более на VBA) "проще" что то написать и поддерживать, если требуется создавать некий прикладной код на зоопарк версий.
Конкретно в этом случае проблемы с совместимостью assemblies (если они есть) будут на уровне .NET, независимо от того, на C# или VB.NET написан код. Без необходимости тащить пользователям бинарник (EXE или надстройку) тоже не обойтись.
Объём работы, необходимой для переработки этого кода с VB.NET на VBA я не оценивал, но как минимум это не copy&paste.
P.S. Да и несуществующий (увы) VBA.NET в тегах намекает, что автор немного запутался...
Может быть и так. Хотя, как я понял, скорее речь идёт о неких универсальных наборах интерфейсов для VB.NET, благодаря использованию которого можно отвязаться от использования для работы с документами непосредственно exe самого офиса. Тогда проблема уходит использования кода завязанного на assemblies, а значит и проблема с изменением API от версии к версии. Просто пишешь своё приложение, которое на VB пишется в общем то легче, по сравнению с кучей особенностей C#, и получаем для своих задач некую тулзу, работающую с общераспространнёным форматом офисных файлов.
Что C#, что VB.NET компилируется в .NET IL, на чём вся разница между ними исчезает. Так что выбор VB.NET может быть обусловлен тем, что он кому-то проще/привычнее, но не более.
А вот VBA - совсем другая история.
Я не великий специалист по VB.Net, но насколько я помню этот вопрос, тут дело скорее в простоте работы с ActiveX в плане загрузки и манипуляций, так как там всё работает примерно так же как и в VBA. Поэтому, не так важно во что превращается код после компиляции. Важнее то, насколько просто начинать и поддерживать работу по автоматизации. В С# контроль за всей этой историей куда строже, и поэтому код там уже куда сильнее будет привязан к конкретным версиям используемых объектов и их интерфейсов, нежели в VB
Нет, Вы как раз пишете про классический VB (версий до 6 включительно), который работает с COM (ActiveX), и на базе которого построен VBA.
А VB.NET построен на платформе .NET и с внешними зависимостями работает ровно так же, как и любое приложение, написанное на любом другом .NET языке. Поэтому и итоговый бинарник будет точно так же привязан или не привязан (тут я предположения автора подтвердить или опровергнуть не могу, сам не сталкивался) к версиям, как если бы он был написан на C#.
Ну, может и так. Хотя, глянул сейчас вот немного порылся по этому поводу, и собственно отчасти соглашусь, отчасти всё равно сложилось впечатление,что VB.Net менее требователен в плане работы с кодом ActiveX компонентов. Хотя, опять же - спорить не буду. Может автор и правда использовал VB именно из-за очень большого сходства с привычным по MS Office и сравнительно простым VBA.
Согласен, Вы правы. Подправил. Речь именно про VBA.NET
VBA.NET? Это что за зверь такой?
https://ru.m.wikipedia.org/wiki/Visual_Basic_.NET
Вот этот)
Ведь по факту я писал программку с использованием именно его
Смотрите, код VBA.NET помог мне избавиться от тех ошибок, которые выскакивали в момент использования C# и необходимых пакетов. Я согласен, что данную задачку можно и на C# легко осилить, но лично на моем ПК вылезли те ошибки, что я привел (у меня как раз crack).
По поводу сравнения VBA.NET/VBA: Вы думаете, что синтаксис будет и внешний облик кода отличаться кардинально?
Во-первых, никакого VBA.NET не существует (а очень жаль).
Во-вторых, синтаксис будет отличаться. Степень кардинальности не знаю, в каких попугаях измерить, конечно. Но это точно не уровень "скопировать код в документ". Можете последовать собственной рекомендации, скопировать Ваш код в VBA-редактор Office и посчитать количество ошибок :)
И прежде всего, отличается сам механизм взаимодействия с вшеними компонентами. В VB.NET Вы ссылаетесь на .NET Assemblies, в VBA - используете COM-компоненты. Скажем, Вы используете DocumentFormat.OpenXml. Есть ли аналог этого пакета для COM, который можно использовать в VBA? Не знаю, может и есть, но из установленного по умолчанию точно ничего не находится.
Смотрите, код VBA.NET помог мне избавиться от тех ошибок, которые выскакивали в момент использования C# и необходимых пакетов.
Вот вы использовали пакеты DocumentFormat.OpenXml.* в вашем "VBA.NET". Почему вы даже не попытались использовать их же в C#?
Или вот вы пишете что у вас заработал Microsoft.Office.Interop.Excel в вашем "VBA.NET". Но это абсолютно тот же самый Microsoft.Office.Interop.Excel что и в C#, который у вас, якобы, не работал.
Или вот упомянутая вами проблема с отсутствием .NET, который вы решили… как-то. Почему вы даже не пытались применить то же самое решение для C#?
Как Vsiual Basic отлично помогает решать инженерные задачи
Возможно не все в курсе, но... Visual Basic - самый страшный язык программирования по мнению пользователей Stackoverflow
Ну не знаю, как по мне язык и язык, что-то в нем удачного есть, что-то устаревшего, что-то не очень удачного. Он вполне решает проблемы для офисного ПО, но в то же время он не оптимизирован на многопоточность (VB6.0 это конец 90х, когда о многопроцессорности/многоядерности можно было только мечтать, хотя материнские платы на 2 сокета уже тогда были, а вот HT еще нет)
Visual Basic — самый страшный язык программирования по мнению пользователей Stackoverflow
было бы забавно послушать аргументы
VB (который 6.0) вполне себе рядовой язык по нынешним меркам, я бы даже рискнул его с питоном сравнить по отношению к типизации и по наличию основ ООП, что в нем такого "страшного", опятьже, опираясь на день сегодняшний, мне сложно придумать
когда я еще в школе учился, в огромный недостаток и минус ему приписывали возможность (причем отключаемую) динамической типизации
Сейчас потихоньку заставляют переходить на иностранное ПО, судя по всему тут или перспектива макросы писать на StarBasic, т.к. LibreOffice идет почти в каждом линуксе из коробки, или есть еще из реестра одинаковый с лица AlterOffice. Либо переходить на python, но с ним много подводных камней в корпоративной среде, хотя бы потому что его надо ставить...
Другие российские офисы не позволяют работать макросом с диском, т.е. открыть/записать файл, МойОфис отличился с LUA, макросом нельзя даже получить системное время и дату. Чуть получше с JS у Р7, но по факту все так же ни кнопку создать и макрос к ней привязать, ни файл открыть/записать/закрыть на диске.
Правда есть еще одна тенденция, т.к. большинство офисных файлов это типовые акты/бумаги, которые постепенно переводят в открытый проприетарный формат XML, то может все это офисное ПО лет через 10 станет анахронизмом?
Хм, а что разве в поставке Lua "МойОфис" отключили os.date() os.time()?
Согласен, выбор Lua для автоматизации спорен, но имеет и собственно большой плюс в том, что очень многое можно расширить за счёт загружаемых налету модулей, в том числе и бинарных. Так что, в теории можно даже своё GUI припилить, вместо убогого родного. Конечно внутренний API по работе с документами там довольно убогий, на фоне MS Office, но для 99% офисных работ по тексту и таблицам вполне должно хватить, если не брать что то очень извращённое.
Хм, а что разве в поставке Lua "МойОфис" отключили os.date() os.time()?
проблема в том, что os.time() здесь не работает, а при использовании DocumentAPI.DateTime из инструкции макрос выдает ошибку: либо nil, либо пусто, если прописать его в переменную с конвертацией типа в текст.
Так что, в теории можно даже своё GUI припилить, вместо убогого родного. Конечно внутренний API по работе с документами там довольно убогий, на фоне MS Office, но для 99% офисных работ по тексту и таблицам вполне должно хватить, если не брать что то очень извращённое.
Я в прошлом году тестировал несколько офисов на скорость чтения/записи в ячейку и работоспособность кое-каких решений... В общем МойОфис был самым медленным, они, с тех пор, допилили код, но все никак не дойдут руки посмотреть как и что там поменялось
https://habr.com/ru/articles/674580/
но для 99% офисных работ по тексту и таблицам вполне должно хватить, если не брать что то очень извращённое.
Мне как раз нужно изощренное - передавать данные из одного файла в другие в пакетном режиме
проблема в том, что os.time() здесь не работает, а при использовании DocumentAPI.DateTime из инструкции макрос выдает ошибку: либо nil, либо пусто, если прописать его в переменную с конвертацией типа в текст.
Специально полез и проверил. Вполне себе работает.
begin_pos:insertText("Текст в начале строки")
begin_pos:insertText("Второй параграф")
begin_pos:insertText("Дата и время создания" .. os.date())Выводит такое вот в документ:
Про os.time() - так оно выводит в мс от даты 01.01.1970 00:00 и требует пересчёта (формула довольно большая, но вполне себе общедоступная). Чтобы получить время в общепринятом смысле, надо задавать формат вывода в os.date("%H:%M") Подробнее можно в руководстве глянуть
Что касается DocumentAPI.DateTime - так это просто формат данных, который используется внутри специального сервиса отслеживания изменений документа, и как я понял, отдельно его использовать не удастся
Я в прошлом году тестировал несколько офисов на скорость чтения/записи в ячейку и работоспособность кое-каких решений... В общем МойОфис был самым медленным, они, с тех пор, допилили код, но все никак не дойдут руки посмотреть как и что там поменялось
Ну, тут спорить не буду. Почитал вашу статью. Я ещё так глубоко в работы именно с таблицами в МойОфис не зализал, но сдаётся мне, вы просто не настолько глубоко углубились в тему Lua, поэтому и может быть, использовали автоматизацию не совсем так, как предусматривали это разработчики. Хотя да - там всё сложно, и похоже что автоматизация там сделана для "галочки" и толком его развитием никто не занимается. API крайне слабое и неполное. Описание тоже мягко говоря оставляет желать лучшего.
Мне как раз нужно изощренное - передавать данные из одного файла в другие в пакетном режиме
Так вроде особых проблем нет, хотя конечно не знаю что вы конкретно имеете ввиду. Средствами офиса через API и читать, и создавать и сохранять файлы (правда, это в основном только в формате самого МойОФис)
Ответ службы поддержки год назад
Так вроде особых проблем нет, хотя конечно не знаю что вы конкретно имеете ввиду.
На VBA я передаю данные из ячеек в основном файле в файлы шаблоны, для Word формата через закладки, для Excel через метки в тексте, который парсится перебором (да может не самый оптимальный вариант с т.з. быстродействия, зато наглядный для человека который этим пользуется) Соответственно мне нужно то же сделать и здесь - привязать ячейки таблицы к меткам в шаблонных файлов что бы затем эти данные запихнуть в файлы по число строк/столбцов подготовленной таблицы данных. Об этом я писал ранее на Хабре
https://habr.com/ru/articles/344956/
https://habr.com/ru/articles/359218/
Вот так это выглядит на практике, то что хочу переписать
А! Ясно!
Я макросы вообще не рассматриваю как средство автоматизации! Я пробую из надстроек. Так всё работает. Макросы это вообще изврат в исполнении разработчиков, так как их нельзя в тех же таблицах вызвать по имени в формулах тех же таблиц. Нельзя привязать к какому нибудь контролу в документе (их в тексте документа опять же просто нет). А работа вручную - такое себе удовольствие! На моё недоумение, мне в службе поддержки сказали что такого в планах нет.
На VBA я передаю данные из ячеек в основном файле в файлы шаблоны, для Word формата через закладки, для Excel через метки в тексте, который парсится перебором (да может не самый оптимальный вариант с т.з. быстродействия, зато наглядный для человека который этим пользуется) Соответственно мне нужно то же сделать и здесь - привязать ячейки таблицы к меткам в шаблонных файлов что бы затем эти данные запихнуть в файлы по число строк/столбцов подготовленной таблицы данных. Об этом я писал ранее на Хабре
Скажу честно - пробежался вкратце, но я как раз занимался недавно схожими задачами. Правда, более касаемо в разрезе просто внутренней документации проектной организации. Пилилось схожее на специализированом отечественном ПО под названием "Lotsia". В плане программирования чего либо в нём - сущий ад и "мойофис" во многом может показаться ещё и ничего. Но в плане как раз схожих задач по генерированию чего то схожего с описанным - там есть довольно много уже автоматизированного. Но рекомендовать не буду, ибо реализация проектной СЭД там отвратная, как по мне. И я смотрю, что никто так толком ничем у нас в стране заниматься особо не спешит, ибо при отсутствии альтернатив, "программисткие ёжики будут плакать, ругаться, но всё равно лезть на кактус". То есть или пользоваться с матами то чем дали, или изобретать велосипеды каждый на своём рабочем месте.
Я пробую из надстроек. Так всё работает. Макросы это вообще изврат в исполнении разработчиков, так как их нельзя в тех же таблицах вызвать по имени в формулах тех же таблиц.
Почему нельзя? Можно, только объявляешь не declare sub, а declare function, при этом функция может что-то возвращать, а может и нет, тут как сам код пропишешь/настроишь.
Нельзя привязать к какому нибудь контролу в документе (их в тексте документа опять же просто нет)
Почему? Вставляем кнопку на лист/документ и вперед, если сильно заморочиться, то можно даже в контекстное меню засунуть в офисе или в ленточный интерфейс, который будет работать только при открытии определенного файла, я сейчас не про написание надстроек, хотя там частично пересекается тема. Еще можно замоделировать всплывающее окно с любым интерфейсом на базе стандартных форм. В общем есть множество инструментов и вариантов запуска макроса и оптимизации юзабилити его использования.
"программисткие ёжики будут плакать, ругаться, но всё равно лезть на кактус". То есть или пользоваться с матами то чем дали, или изобретать велосипеды каждый на своём рабочем месте.
Собственно это та задача которая должна решаться макросами, а в современных российских офисах с этим все печально. Либо пишется ПО которое подменяет, в узкоспециализированном секторе задач, офисное ПО... а дальше.. система же не может остановиться, она или развивается или деградирует. Поэтому, как по мне, именно такая автоматизация рутины нам и нужна, без фанатизма.
Ещё раз, чтобы не было недопонимания - я вам написал про МойОфис и ваши старания в нем, а не про MS Office/
Тогда прошу пардону. по МойОфис у меня у самого, как я писал выше, много вопросов на которых нет ответа, из-за чего его не могу рассматривать как альтернативу для себя и своей команды в разработке ПО в рамках малой автоматизации оформления документации в стр-ве. Увы, LibreOffice тут безусловно выглядит более предпочтительным вариантом, хотя тоже не идеальным
Абсолютно согласен, что с python есть великая проблема потому, что его надо ставить. Лично постоянно встречался с таким в инженерной сфере
Я подобную рутинную задачу решил написав надстройку для Excel с помощью библиотеки Excel-DNA. У меня входные данные только Excel файлы правда, но парсер можно и вордовских написать, без проблем. Так реализовал экспорт спецификации в девятиграфку в dwt например. Тут же импорт другой будет.
Код на VB ваш в Excel-DNA тоже можно адаптировать. .NET же
.NET кстати на машине целевой возможно и есть, но рантайма нужной версии нет.
Забавно. Тоже надо было повозиться с чужими большими таблицами, а вспоминать VBA было лень. Ну и из Powershell вылезать тоже лень.
$xl = New-Object -COM "Excel.Application"
$xl.Visible = $true
$wb = $xl.Workbooks.Open($InputFile)
#select first sheet
$ws = $wb.Sheets.Item(1)
...
$objRange = $ws1.UsedRange
$xlCellTypeLastCell = 11
$objLastcell = $objRange.SpecialCells($xlCellTypeLastCell)
$lastrow = $objLastcell.row
$lastcolumn = $objLastcell.column
В общем, оказалось, что почти всё можно ненапряжно делать из любимого PowerShell - тут хороший набор подсказок.
- тут хороший набор подсказок.
К сожалению в вашем комментарии ссылка не рабочая! Не могли бы вы продублировать ?
Похоже что-то в движке Хабра сломалось. Вчера ссылка работала:
https://www.myfaqbase.com/q0001773-Scripting-Powershell-5-0-Working-with-Microsoft-Office-Excel-part-1.html
Писать приложение на VB.NET для системы, где dotNET отсутствует... Сильно... Для WinXP? Т.к. начиная с Висты dotNET ставится с ОС по умолчанию.
Не проще ли написать надстройку на VBA, к-рая не создаст никаких проблем на ограниченном аккаунте?
Вы уверены, что платформа идет с ОС по умолчанию? На целевом рабочем ПК возникала ошибка «отсутствия .NET», пока я не «опубликовал» решение и не получил setup.exe
Если .NET отсутствует, разве не завернет setup.exe при установке приложения на целевой ПК необходимые компоненты?
С точки зрения ограниченности аккаунта, такое может быть проще. Но в моем случае проблем с установкой не оказалось (именно скомпилированной проги)
Вы уверены, что платформа идет с ОС по умолчанию?
Посмотрите в папке, C:\Windows\Microsoft.NET\Framework64\*version* , там должен быть файлик csc.exe, наведите на него мышкой и посмотрите что за подсказка всплывает.
По идее, с новыми версиям Windows должна по умолчанию идти какая-то версия .NET FW. Вот тут галка рядом с версией - должно быть установлено по умолчанию как компонент системы.
У Вас сборка под .NET Framework 4.7.2, который идёт в комплекте с Win 10 v. 1803 и выше.
Вы уверены, что платформа идет с ОС по умолчанию?
Да, начиная с Висты.
Очень странный выбор.
По мне "1 выбор" это работа в vba , старом классическом и встроенном.
Плюс отсутствие зависимостей и встроенность.
Если выбирать из .Net то я однозначно за C#. Просто по одной причине - документации и примеров по нему в 10 раз больше чем по VB.NET.
Еще очень популярный метод работы с word/excel это COM - его плюс это возможность работать с файлом, открытым у пользователя. То есть, интерактивность. Часто эти плюсы превышают минусы.
Как Visual Basic.NET отлично помогает решать инженерные задачи, связанные с Word и Excel