Здесь мы рассмотрим создание внешней компоненты, работающей по технологии Rainbow, с нуля с использованием Microsoft Visual Studio 6.0. В этой компоненте не будет использования интерфейсов 1С («IInitDone» и прочее).
Создаем проект. Тип проекта: «MFC App Wizard? (dll)" (для Visual Studio 2005 пункт меню будет «New projects -> Visual C++ -> MFC DLL»). Указываем название проекта и каталог. Тип DLL ставим «MFC Extension DLL (using shared MFC DLL)". Можно поставить и тип “Regular DLL using shared MFC DLL”, однако этот вариант требует больше ресурсов для запуска (для использования в MFC-приложениях Microsoft рекомендует “MFC Extension”). Также все DLL 1С, скорее всего, сделаны по типу “MFC Extension”.
Сразу после создания проекта у него будет две конфигурации: “Debug” – отладочный вариант с включенными в него runtime-проверками и отладочной информацией; и “Release” – конфигурация, используемая для сборки конечного варианта проекта с включенной оптимизацией.
В окне ClassView выбираем наш проект и открываем окно настроек: “Project” – “Settings”:
Т.е. для конфигурации “Debug” мы установили часть параметров как в конфигурации “Release”. Если это не сделать, то могут быть пробемы при использовании классов 1С в качестве базовых для построения своих. В частности, при создании классов-наследников CChildFrame? при создании фреймов вылетают assertion'ы с последующим вылетом 1С.
Также такие настройки позволяют корректно отрабатывать функции AfxGetApp() в компонентах, реализованных по типу “Regular DLL using shared MFC DLL”. Без этих настроек данная функция в DEBUG-сборке будет возвращать собственный CWinApp компоненты, а не CWinApp от 1С.
Тут есть два пути:
В первом случае включаем заголовочные файлы в проект добавлением строки в stdafx.h:
Во втором случае так:
Второй случай неудобен тем, что в дереве классов не будет видно классов 1С, что, при отсутствии полной документации, не удобно. Однако, если использовать все время первый способ, то в итоге для разных проектов может получиться несколько разных наборов заголовочных файлов (отличающихся в деталях). В общем, каждый сам выбирает для себя наиболее удобный способ.
Включение в stdafx.h удобно тем, что для этого файла студия создает «предкомпилированный заголовок» – PCH-файл. Для всех файлов в проекта по умолчанию установлено, что при их компиляции следует использовать PCH-файл для stdafx.h. Это позволяет компилятору не анализировать при компиляции каждого cpp-файла заголовочные файлы Windows и MFC. В нашем случае мы избавляем компилятор также и от необходимости возиться с заголовочными файлами 1С.
Аналогично, есть два пути:
В первом случае дополнительных действий для проекта не требуется. Во втором случае понадобится отредактировать свойства проекта: “Project” – “Settings”. Закладка “Link”, категория “Input”. В поле "Object/Library modules” пишем путь к каталог библиотек 1С, например: «../LIBS/*.lib” – т.е. библиотеки находятся в каталоге “LIBS” уровнем выше. Это надо будет сделать для обоих конфигураций: и “Debug”, и “Release”.
Недостатков первого приведенного метода два:
Поэтому сам я сделал так:
Все проекты размещены в одном каталоге.
В том же каталоге создан единый для всех проектов каталог 1CHeaders. В этом же каталоге создан проект "1cheaders.dsp", включающий в себя все заголовочные файлы 1С, и файл "empty.cpp", следующего содержания:
Теперь при разработке ВК в workspace включается проект "../1cheaders.dsp", таким образом в дереве классов классы 1С лежат в отдельном проекте, в своем же файле "stdafx.h" пишем
То есть примерная структура каталогов:
Подключение библиотек выполняется в stdafx.cpp:
Этот файл содержит инструкцию линкеру по подключению 1С библиотек, и реализацию нескольких полезных функций, объявленных в 1cheaders.h
Используем метод из 
статьи Альфа. А именно открываем файл с расширением “rc2” и добавляем в конец код:
Это позволит загружать компоненту методом "Загрузить Внешнюю Компоненту?".
Все операции по интеграции с 1С (модификация меню, регистрация собственных объектов) производим в функции DllMain. При этом помним, что интерфейса IInitDone у нас нет и все надо делать с использованием внутренних функций 1С. Пример:
При сборке проекта выдается набор сообщений:
Решение проблемы описано в следующей статье на сайте Microsoft.
Кратко: такие сообщения могут выдаваться в модулях, собранных как “MFC Extension DLL”, при использовании конструкций вида «AFX_MANAGE_STATE(AfxGetStaticModuleState());". Данные конструкции не нужно использовать в данных видах DLL.
Александр!
Тип “Regular DLL using shared MFC DLL”, использовать не рекомендуется, тк при этом в длл создается свой объект CWinApp, и Afx Get App?() будет возвращать его, вместо единого приложения 1С.
Это не так. В Html User Help? тип DLL “Regular DLL using shared MFC DLL” и эта функция возвращает CWinApp для 1С, а не компоненты. Более того, 1С++ тоже имеет свой объект CWinApp, но также нормально получает CWinApp от 1С.
Недостатков первого приведенного метода два:
1С классы в дереве классов валяются вперемешку с собственными классами.
При ведении нескольких проектов сложно поддерживать изменения в разрозренных версиях 1С-хедеров разных проектов.
Смотри текст внимательней. Для подключения заголовков и библиотек было предложено по два разных способа. Один из них сходен с твоим.
Да, это я не внимательно прочитал :)
А для чего нужно выравнивание 512?
Для подключения заголовков и библиотек было предложено по два разных способа. Один из них сходен с твоим.
Тут фишка в том, что под 1С хедеры создается фиктивный проект, и 1С классы не валяются вперемешку с моими
У меня они в дереве классов сидят в отдельной папочке и не перемешиваются с моими :) Правда, если случайно неправильно добавить комментарий в хедер 1С, то, бывает, половина классов вылазит опять в корень и их приходится обратно упихивать, но я уже привык :)
Я просто задолбался их так упихивать при каждом чихе обратно.