Компоновка MFC с OCX-файлом

Доброе время суток!

Намедни я столкнулся с проблемой регистрации OCX'а. По совету Boombastic'а я сделал релизный конфиг активным и от себя уж прилинковал MFC статически (на всякий случай). Не знаю, что именно помогло, но заработало.

Но это навело меня на размышления. Читал я где-то, что к OCX'у НИКАК нельзя линковать MFC. Дескать, надо пользоваться шаровыми дллками. И автор даже грозился, что не то, что работать не будет, а и компилятор вас обругает и не сделает этого категорически. Но мой делает. Нет, понятно, что в результате такого хода файл распухнет и в страницу его будет не интегрировать, почему и юзают ATL, но сам принцип компоновки??? Кто-нибудь знает, можно это делать или нет? Ну, т.е. я убедился, что можно, но откуда вообще такая тема пошла, что нельзя?

Всего, Снорк. [www.snorkonline.narod.ru] [snorkleg@mail.ru]

Подожди я не уловил, кто куда прикомпоновался статически?
Если ты говоришь об установках компилятора Use MFC in a Static Library, то это работает только для MFC библиотек и в основном для mfc42.dll. То есть когда ты будешь использовать класс CString или CWnd программа не полезет искать библиотеку mfc42.dll сначала в памяти, потом если таковой нет то по дискам, а будет использовать внедренный в твою программу код. И это нормально, при создании своих ActiveX компонентов и прочих COM объектов ты с легкостью можешь использовать эту опцию, как впрочем и при создании приложения, даже если это приложение использует твои или сторонние COM-объекты.
С другой стороны, если ты хочешь использовать библиотеку, содержащую COM-объеты, и линковать ее статически (те же *.ocx - файлы) - вот это у тебя не получиться. Библиотека должна быть зарегистрирована в реестре и скомпонована по особым правилам и т.п. то есть тебе придется с проектом, который использует COM-объекты, нести эти самые объекты в своих библиотеках и регистрировать их.
По поводу ATL-на самом деле сложно утверждать, что код получается гораздо меньше, особенно если не использовать статическую компановку в первом случае (с MFC). Я бы даже сказал, наоборот, так как библиотека mfc42.dll уже включена в стандарт Windows 2000/ME, многие пользователи уже более старых ОС, уже давно установили ее с одним из многочисленных проектов, разработтаном на VC++ с применением MFC, то в принципе ее можно и не включать в поставку, просто сделать ссылочку в FAQ, что возможно отсутствует библиотека mfc42.dll. Тогда код сгенерированного ocx с использованием MFC будет раз в 5 - 10 меньше подобного, но с использованием ATL (цифра так навскидку и конечно может варьироваться). Кроме того разработка, например ActiveX компонентов с использованием MFC мне показалась гораздо легче, чем с ATL. Обычно для контролов я использую MFC, а для библиотек функций - ATL (все таки приятно когда ты не зависишь ни от каких сторонних библиотек Хотя конечно сложно mfc42.dll назвать сторонней ).

С уважением, Владимир

0

Владимир, привет!

Ну, про то, что ocx'ы не скомпонуешь, знают все, кто понимает, что такое позднее связывание и откуда есть пошел COM (стандарт двоичного позднего связывания). Нужна 'прописка' в реестре, 'гуиды' etc. Я не про то. Я о другом. Вот именно, что в какой-то книжке читал, что опцию 'Use MFC in a static lib' нельзя включать для ActiveX - контролов, сгенерированных визардом. Гон какой-то, верно? Я просто хотел понять, откуда ветер дует.
------------------------------------
Во, не поленился, нашел. Кэйт Грегори, 'Использование VC++ 6'. Цитирую (стр 484.): 'Возможно, вам придет в голову идея скомпоновать библиотеку MFC и элемент управления статически. На 1ый взгляд, сделать это не сложно - выбрать Build->Settings. <...> Сделав это, вы столкнетесь с множеством ошибок компоновки: функций классов COleControl и CPropPage. Последние не входят в состав DLL-модулей, которые можно компоновать статически.' Далее про гейтсовцев, которые не предполагали, что кто-то запузырит ЭмЭфСю в ocx. Теперь вопрос понятен? Или автор говорит о чем-то другом, а я не так понял, или ей пора переквалифицироваться в управдомы :-))).

С уважением - Снорк.

Ясьненько.
Странно, и вроде бы VC++6.0, а какого года книжка? Оригинальное издание? Может парни из Microsoft прочитали ее и одумались
В любом случае, раз это работает, то надо радоваться!

Счастья Вам, Владимир

0