Было бы интересно узнать мысли автора(ов) этого монстра) ну в смысле: зачем/почему/что мешало и тд
Бывают просто забавные ситуевины, когда ты чувствуешь потенциал, хочешь его раскрыть, а тебе говорят «нет, батенька, excel и не более, не надо нам ваших C#/Java/C++ etc.»
Конечно, соглашусь, очень сложно поддерживать большие проекты, как минимум из-за невозможности структурировать файлы. Когда открываешь большой проект и видишь просто кучу модулей, становится немного страшно. Ситуацию немного помогает исправить Rubberduck, но это особо ничего не меняет.
Плюс, как тут уже заметили, Excel очень любит ни с того ни с сего в любом месте выполнения отлаженногоприложения макроса просто упасть и все, без объяснения причины. Поэтому да, скорее это извращение.
Но черт возьми, мне теперь интересно глянуть на этого монстра?
Конечно есть свои массивы. А еще есть коллекция. Но можно же и без нее, просто на массивах все делать, верно?
Ладно, возможно не совсем уместный сарказм, но я вот какую мысль хочу донести.. mscorlib это динамически подключаемая библиотека, верно? Верно. Ровно такая же, как и scrrun (Scripting runtime, в составе которой FileSystemObject и Dicrionary, так горячо любимые всеми VBAшинками). Возможно Вы скажете ими тоже не стоит пользоваться по причинам производительности? Тогда точно останутся одними массивы да коллекция, с которой не особо удобно (ну лично мне, возможно кто-то со мной и не согласится) работать, т.к. ключ/значение в нее добавлять можно, а проверить наличие ключа (встроенными средствами) нет, приходится изворачиваться. Метод извлечения списка ключей/значений? Не, не слышал. Про FSO вообще молчу, стандартные функции для работы с файлами крайне скудны. Я пробовал принципиально ими пользоваться, тяжко.
Если не использовать тип Object, а пользоваться ранней привязкой, то конечный клиент может словить интересные ошибки (ну не поддерживают VBA, куча багов в нем, которые никто уже не исправит). Поэтому только поздняя привязка, поэтому только через тип Object, хоть мне поначалу это дико не нравилось и я пытался продвигать раннюю привязку, но после нескольких обращений от клиентов о том, что у них что-то не работает из-за этого (даже, казалось бы, такие родные либы Word и Outlook), пришлось смириться.
Это я все к чему? Все эти библиотеки и прочее - они ведь сделаны для удобства программиста, чтобы ему не нужно было сотни раз переписывать один и тот же код и можно было пользоваться уже готовыми и проверенными решениями. Да, порой они дают маленькую просадку в плане производительности, но, наверное, иногда можно пожертвовать этими нано-миллисекундами в угоду удобства, читаемости кода (возможно я и не прав, но это сугубо личное мнение). В VBA и без ArrayList кучу всего приходится писать самостоятельно, что в других языках решается подключением какой-либо библиотеки.
Задача, приведенная в статье, просто пример который пришел в голову. Возможно решение не самое действенное, но наглядно показывающее как можно упростить задачу. А ведь бывают задачи, когда нужно работать именно с массивом (да что там бывают, вечно есть).
Согласен, встроенные возможности Excel чаще гораздо удобнее, чем сочиненные самостоятельно, но их все таки часто не хватает.
На самом деле, при должном подходе, мне кажется вполне возможно и что-то более серьезное наваять. Но кто бы умел в этот должный подход. (Не претендую на знатока, но пытаюсь как-то туда идти)
Думаю подавляющее большинство VBA-программистов — люди, которые пару раз юзали макрорекордер и в лучшем случае научились объявлять переменные. Но статистики у меня нет, поэтому это лишь домыслы.
Думаю, вам будет интересно таки поглубже изучить классические структуры данных
Если речь о hash-таблицах и т.п., то поверхностно ознакомлен. Сильно глубоко не вдавался, т.к. пока не вижу как таковой нужды в плане применения (аналог тех же hash-таблиц в VBA — Dictionary, если я правильно понимаю).
ожидаешь хотя бы пару слов о сложности операций (в идеале в O-нотации)
По оценке сложности операций я не силен. В VBA подобная оценка как будто отсутствует (ну по крайней мере у большинства пользователей точно), возможно в этом причина. Поэтому как-то даже в голову не пришло добавить ее в статье. Но свою ошибку я понял, постараюсь на будущее учесть, спасибо!
Ну, на самом деле, с такими мыслями можно и от ООП отказаться в пользу ФП, а вместо Enum пользоваться константами. Да и они не нужны, просто в процедуре присваивать значения, да и все :)
Есть у меня один коллега, который достаточно давно программирует на VBA, но не пользуется классами. Коллеги решили ему показать пример, что классы могут быть вполне удобны в использовании, и даже удобнее, чем просто функции юзать. Но человека переубедить невозможно)
Ну и мое сугубо личное мнение - если в языке есть функционал, надо его как минимум знать, а в идеале использовать (не просто же так его завезли). Могу быть не прав, но на то это и сугубо личное мнение.
Ни в коем случае не камень, и не в Ваш огород. Просто размышления в слух.
P.S. Кстати, в статье я не пытаюсь сравнить Type с Классом (в плане «что лучше, то или это»). А если создается такое ощущение, то оно ложное, отбросьте его :)
Абсолютно никакой обиды нет, я в конце даже и написал, что уверен в возможности других решений, это нормально. Этим и круто программирование, что одну и ту же задачу можно решить кучей способов и все они будут правильными.
Про функцию Find как-то забыл, очень редко ее использую. Да и с Range в подобном формате почти не взаимодействую, гораздо чаще передаю в массив и уже с ним работаю. Конкретно тут почему так решил построить? Хм.. если честно, наверное, даже сам не смогу ответить :D
Касаемо вопросов о качестве кода - я все ещё учусь) Написанием макросов (да и в принципе программированием) занимаюсь примерно год с небольшим.
Статью же решил написать по нескольким причинам:
Показалось, что подобные решения смогут подтолкнуть кого-то (возможно таких же как и я новичков) на более глубокое изучение работы с макросами (все таки VBA, увы, не столь популярен в наше время).
В одном своём проекте я заложил в процедуре установление настроек по дефолту, если меняется пользователь.
То есть - открывается книга, макрос проверяет текущего пользователя, и если он не соответствует тому, который записан в том же конфиге, конфиг полностью сбрасывает в дефолт.
А уже далее пользователь под себя все настраивает.
Я данный подход использую в книге с конкретным макросом/макросами. Когда «клиент» пользуется макросом, ему в любом случае нужна будет эта книга, а в ней уже заложена конфигурация, которую можно обновлять с учетом предпочтений конкретного пользователя.
На большую аудиторию, которая одновременно пользуется этим макросом, конечно, это не рассчитано.
Тут, скорее, частная история. Но удобство в том, что передавая эту частную историю другому пользователю, он сможет ее подстроить под себя.
Не совсем так. Формирование этой таблицы действительно можно сделать программным. Но проверять/формировать ее при каждом запуске нет необходимости. Она изначально потребуется при разработке.
Другой вопрос, что можно автоматизировать процесс ее первого появления. И такое есть у меня, но подход костыльный и требует доработки. Как только, так сразу опишу в отдельной статье :)
Похоже, что это personal book. Да и надстройки, если мне память не изменяет, тоже запускаются из этой папки. Примерно таким образом у меня сейчас работает формирование листа и таблицы конфига в новых проектах. Ну и если код вынести в отдельный модуль, можно и его подключать так же.
Правда Вы меня натолкнули на другую идею. Пойду думать)
На самом деле я пытаюсь придумать этот «велосипед» с возможностью контроля версий. Даже что-то очень отдаленное удалось сделать (в виде надстройки). Но довольно костыльно. Увы, пока прям точных рецептов нет (в интернете особо ничего не удалось найти, не удивлюсь если плохо ищу).
Что касаемо GitHub’а, конкретно у меня проблема в том, что работодатель блокирует для сотрудников)) ну вот так, не суть важно. (Может стоит другие варианты контроля версий рассмотреть..) Короче говоря, возможно, этот вариант можно раскушать, но так как лично мне он не подходит, я за него пока не брался.
На счёт вызова из .vba не слышал ни разу. Можно подробнее? Освечу для себя этот момент.
В остальном, конечно, мой подход далеко не идеален и требует доработки. Но меня на данном этапе пока, в общем и целом, устраивает)
Вы про заголовок? Надо было добавить дисклеймер, что это, конечно, для красного словца) кликбейт, так сказать
Прошу прощения, если ввел в заблуждение
Добавлю в ближайшее время?
Прям мини блокбастер? спасибо
Интересная концепция?
Вот с одной стороны я надеюсь когда нибудь увидеть такой «макрос», с другой, не хотелось бы чтобы этот зверек попал тебе на попечение?
Было бы интересно узнать мысли автора(ов) этого монстра) ну в смысле: зачем/почему/что мешало и тд
Бывают просто забавные ситуевины, когда ты чувствуешь потенциал, хочешь его раскрыть, а тебе говорят «нет, батенька, excel и не более, не надо нам ваших C#/Java/C++ etc.»
Конечно, соглашусь, очень сложно поддерживать большие проекты, как минимум из-за невозможности структурировать файлы. Когда открываешь большой проект и видишь просто кучу модулей, становится немного страшно. Ситуацию немного помогает исправить Rubberduck, но это особо ничего не меняет.
Плюс, как тут уже заметили, Excel очень любит ни с того ни с сего в любом месте выполнения отлаженного
приложениямакроса просто упасть и все, без объяснения причины. Поэтому да, скорее это извращение.Но черт возьми, мне теперь интересно глянуть на этого монстра?
Позвольте с Вами поспорить.
Конечно есть свои массивы. А еще есть коллекция. Но можно же и без нее, просто на массивах все делать, верно?
Ладно, возможно не совсем уместный сарказм, но я вот какую мысль хочу донести.. mscorlib это динамически подключаемая библиотека, верно? Верно. Ровно такая же, как и scrrun (Scripting runtime, в составе которой FileSystemObject и Dicrionary, так горячо любимые всеми VBAшинками). Возможно Вы скажете ими тоже не стоит пользоваться по причинам производительности? Тогда точно останутся одними массивы да коллекция, с которой не особо удобно (ну лично мне, возможно кто-то со мной и не согласится) работать, т.к. ключ/значение в нее добавлять можно, а проверить наличие ключа (встроенными средствами) нет, приходится изворачиваться. Метод извлечения списка ключей/значений? Не, не слышал. Про FSO вообще молчу, стандартные функции для работы с файлами крайне скудны. Я пробовал принципиально ими пользоваться, тяжко.
Если не использовать тип Object, а пользоваться ранней привязкой, то конечный клиент может словить интересные ошибки (ну не поддерживают VBA, куча багов в нем, которые никто уже не исправит). Поэтому только поздняя привязка, поэтому только через тип Object, хоть мне поначалу это дико не нравилось и я пытался продвигать раннюю привязку, но после нескольких обращений от клиентов о том, что у них что-то не работает из-за этого (даже, казалось бы, такие родные либы Word и Outlook), пришлось смириться.
Это я все к чему? Все эти библиотеки и прочее - они ведь сделаны для удобства программиста, чтобы ему не нужно было сотни раз переписывать один и тот же код и можно было пользоваться уже готовыми и проверенными решениями. Да, порой они дают маленькую просадку в плане производительности, но, наверное, иногда можно пожертвовать этими нано-миллисекундами в угоду удобства, читаемости кода (возможно я и не прав, но это сугубо личное мнение). В VBA и без ArrayList кучу всего приходится писать самостоятельно, что в других языках решается подключением какой-либо библиотеки.
Насколько я понял, к .NET.
Не уверен, но думаю от версии Excel она не зависит.
Увы в моей работе принцип:
Интрументы как и родителей не выбирают?
Ну то есть, необходимо именно с Excel работать. Возможно в будущем, когда-нибудь. Но пока так.
Спасибо за развернутый комментарий)
Задача, приведенная в статье, просто пример который пришел в голову. Возможно решение не самое действенное, но наглядно показывающее как можно упростить задачу. А ведь бывают задачи, когда нужно работать именно с массивом (да что там бывают, вечно есть).
Согласен, встроенные возможности Excel чаще гораздо удобнее, чем сочиненные самостоятельно, но их все таки часто не хватает.
Боюсь даже представить что там было?
На самом деле, при должном подходе, мне кажется вполне возможно и что-то более серьезное наваять. Но кто бы умел в этот должный подход. (Не претендую на знатока, но пытаюсь как-то туда идти)
Думаю подавляющее большинство VBA-программистов — люди, которые пару раз юзали макрорекордер и в лучшем случае научились объявлять переменные. Но статистики у меня нет, поэтому это лишь домыслы.
Если речь о hash-таблицах и т.п., то поверхностно ознакомлен. Сильно глубоко не вдавался, т.к. пока не вижу как таковой нужды в плане применения (аналог тех же hash-таблиц в VBA —
Dictionary, если я правильно понимаю).По оценке сложности операций я не силен. В VBA подобная оценка как будто отсутствует (ну по крайней мере у большинства пользователей точно), возможно в этом причина. Поэтому как-то даже в голову не пришло добавить ее в статье. Но свою ошибку я понял, постараюсь на будущее учесть, спасибо!
Круто, спасибо за интересную информацию!
Ну, на самом деле, с такими мыслями можно и от ООП отказаться в пользу ФП, а вместо Enum пользоваться константами. Да и они не нужны, просто в процедуре присваивать значения, да и все :)
Есть у меня один коллега, который достаточно давно программирует на VBA, но не пользуется классами. Коллеги решили ему показать пример, что классы могут быть вполне удобны в использовании, и даже удобнее, чем просто функции юзать. Но человека переубедить невозможно)
Ну и мое сугубо личное мнение - если в языке есть функционал, надо его как минимум знать, а в идеале использовать (не просто же так его завезли). Могу быть не прав, но на то это и сугубо личное мнение.
Ни в коем случае не камень, и не в Ваш огород. Просто размышления в слух.
P.S. Кстати, в статье я не пытаюсь сравнить Type с Классом (в плане «что лучше, то или это»). А если создается такое ощущение, то оно ложное, отбросьте его :)
Насколько мне известно, увы да, udt нельзя добавить в collection или в dictionary.
Только массив, Вы правы.
Как альтернатива - создать класс, аналогично udt. В данном случае будет более гибкая модель.
Спасибо за отзывы!
Абсолютно никакой обиды нет, я в конце даже и написал, что уверен в возможности других решений, это нормально. Этим и круто программирование, что одну и ту же задачу можно решить кучей способов и все они будут правильными.
Про функцию Find как-то забыл, очень редко ее использую. Да и с Range в подобном формате почти не взаимодействую, гораздо чаще передаю в массив и уже с ним работаю. Конкретно тут почему так решил построить? Хм.. если честно, наверное, даже сам не смогу ответить :D
Касаемо вопросов о качестве кода - я все ещё учусь) Написанием макросов (да и в принципе программированием) занимаюсь примерно год с небольшим.
Статью же решил написать по нескольким причинам:
Показалось, что подобные решения смогут подтолкнуть кого-то (возможно таких же как и я новичков) на более глубокое изучение работы с макросами (все таки VBA, увы, не столь популярен в наше время).
Дать небольшую рекламу своему каналу в ТГ :)
Ещё раз, спасибо за отзывы :)
В одном своём проекте я заложил в процедуре установление настроек по дефолту, если меняется пользователь.
То есть - открывается книга, макрос проверяет текущего пользователя, и если он не соответствует тому, который записан в том же конфиге, конфиг полностью сбрасывает в дефолт.
А уже далее пользователь под себя все настраивает.
Спасибо за отзыв.
Возможно я не так понял, прошу поправить.
Я данный подход использую в книге с конкретным макросом/макросами. Когда «клиент» пользуется макросом, ему в любом случае нужна будет эта книга, а в ней уже заложена конфигурация, которую можно обновлять с учетом предпочтений конкретного пользователя.
На большую аудиторию, которая одновременно пользуется этим макросом, конечно, это не рассчитано.
Тут, скорее, частная история. Но удобство в том, что передавая эту частную историю другому пользователю, он сможет ее подстроить под себя.
Спасибо за отзыв.
Интересный подход, надо будет поискать информацию на эту тему, благодарю :)
Спасибо за отзыв.
Не совсем так. Формирование этой таблицы действительно можно сделать программным. Но проверять/формировать ее при каждом запуске нет необходимости. Она изначально потребуется при разработке.
Другой вопрос, что можно автоматизировать процесс ее первого появления. И такое есть у меня, но подход костыльный и требует доработки. Как только, так сразу опишу в отдельной статье :)
Спасибо за отзыв!
Пихаю Goto где надо и где нет..надо по рукам себя бить начинать) Конечно, лучше так как Вы написали. Будет возможность, поправлю.
Благодарю.
Похоже, что это personal book. Да и надстройки, если мне память не изменяет, тоже запускаются из этой папки. Примерно таким образом у меня сейчас работает формирование листа и таблицы конфига в новых проектах. Ну и если код вынести в отдельный модуль, можно и его подключать так же.
Правда Вы меня натолкнули на другую идею. Пойду думать)
Спасибо за отзыв и за плюс)
На самом деле я пытаюсь придумать этот «велосипед» с возможностью контроля версий. Даже что-то очень отдаленное удалось сделать (в виде надстройки). Но довольно костыльно. Увы, пока прям точных рецептов нет (в интернете особо ничего не удалось найти, не удивлюсь если плохо ищу).
Что касаемо GitHub’а, конкретно у меня проблема в том, что работодатель блокирует для сотрудников)) ну вот так, не суть важно. (Может стоит другие варианты контроля версий рассмотреть..) Короче говоря, возможно, этот вариант можно раскушать, но так как лично мне он не подходит, я за него пока не брался.
На счёт вызова из .vba не слышал ни разу. Можно подробнее? Освечу для себя этот момент.
В остальном, конечно, мой подход далеко не идеален и требует доработки. Но меня на данном этапе пока, в общем и целом, устраивает)
Ещё раз спасибо)