Выделил время на 2-ю главу. Первая партия замечаний по ней:
Рекомендуемой и почти обязательной средой разработки является Microsoft Visual Studio (VS) Professional.
На мой взгляд, здесь в тексте присутствует некоторая двусмысленность, согласно которой у читателя может сложиться впечатление о том, что то ли можно попытаться использовать IDE от других производителей (т.е. не Microsoft), то ли даже имея на руках версию VS Premium или VS Ultimate он всё же по каким-то причинам должен стараться использовать именно VS Professional. Наверное стоило бы уточнить, что IDE
должна быть именно MS VS, а в составе конкретной линейки продуктов рекомендуется использовать
не ниже чем Professional, тем самым давая понять, что более функциональные варианты (например Premium или Ultimate) так же годятся. Так же неплохо было бы пояснить читателю, чем обусловлены эти требования.
Основное окно Solution01-Microsoft Visual Studio(Администратор)...
У меня "(Администратор)" отсутствует, поскольку я никогда не работаю с правами администратора, но пользуюсь ими лишь для установки\удаления софта или в др. важных случаях, когда такие права действительно необходимы. Вы работаете из под учётной записи администратора - это конечно же Ваше личное дело однако, пусть даже и невольно, но прививать такую привычку читателю не стоит и на скринах книги "(Администратор)" присутствовать не должен (ИМХО).
Небольшая цитата из официального учебного курса Microsoft:
В наши дни нет оправдания тем, кто не использует принцип наименьших привилегий, так как все должны входить в системы под учётной записью стандартных пользователей. Чтобы использовать принцип наименьших привилегий, следуйте двум правилам:
1. Не запрашивайте большего уровня доступа к ресурсам, чем необходимо.
2. Создавайте файлы и разделы реестра там, где стандартные пользователи могут их изменить.
Я неоднократно сталкивался с приложениями (не системными), которые работают только из под админской учётной записи в виду того, что разрабатывавший их программист имел привычку работать с правами администратора и с этими же правами, видимо, тестировал свой код. А вот протестировать его из под обычной учётки либо не додумался, либо поленился, видимо решив, что и там всё будет успешно работать. Разработка ПО из под учётной записи обычного пользователя - общепризнанная, широко используемая мировая практика (и не только потому, что так советует Майкрософт).
Разработчикам, создающим коммерческие версии своих продуктов, необходимо компилировать и собирать проекты под обе платформы (они несовместимы друг с другом).
Т.е. если софт не является коммерческим, то такой необходимости нет? Вопрос риторический.
Такая формулировка может сбить с толку читателя. Коммерческий это продукт или некоммерческий - роли не играет: правила "игры" одни и те же в обоих случаях. Я думаю, что корректней было бы написать так: "Разработчикам, желающим чтобы их приложение работало как в 32-х битной, так и в 64-х битной версии AutoCAD, необходимо...".
Параметр Конечное расширение (Target Extension) необходимо заменить на .arx (по умолчанию - .dll), так как это обязательно для ARX-приложений...
Данное заявление не совсем корректно... Пользователю действительно
не удастся загрузить ARX приложение, имеющее произвольное расширение,
при помощи диалогового окна Load\Unload Applications. Это обусловлено тем, что в настройках этого окна установлены фильтры на расширения отображаемых файлов. Однако ничто не мешает выполнить загрузку такого приложения
программно: в настройках проекта я заменил
.arx на
.abcd, после чего смог успешно через COM API загрузить приложение в AutoCAD и использовать определённые в нём команды и lisp-функции. Код загрузки прост:
// C# code:
public void Initialize() {
IAcadApplication comApp = (IAcadApplication) cad.AcadApplication;
comApp.LoadArx(@"C:\public\Debug\App01\App01_x64.abcd");
}
Т.о. слово "обязательно" следовало бы заменить на "стандартно" и при этом добавить информацию о возможности программной загрузки ARX приложений с произвольными расширениями файлов (это может быть полезно, когда программист по каким-либо причинам не хочет предоставлять пользователю возможность загрузки тех или иных ARX приложений через обозначенное выше диалоговое окно).
... создаваемые файлы приложения будут накрывать друг друга.
Накрывать чем, медным тазом?
Мне кажется слово "перезапись" было бы более к месту.
Представляет интерес параметр Набор инструментов платформы (Platform Toolset). Это номер версии используемого компилятора. Обычное значение - v100 (соответствует версии 10 компилятора, необходимого для ObjectARX2013-2014).
Неплохо было бы пояснить, что если на компьютере установлены, к примеру, VS 2008-2013, то для разработки ARX приложений, которые требуют одну из этих версий VS, при желании можно использовать даже самую новую версию (VS 2013 на сегодняшний день) при условии, что свойству Platform Toolset назначена корректная версия компилятора. Т.е. разработчик сможет использовать более современную IDE, а уж msbuild.exe для компиляции воспользуется именно той версией компилятора, которая указана в обозначенном выше свойстве. Т.е. в данном месте была бы полезна ссылка на стр. 52.
Если вы посмотрите параметр Свойства конфигурации => С/С++ => ...
В VS 2013 обозначенная группа свойств по умолчанию присутствует, но в VS 2010, используемом согласно тексту книги, она отсутствует. Группа настроек С/С++ появляется в VS 2010 сразу после добавления в проект первого CPP файла. Возможно, что такое поведение будет наблюдаться и у др. читателей и об этом следует предупредить заранее, дабы не оставлять их в замешательстве.
Примечание. Предлагаемые в примере настройки не работают в VS 2012 и ObjectARX 2015.
Это здорово...
Но если уж сказано "А", то тут же хотелось бы услышать и "Б": почему они не работают и что нужно сделать, чтобы заработали? Или же нужна ссылка на стр. где это будет объяснено позднее. Оставлять читателя в недоумении - не самый лучший ход.
Теперь к проекту необходимо добавить файл определений имён функций, экспортируемых из DLL (такой файл должен быть с расширением .def).
Строго говоря, это не является "необходимостью", но является лишь одним из возможных способов сообщения линковщику списка экспортируемых функций. Я полагаю, что имеет смысл показать читателю ещё один вариант, дабы он для себя сам решил, каким способом ему пользоваться. Далее, собственно, показан альтернативный вариант...
В конце заголовочного файла
dbxEntryPoint.h определена следующая директива условной компиляции:
//- This line allows us to get rid of the .def file in ARX projects
#if !defined(_WIN64) && !defined (_AC64)
#pragma comment(linker, "/export:_acrxGetApiVersion,PRIVATE")
#else
#pragma comment(linker, "/export:acrxGetApiVersion,PRIVATE")
#endif
Неплохо было бы обратить внимание читателя на то, что в данном коде для Win32 имя экспортируемой функции начинается с символа подчёркивания. Включив обозначенный заголовок в наш код, мы тем самым выполняем тот самый экспорт обозначенной в коде функции
acrxGetApiVersion (или
_acrxGetApiVersion). Остаётся выполнить экспорт функции
acrxEntryPoint (её имя одинаково для Win32 и x64). В обозначенном выше файле заголовка присутствует макрос
IMPLEMENT_ARX_ENTRYPOINT_STD, посредством которого, видимо Wizard выполняет регистрацию
acrxEntryPoint, предварительно сгенерировав некий вспомогательный класс, имя которого и передаёт параметром макросу. Можно попробовать самому написать такой класс, после чего воспользоваться обозначенным макросом, либо, как наиболее простой вариант - создать и подключить такой заголовочный файл:
/* exports.h */
#pragma once
//- This line allows us to get rid of the .def file in ARX projects
#pragma comment(linker, "/export:acrxEntryPoint,PRIVATE")
Т.о. после подключения заголовочных файлов
dbxEntryPoint.h и
exports.h необходимость в DEF файле исчезает. Если позднее потребуется экспортировать какие-то дополнительные функции, то всегда можно добавить соответствующие записи в файл
exports.h.
