Комментарии 15
Хоть это больше реплика, а не статья, но как все точно подмечено! Автор, если ты можешь, пиши в том же духе!
В 98 Винде, "классическим" способом таблица на пару тысяч элементов собиралась минут 10-15, а с отключением прорисовки и через массив - быстрее, чем прорисовывался интерфейс.
Справедливости ради, если человек начинает с обработки небольшого количества ячеек, которым ещё в процессе надо менять внешний вид в зависимости от результата (выделение, шрифт и пр. для удобства просмотра), то обработка этого в массиве сильно усложнит как написание макроса новичком, так и понимание его через месяц, когда надо будет что-то изменить. А выигрш во времени при таких малых количествах будет ничтожно мал для человека. А потом такой макрос будет использован как заготовка для обработки больших таблиц, ведь код уже отлажен. Там недостатки в виде низкой скорости уже будут видны, но писать код фактически заново уде будет лень. Так и идёт.
у среднего офисного макрописца знаний алгоритмов и опыта обычно недостаточно, потому очень много раз видел перебор массив из N 'элементов N-1 раз, причем с увеличивающейся в прогрессии значением N. В таких ситуациях даже небольшое увеличение размеров табичек заметно утяжеляет и замедляет.
ИМХО, единственное разумное оправдание прямого обращения к ячейкам, кроме небольшого объема обрабатываемых массивов - это дать пользователю увидть, что делает макрос и визуально контролировать, если что-то пойдет не так. Когда пользователь видит, что на экране что-то происходит, он успокаивается и умиротворяется.
Для выделения ячеек цветом, чтобы не раздувать код VBA, можно использовать условное форматирование. Настроил один раз и забыл.
P.s. Во многих не-IT организациях вовсю пользуются Office 2007 и даже не думают переходить на что-то другое, ибо он просто работает и свою задачу выполняет...
Дело в том что большинство макрописцев это начинающие разработчики, поэтому в основном вы видите тот код который описали, но поверьте есть разработчики(и не только зарубежные), которые используют и массивы и классы и формы в VBA. Их мало, согласен. Просто те кто с таким подходом пишет код(знает как работать с объектами) не будет работать на той должности и на той зарплате, которую платят VBA разработчику.
Автор смешал в кучу всё: кони, люди. И языки макросов в импортозамещающих офисных продуктах и негативный опыт с сотрудниками, которые не эффективно пользовались VBA. Плюс написано двойственно - из одних высказываний ощущение, что автору 50+, а из других 20+ лет. При этом тема использования классов не раскрыта.
Статья вообще не ставила цель раскрыть тему работы с классами. Я ставил целью популяризовать некоторые методы, которые мне очень помогли в работе и напомнить, что VBA - это, по сути. такой же ОО язык, как и остальные. Сама тема родилась из обсуждения с замдиректора по IT вопроса о переписывании макросов на JS для Р7, в процессе которого мой собеседник открыл для себя. что в VBA есть пользовательские классы. Впрочем, какие темы не раскрыты? Если надо вам подробней про классы - пожалуйста, я вам могу лично ответить на все интересующие вопросы в рамках компетенции, если продвинутому айтишнику, коим вы, несомненно, являетесь, недостаточно широкораспространенных учебников и справки майкрософт. Или, возможно. вы можете сами меня поучить чему-то и рассказать что-то новое про классы в VBA?
Код - он пишется не в вакууме, а в определенных социальных условиях. А этими условиями являются и неэффективно пользующийся инструментом контингент VBA-разработчиков, и импортозамещающие продукты (к вопросу негативный опыт перехода на них не только мой, просто пока что не до всех дошла эта боль) . Актуальность любого технического вопроса зависит от всех этих факторов, и он сам становится интересен только в этом контексте. Если вам неинтересно - то читайте справку майкрософт, ваш выбор.
Ваш комментарий предельно неконкретен, и из него только и можно выяснить, что "баб-яга против". Но то ли она против, потому что с утра лимон сожрала и сидит весь день с кислым видом, то ли имеются какие-то аргументированные доводы - это вопрос за семью печатями. В таком случае проще предположить, что аргументов все-таки нет, потому что их действительно в комментарии нет :).
Lua как "замена" в "Моём офисе", это вообще нечто, лежащее за гранью добра и зла. Я тут под НГ собеседовался в один наш очень крупный банк на импортозамещение из MS Office в "Мой Офис", как раз по вопросу переноса их зоопарка макросов из VBA в Lua. Когда ознакомился предварительно, понял, что сказать что в Моём офисе всё печально - это ничего не сказать! Бредовая идея разделить нормальную среду макросов на макросы и надстройки, приводит к тому, что макросы с формами перевести в нечто похожее в "МО" почти нереально. Нет возможности создать надстройку с множеством форм. При этом, нет элементарных вкладок на одной форме. И это в 2023 году, Карл!
Да фиг с ним, нет элементарно возможности в их таблице вызвать макрос через =ИмяМакроса(аргумент), хотя уж казалось бы - ну это то как не внедрить, если вы пытаетесь хоть как то своим продуктом заместить импортный офис!?
Короче, не взяли из-за слишком большого опыта с моей стороны (уж не знаю, чтобы этого значило), но наверное и слава богу! Искренне не завидую тем, кто сейчас этим занят!
да, вот сейчас сижу и смотрю, что я смогу сделать в P7, чтобы у меня макросы так же работали. Кроме ограничений самого JS еще и ограничения API - например, по индексу к ячейке не обратиться. Дергать API приложения- это вообще не самая лучшая идея. Где у них контролы и как подрвязать макрос к событию я пока что не обнаружил, задокументировано оно совсем не очень. На кого рассчитано все это совсем не ясно - на профессионала-разработчика? возможно, но уж точно не на пользователя с некоторыми навыками программирования. Посмотрел курсы в сети - вообще нет, никто этой фигне не учит. Типа, разберись сам или делай руками.
А LUA в Мой Офис - это что-то запредельное и не для людей написано. За эти вполне очевидную идею меня тут как-то заминусили до -30 тусующиеся здесь работники МоегоОфиса :) Там большая часть объектов вообще доступна только через С.API, а сама документация на описание методов - это редкостное убожище. Там просто нормальный макрос написать, который будет обрабатывать выделенный диапазон - еще тот квест. Макрорекордер не только не помогает, но активно мешает понять, что там у них с объектами и методами. Как обратиться к выделенной области я так и не нашел. Про надстройки я и не говорю. Я просто бросил попытки раньше, чем дошел до создания надстроек.
У меня есть вполне четкое ощущение, что компании, импортозамещающие мелкософты, либо просто имитировали наличие макросов. чтобы формально пройти через требования госторгов, либо сознательно затруднили норммальному человеку вход в эту область, чтобы потом сесть на разработку пользовательских макросов ради дополнительного профита. Их может оправдать только если они действительно криворукие и обладают извращенной логикой, а проекты пилили из принципа "лишь бы не как у Майкрософт". Компании никак не развивают среду - нет ни профессиональных форумов\соцсетей по макросам в их продуктах, нет ни нормальных учебных пособий и описаний. Мы все ругаем справку мелкосовта, но даже по сравнениею с описанием API от P7 справка MS ясна и понятна как расписание электричек в сравнении с предсказаниями Нострадамуса.
Делал нечто похожее со своей системой классов и отображением их в таблицы.
Сперва с обращениями как у автора, Cells(count, 6) , потом столкнулся с тем, что довольно часто возникает необходимость поменять структуру таблицы - добавить, убрать столбец, поменять местами. Чтобы не переписывать при каждом изменении все номера столбцов в таблице с почти 100 столбцами, переписал обращения на обращения по имени столбца, вида
BOM_Table.ListColumns("Product").DataBodyRange.Rows(pos) = formulation
По ходу прикрутил перевод всех таблиц (заголовков, данных в определенных столбцах, списков и т.п.) в файле на несколько языков, чтобы каждый пользователь мог выбрать свой язык, а я бы мог подгружать это в единую сводную таблицу - считывая язык конретного языка и делая автоматический перевод в язык сводной таблицы.
Большой геморрой для мультиязычности доставляет отсуствие поддержки юникода в среде разработки, когда невозможно просто записать строку, а приходится конструировать ее из шестнадцатиричных констант и функций вида ChrW$(Hun_as).
очень интересный опыт. Я, правда, проблему динамических столбцов решал через объект Dictionary, потому что там просто достаточно ключа (заголовок) и номера столбца в качестве Item'а. Но вообще, если там не только столбцы, но и еще какая-то информация (например, таблиц на листе несколько с одинаковыми заголовками столбцов, например, то да, будет достаточно удобно создавать классы определенного типа и загонять в них подобную информацию. . Если будут еще задачи, учту ваш опыт, еще раз спасибо. ,
Со своими пользовательскими об'ектами-таблицами я тоже игрался когда-то. Сделал свой библиотеку классов, описывающих важные для меня параметры столбцов (название, тип данных, раскраска, шрифты,...), об'единял их в динамическую коллекцию-таблицу и при запуске файла мапил это на реальную экселевскую таблицу. В результате вся структура/типы/данные актуальной таблицы у меня считывались и записывались без моего вмешательства.
Но это имеет смысл для больших таблиц, которые обрабатываются как-то нелинейно. Чаще (по крайней мере у меня) все же встречается построчная обработка и особого выигрыша от этого нет, хватает того, что я писал выше.
Как я использовал-таки классы в VBA и даже полюбил это дело