Комментарии 22
Кто-нибудь может пояснить в чем смысл интеграции C# в сравнении с уже существующей штатной возможностью использования кроме VBA любого скриптового языка, например питона, с уже готовым менеджером пакетов? В чем смысл встраивать в Эксель IDE в сравнении с возможностью использования любой самостоятельной? В чем смысл платной надстройки для извлечения данных в сравнении с штатной Power Query?
Думаю, основная магия Excel и с Alt+F11 (VBA IDE) - это Макрорекордер. Если разместить эти два окна рядом или на 2-х мониторах - КПД повышается в 2 раза. Трансляция в реальном времени каждого клика в код позволяет не изучать API и огромную объектную модель Excel, а просто скопипастить код из VBA в любой другой ЯП. И это дорогого стоит. Плюс сам Excel - это счастливый билет в программирование "для себя". Поэтому смысл любых интеграций - есть, даже с приходом экосистемы Jupyter-блокнотов и Python+Pandas, несомннено, начавших новую эру в работе с табл. данными.
Excel остается самым популярным и многочисленным бизнес-ПО, и макросы в нем - это тоже микро-приложения. В продакте Excel+VBA делает самое важное, страшное и секретное, что не снилось 1С-среде и тем более другому ПО с "аудиторским следом".
Я могу назвать лишь одну сферу деятельности, где макросы настолько же упростили/усилили труд, как это сделал VBA: труд музыканта, аранжировщика, звукорежиссера в DAW Reaper. Там тоже "россыпь" ЯП: JSFX, EEL, Lua, Python, C++. И тоже IDE, которая в реальном времени(!) обрабатывает звук и управляющие сигналы. И ЯП тоже 100% покрывают API программы. И музыканты лезут в окно IDE и пишут код, потому что большую часть их ТЗ быстрее накодить самому, чем сформулировать для кого-то.
Ну, так же прекрасно расширяются возможности материнской программы схожим образом в SolidWorks (один из самых популярных САПР) или в CorelDraw. Покрытие может и не 100% но очень близкое к нему, и при этом - сравнительно быстрый набор и отладка для специфических задач, и как вы верно заметили - возможность изучить внутреннюю кухню материнского ПО в режиме реального времени (ну почти), с последующим анализом API и расширением своих возможностей за счёт мощной автоматизации рутинных процессов.
Вот недостаток условного питона у меня был один: он сам как пользователь открывает книгу. То есть обновлений, умных сортировок, кнопок внутри экселя он не умеет. Пользователь должен закрыть файл, запустить файл, открыть файл.
Открывайте книгу через com Экселя и пользуйтесь всеми возможностями объектной модели.
Через COM работают Python-либы PyXLL и ExcelWings, реализующие доступ ко всему API. Microsoft в 2015 г. грозилась интегрировать Python в Excel, на маркетологи убедили что PB/PQ/DAX/M-направление даст больше денег, и работы свернули.
Другие python-либы, работающие с MSO-форматами и при отсутствии MS Excel - xlrd, xlwt, xlsxwriter, openpyxl (и еще с ~10) - слабее. Некоторые могут вставлять формулы, вычислять их и вставлять предвычисленные значения (чем не обновление?), добавлять имена, диаграммы, подписи, VBA-модули итд. То есть предсказуемо менять файл при последующем открытии в MS Excel. Но обновить "сводную" или переопределить "умную" Т. - они не могут. Но такое ограничение и разделение вполне логично и в рамках философии СПО. Ведь собрать и обновить сводную/умную заново с помощью Pandas часто быстрее, проще и дешевле, особенно если надо с данным сделать нечто большее. МСБ с 2008 г. обез-Excel-ивается довольно спокойно, процесс идет, монополии и "безвыходности" уже нет.
безусловно, микрософт могла бы без проблем заменить визуал бэйсик в эксель на Си Шарп. Однако, отмечу бэйсик сейччас хорошо интегрирован в эксель, на нем кмпактно записываются скрипты того, что выполняет юзер мышкой и клавой сразу в готовую работающую пограмму. Кажется, придется приложить не мало усилий, чтобы повторить этот генератор кода на Си Шарп. Также хороша интеграция с SQL и лично у меня получается намного компактнее чем на Си Шарп и интеграци со сводными таблицами тоже отличная. Но все весма реально переделать на Си Шарп. Почему микрософт этого не делает - большая загадка.
Мне думается, что они просто не видят в этом смысл. Для серьёзных расширений предполагается написание аддонов, на любом из современных ЯП (С#,C++,Phyton и т.д.) Для текущих быстрых задач возможностей VBA даже в том уже устаревшем виде, как говорится "за гланды". Мне кажется странным скорее, что они прекратили мало того что развитие VBA, но и даже продажу новых лицензий для интеграции в ПО других разработчиков. Сам по себе конечно VBA ущербен, как современный ЯП, но в плане автоматизации рутины - он как по мне до сих пор не имеет аналогов.
Неожиданно! Какие люди! Сам великий и ужасный Fred Guitarist! Добро пожаловать на Хабр!
Обращаю внимание, что это не авторская статья - а перевод - и автор разработки не из РФ - так что тут могут быть нюансы с использованием и поддержкой (учитывая что для коммерческого использования (для разработки) систему надо приобретать, и даже для комьюнити нужно регистрироваться на "бизнес" e-mail
А в остальном отличная статья (перевод) - отличная разработка, хоть более интересная C#-программистам, чем кому-то ещё (но готовые расширения могут быть далее использованы кем угодно, без каких либо особых навыков) - для других безусловно есть стандартные решения от Микрософт - уже упомянутый Power Query и Power Bi, Power FX, и некоторые другие - хотя синтаксис C# LINQ лично мне достаточно приятен; как и кажется вполне приятным общий UX данной разработки
Как работавший (боком) со сложными таблицами Excel, в которых было много макросов, могу сказать, что не видел ни одной таблицы, которая подходила бы под определение "сторого типизированная коллекция", то есть как таблица из базы данных. Всегда было форматирование, разные области данных, кнопки, нетривиальные связи между ячейками и так далее. То есть, таблица Excel - это не коллекция записей, а сложный документ. Поэтому предлагаемое решение было бы неприемлемо в том проекте. Но может, где и сгодится..)
P.S. Так же делали сервис на C# для автоматизации Excel, через COM-automation (для авто-тестов). Работал наш сервис очень криво, там много подводных проблем.
Как-то все очень громоздко. Целая IDE для скриптов.
Работаю с библиотекой ExcelDNA. Все пишется на C#, доступен COM, все объекты с которыми можно работать через VBA. В студии проект собирается в xll файл плагина Excel, который достаточно положить в нужную папку на компьютере пользователя и включить в настройках.
Если кто не знает - в статье не заметил этого факта, - к листам экселя как к таблицам можно обращаться через SQL даже из этой же Workbook в макросе при помощи MS ADO. Делал такое 10+ лет назад. Чревато получением "Out of memory" - но мне в текущей работе эта возможность сильно помогала.
ЗЫ Ух, даже нашёл привет из 2011-го)
Теперь аргумент нашей преподавательницы что ВБА крутой и вообще как по другому в Excel наконец то разрушен, респект за проделанную работу!
А можно также но в 1с?
C# как замена VBA в Excel