#=============================
стр. 11, Предисловие.Абзац 2:#=============================
> Если это для читателя критично, то он должен с особой тщательностью подойти квыбору языка разработки. А иначе с каждой новой версией AutoCAD придётся выпускать новую версию своего приложения.*******************************
На мой взгляд это достаточно сомнительное утверждение.
Как правило код ARX работает
во всех версиях AutoCAD, имеющих идентичное значение Major в номере сборки
(*если в них присутствует нужный программисту функционал).
Обычно это три версии (AutoCAD 2015 перескочил через одну). В то же время .Net
сборки имеют ещё б
ольшую совместимость: например,
нередко можно ограничиться
двумя-тремя версиями DLL, которые будут успешно загружаться и работать в AutoCAD
2009-2015 любой разрядности (при соблюдении того же уточнения (*), что было обозначено выше).
У AutoLISP и Visual LISP совместимость с разными версиями AutoCAD ещё выше, чем
у .NET.
Что касается VBA, то до версии 7 в нём нередко наблюдались проблемы, связанные
с разрядностью AutoCAD (x86\x64), но с выходом VBA версии 7, эта проблема была в
значительной степени устранена. Касательно совместимости кода, написанного на
VBA с разными версиями AutoCAD я не силён, т.к. не пишу на этом языке. Более
точную информацию смогут дать специалисты, использующие этот язык на практике. Тем не
менее, все мы прекрасно помним, что Autodesk уже давно и весьма настоятельно
рекомендует уходить с VBA на VB.NET (или на любой др. .Net язык), предупреждая,
что планирует вовсе отказаться от использования VBA. Правда с выходом VBA 7,
Autodesk (насколько я помню), отсрочил "похороны" VBA, по
прежнему продолжая рекомендовать "уходить" с этого языка. В виду этого изучение
VBA под AutoCAD вряд ли целесообразно.
Резюмируя цитату хочу отметить, что при надлежащем отношении к процессу
разработки, компилировать код под каждую версию AutoCAD не придётся, во всяком
случае в C++, .Net языках и AutoLISP\Visual LISP. В свете обозначенной мною
информации я не вижу связи между выбором языка и потребностью компилировать код
под каждую версию AutoCAD отдельно.
#=============================
стр. 11, Предисловие.Абзац 5:#=============================
> Центральной можно назвать главу 2...*******************************
Пожалуй, это всё же несколько субъективное мнение... В данном случае координаты
"центра" будут складываться из двух составляющих: предрасположенностью читателя
к тому или иному языку программирования, а так же из объёма страниц, отведённых
в книге под материал, отведённый под тот или иной язык. Например, мне в равной
степени интересен как материал, написанный на C++, так и материал, написанный на
.NET (и не только применительно к данной книге, но и вообще). Так же мне был бы
интересен материал, написанный на managed C++ (смесь C++ и .Net). Поэтому лично
я для себя не выделяю "отдельно C++" и "отдельно .Net", но смотрю на это в
комплексе.
#=============================
стр. 11, Предисловие.Абзац 6:#=============================
> Это можно сделать только на C++.*******************************
Это можно сделать только на C++, если речь идёт
о программировании под
AutoCAD средствами ObjectARX. Однако используя, к примеру, MultiCAD можно в т.ч.
и средствами .Net создавать пользовательские объекты, которые будут работать в
AutoCAD, при условии подгрузки в AutoCAD соответствующих Enabler'ов (в противном
случае такие объекты будут представлены в виде proxy). Более того, один и тот же
такой управляемый DLL файл, написанный с использованием MultiCAD, может быть
успешно загружен и использован не только в AutoCAD, но и в nanoCAD, а так же в
BricsCAD. То, является ли сам по себе MultiCAD приложением ARX, выступающим в
роли обёртки - это другой вопрос. Для меня, как для программиста, интересен
набор предоставляемого им функционала, а пользователя интересует конечный
результат. Соответственно, если нужный мне пользовательский объект может быть
создан кодом .Net через обёртку MultiCAD, то наличие такой возможности так же не
стоит отрицать.
На мой взгляд это достаточно интересная информация и может дать некоторый повод
к размышлению, тем более, что книга называется "Программирование для AutoCAD
2013-2015" и из названия вовсе не следует, что контент должен ограничиваться
только тех API, которые предоставляет компания Autodesk. Я не призываю к тому,
чтобы в книгу включали информацию о MultiCAD или Teigha, но я за то, чтобы не
давать искажённой информации, вводя читателя в заблуждение, мол "
вот ваша песочница и за её границами ничего нет". Читатель имеет право получать как можно
более объективную информацию, не зависимо от того вписывается ли данный материал
в "религиозные взгляды" менеджеров Autodesk или нет.
Анализ информации - это уж
дело читателя (главное, чтобы информация была действительно
объективной, не однобокой).
