Предполагается что инженер-строитель использует как AutoCAD (или его клоны) так и расчетные программы узкостроительного направления, времени на изучение минимум. Требуется получить наибольший практический эффект от владения данным языком.

[Владимир_М]

Сообщение от Сергей812 потому что программирование ради программирования - это хобби) А с точки зрения практического применения как раз конечный эффект - насколько сократился цикл разработки проекта (для начала).

Вот это на мой взляд чушь полная. Проект проекту рознь. То что подойдет для одного проекта, для другого совсем неприменимая вещь.
Или что? если приложение не охватывает весь проект в целом, то это уже не имеет смысла и начинать?
Хорошо. Вот следующее кино. То что выполняется приложением - это примерно 50% чертежной работы стадии П и почти 100% стадии Р. Ну вот такой есть у нас бывает тип проектов, с таким "циклом". Так Вам более понятен станет экономический эффект?

Да забыл сказать, это вообще не VBA и работает еще с прошлого века, кажись

[stas_org]

Сообщение от trir повтори

Я не совсем понял, что там происходит на экране, но думаю что это вполне под силу ВБА. Я понимаю, что это очень серьезная работа и нисколько ни умаляю ее.

[Сергей812]

Сообщение от stas_org Но это уже выходит за рамки типовых инженерных задач.

это выходит за рамки суперязыка VBA, но являются штатными средствами языков типа C# и NetAPI для "понторезов")

Сообщение от stas_org А если ты, не дай бог, забухаешь например и забудешь родной ЯП)))). Что тогда делать нормальным людям?

Понятно, что код на VBA со кучей всяких костылей и велосипедов для обхода ограничений языка является гораздо более поддерживаемым, чем решения на стандартных документированных средствах распространённого языка) Про понты типа XML комментариев даже смысла нет говорить - лучше редактора VBA 20-летний давности ничего не смогли и не смогут придумать)

[trir]

но думаю что это вполне под силу ВБА

ни фига, там используется brep

[Boxa]

Сообщение от stas_org Что вы там такое в одиночку можете сделать, чего я не смогу повторить на VBA.

После этой фразы, Вас попросили повторить на VBA и начались отмазки

Сообщение от stas_org Не повторю, и ни копейки за эту фитчу не дам, да и не надо это инженеру, и никакой практической пользы не вижу.

Сообщение от stas_org Но это уже выходит за рамки типовых инженерных задач.

Не имеет значения надо или не надо, выходит или нет. Вы говорили, что можете повторить. Повторяйте.

----- добавлено через ~10 мин. -----

Сообщение от stas_org Код на ВБА который я писал для себя на ВБА на А2004 отлично работает на А2014. А вот для того, чтобы использовать код(.NET) написанный для А2012 на А2015, нужно будет упрашивать Сергея812 предлагая ему огромные деньги)))) Может в этом вся перспективность на самом деле?))) Вот вам и аргумент.

Сообщение от stas_org А если ты, не дай бог, забухаешь например и забудешь родной ЯП)))). Что тогда делать нормальным людям?

Т.е. Вас не смущает, что компания AutoDesk может разориться, что служба поддержки отвечают на вопросы только по 3-м последним версиям, что исправления ошибок выходят, как правило, только для последней версии акада, если повезет, а если не повезет, то в следующей версии. Но да, частный программист, должен пожизненно поддерживать проект и выпускать все новые и новые версии под новые платформы и быть доступным 24/7 .... Забавно.

[Владимир_М]

Ну, если речь зашла об армировании вообще (а не параметризация отдельных участков или изделий), то еще одно кино. Первая серия "Создание арматурной требухи".

[Дима_]

Ну пожалуй и я влезу в Ваш спор со своим субъективным мнением. Если мы говорим о реализации инженерных хотелок - vba безусловно хватит. Другой вопрос, что если эти хотелки развивать, то рано или поздно упрешься в то, что он совсем никак не может - или если и может то с такими костылями, что лучше без них. .Net платформа конечно дает гораздо более продвинутый результат, но "порог входа" в нее выше и, наверное, все-таки она выходит за "инженерные" рамки. Но в общем то же можно сказать про vba, но он при этом менее перспективен. С моей точки зрения, для "автокадного" инженера в плане, возможностей, порога входа и производительности лучшим выбором будет автолисп (плюс еще в том, что на нем можно программировать на очень разных уровнях, как на достаточно "продвинутом", так и совсем на начальном). Конечно если сразу ограничиваемся инженерными задачами и уже хорошо знает vba, то ему конечно его будет вполне достаточно, но это не значит, что этот метод наилучший в других случаях. Если сравнивать VB.net и C#, то как я уже не раз говорил, мне не нравится ни тот, ни другой, но С# конечно знать надо (если речь о .Net платформе), чтобы как минимум уметь читать чужие коды - которых в сети валом, писать на нем совсем не обязательно и ИХМО даже противопоказано (есть там неплохие "куски" типа LINQ - но все познается в сравнении) - но я ни в коем случае не говорю, что всем надо поступать именно так.

[Владимир_М]

Сообщение от Дима_ Ну пожалуй и я влезу в Ваш спор со своим субъективным мнением. Если мы говорим о реализации инженерных хотелок - vba безусловно хватит. Другой вопрос, что если эти хотелки развивать, то рано или поздно упрешься в то, что он совсем никак не может - или если и может то с такими костылями, что лучше без них. .Net платформа конечно дает гораздо более продвинутый результат, но "порог входа" в нее выше и, наверное, все-таки она выходит за "инженерные" рамки.

Ну вот же все ясно и понятно, надеюсь, и авторитетно для местных знатоков языков.
И где Вы Дима раньше были? Тут чуть было не передрались.

Вторая серия "Про армирование" - "Переработка требухи в спецификации"

[Сергей812]

Сообщение от Дима_ но С# конечно знать надо (если речь о .Net платформе), чтобы как минимум уметь читать чужие коды - которых в сети валом, писать на нем совсем не обязательно и ИХМО даже противопоказано (есть там неплохие "куски" типа LINQ - но все познается в сравнении)

умение разобраться в чужих кодах - это уже уровень не начинающего программиста-самоучки, имхо. И тем более не уровень знающего язык, но без практического опыта. Это примерно как менеджер проекта пытается проверять проекты - поверхностных знаний и знание средних цен позволяет оценить общую рентабельность, но не степень соответствия проекта нормативным требованиям и правильности инженерных решений.

[Boxa]

Выдирать слова из контекста, не буду:

Сообщение от Дима_ .Net платформа конечно дает гораздо более продвинутый результат, но "порог входа" в нее выше и, наверное, все-таки она выходит за "инженерные" рамки. Но в общем то же можно сказать про vba, но он при этом менее перспективен.

Собственно последние 5 страниц именно об этом.

[DEM]

С одной стороны, да VBА хорош низким порогом вхождения...
Но наиболее интересные библиотеки, всё такb для VBA не доступны...
Для инженерных(расчетных) задач например приходится и numpy использовать и различные библиотеки для триангуляции.

[Psyakrev]

Сообщение от stas_org Код на ВБА который я писал для себя на ВБА на А2004 отлично работает на А2014. А вот для того, чтобы использовать код(.NET) написанный для А2012 на А2015, нужно будет упрашивать Сергея812 предлагая ему огромные деньги))).

Ох уж эти сказки. В dnl есть пара очень полезных программ на vba, которые не работают примерно так с 2010 автокада, но отлично работали в 2008 версии. А все потому, что vba под х86 и x64 отличается (что-то с objectid, не помню точно).

[Сергей812]

Ветка с adn-cis.org - Седьмой пост

[Владимир_М]

Сообщение от Psyakrev Ох уж эти сказки. В dnl есть пара очень полезных программ на vba, которые не работают примерно так с 2010 автокада, но отлично работали в 2008 версии. А все потому, что vba под х86 и x64 отличается (что-то с objectid, не помню точно).

Да был такой прецедент.
DataType(2) = 1041: Data(2) = plineObj.ObjectID
Отличие только в следующем ObjectID и ObjectID32. Но это только встретилось мне один раз (в одном приложении) когда я решил поиграться с XData и изобрести что-то типа самодеятельного реактора в VBA. (короче, сделал приложение Рамка Штамп и чтобы по клику по уже отрисованным элементам, в зависимости от элемента, включался нужный макрос для соответствующего изменения этих элементов).
Второй случай, когда пытался использовать какую-то встроенную функцию, без которой в итоге совершенно спокойно обошелся.
Это все. В других приложения смена разрядности машины ничего подобного не вызывала.
Сами по себе смены версий Windows, Excel, Acad практически никаких ошибок не вызывали. И это за период с 2000 года (асаd R14) и по сегодняшний день.
Да был еще такой затык. В Excel c какой-то не помню версии при отрисовке овала приложение начало выдавать какие-то фокусы. Но это уже походу не к VBA претензии, а просто саму функцию переделали, аргументы местами поменяли.
Вот и все трудности, с которыми столкнулся за 17 лет. Сильно пинать не надо если что-то забыл.
А вот, еще вспомнил. Было что-то с блоками. Типа была какая-то ссылка на блок одна, а потом появилась еще другая. Но опять-таки, как я понимаю, это не VBA виноват, а само развитие Acada, появление новых функций. Тут и любой C# споткнется.
Так что судите сами где сказка, а где "прост о сказка". А если учесть возможный вариант с переходом на MicroStation
c его встроенным VBA, так для меня вообще песня. Многие приложения перейдут как родные.
Пока не накинулись высокоязычные критики подчеркиваю, я не пытаюсь как-то пропагандировать VBA и отговаривать начинающих от использования .NET. Только за, вперед и успехов. Просто за объективность и закоснули безаппеляционные заявления типа "VBA - мертв!". Слухи о смерти пациента мне кажутся сильно преувеличенными. И за VBA вполне еще может сохраняться своя ниша. Доказательства привел выше в виде кино.

[Do$]

Autodesk еще относительно недавно (буквально пару лет назад) открещивались от VBA, настоятельно рекомендовал переводить свои проекты на VB.NET. И все считали, что вот-вот, в следующих версиях, объявят о полном прекращении его поддержки. А они вместо этого, вдруг, объявили о поддержке VBA 7.1! И теперь, вроде как, уже и не предвидится отказ от него в AutoCAD. Оно, наверное, и логично. В свое время, было довольно много вложено труда во внедрение этого инструмента в AutoCAD и его поддержку. Да и владеющих VBA не так уж и мало, и написано приложений для AutoCAD на нем великое множество. А уж возможность использовать один и тот же инструмент и в продуктах Office и в AutoCAD и разных других приложениях - это, конечно, большой плюс. Так, что, похоже, VBA в AutoCAD свою нишу довольно прочно будет держать еще долго.
Если сравнивать VBA с его ближайшим "оппонентом" в AutoCAD - AutoLISP, то:

• У VBA больше возможностей.
• Порог вхождения у AutoLISP гораздо ниже.
• VBA более универсален и может применяться во многих других программах. AutoLISP вне AutoCAD (и его клонов) не используется.
• Грамотно написанное приложение AutoLISP меньше зависит от версии AutoCAD, чем приложение на VBA.
• AutoLISP приложения работают в AutoCAD "из коробки", для VBA нужно устанавливать отдельный Enabler.
• После VBA легко перейти на VB.NET, т.к. у них схожий синтаксис. А вот после AutoLISP перейти на другой язык очень тяжело.

Так что, VBA в качестве прикладного инструмента к AutoCAD, на мой взгляд, это не так уж и плохо.
Если говорить про другие языки, типа языков .NET или C++, то тут VBA, конечно, сильно уступает по возможностям. С высоты знаний VBA этого не понять. Так что, уважаемые мои коллеги, ничего вы не докажете VBA-программисту . Это надо почувствовать на собственном опыте, чтобы понять.

[Сергей812]

Сообщение от Do$ А они вместо этого, вдруг, объявили о поддержке VBA 7.1!

Если Майкрософт перешел в последних версиях офиса на 7-ую версию VBA, то куда было Аутодеску деваться то?)

[Do$]

Могли сообщить о прекращении поддержки, к этому они уже, вроде как, всех готовили

[Сергей812]

И еще есть такая вещь, как Interop. Скомпилированное в сборку приложение уже не требует наличие энаблера vba для запуска, и позволяет одновременно использовать как привычный код VBA фактически один в один (если выбрать VB.NET), так и технологию Net для реализации интерфейса пользователя и работы с самой операционной системой. Минус - медленная скорость работы с акадом по сравнению с Net Api.

----- добавлено через ~17 мин. -----

Сообщение от Do$ Могли сообщить о прекращении поддержки, к этому они уже, вроде как, всех готовили

на самом деле расширили бы функционал лиспа в плане тех же средств интерфейса и создали бы какую то базу типовых решений на нем (что сейчас можно по инету раскопать, но чтобы было собрано в справку) - и можно было бы от VBA отказаться, имхо.

[Дима_]

Сообщение от Do$ Если сравнивать VBA с его ближайшим "оппонентом" в AutoCAD - AutoLISP, то:

+ к сказанному - автолисп дает "правильное" направление развития хода мысли - растешь как программист (если конечно сам этого хочешь), вба "подталкивает" в другую сторону.

[Do$]

Сообщение от Сергей812 на самом деле расширили бы функционал лиспа в плане тех же средств интерфейса и создали бы какую то базу типовых решений на нем (что сейчас можно по инету раскопать, но чтобы было собрано в справку) - и можно было бы от VBA отказаться, имхо.

Если серьезно, то не могли они отказаться. Это крайне недальновидный шаг с точки зрения маркетинга. Им надо создавать благоприятные условия для того, чтобы пользователи переходили на новые версии AutoCAD. Если отключить VBA совсем - то многие просто не смогут этого сделать, т.к. очень много полезных наработок на VBA, без которых они уже и не представляют свою работу в AutoCAD. На моей памяти был такой случай, когда целый институт не мог перейти на новую версию AutoCAD, потому что в нем не работало полезное для них приложение. Это была та еще эпопея под названием "уговори разработчика обновить приложение" . Отключение VBA - это будет то же самое, но в более глобальных масштабах. Так что, VBA и Auto-VisualLISP в этом плане "в одной лодке". Развивать активно их вряд ли станут, но поддерживать будут.

Сообщение от Дима_ автолисп дает "правильное" направление развития хода мысли - растешь как программист

Понятие "правильное" - очень относительно. К тому же, LISP - не для всех, уж очень он бывает изощрен в своих конструкциях Хотя, конечно, не спорю - мозги развивает хорошо.