Использование MFC на COM-сервере - какие у меня варианты?

Question

Visual C ++.Я должен реализовать некоторые функции рисования и печати, которые будут включены в (другие разработчики) COM dll.Сначала я думал о том, чтобы делать все с использованием чистого GDI и ничего более, но кажется, что печать и предварительный просмотр печати - адская работа, которая должна быть выполнена в GDI по сравнению с реализацией MFC.Поэтому я решил сосредоточиться на MFC.Быстрый вопрос здесь: мой выбор правильный?Я имею в виду, есть ли какие-нибудь простые способы реализовать печать (и предварительный просмотр) без MFC?

Теперь, когда мне нужен MFC (если вы согласны с этим), у меня есть два вопроса о том, как это сделать:

1) Я считаю, что COM dll - это проект ATL (это не мой код, некоторые другие разработчики самостоятельно разрабатывают его).Могу ли я включить поддержку MFC в этой DLL?Каковы риски / ограничения / недостатки наличия среды выполнения MFC на COM-сервере?И если вы посоветуете сделать это, как я могу это сделать?

2) Насколько я хочу, чтобы как можно меньше влиять на код стороннего COM-сервера, я подумал, что это может быть лучшим подходом для реализациимой код в виде отдельной DLL на основе MFC, и загрузить и использовать эту DLL с COM-сервера.Вы советуете делать это?Каковы риски / ограничения / недостатки в этой ситуации?

Вскоре я хочу использовать возможности рисования MFC и особенно возможности печати в моем коде, который сам должен быть интегрирован в COM dll другого разработчика (который сам используетсяв большом корпоративном приложении).Я не эксперт в технологии COM, поэтому я немного запутался.Каковы мои лучшие варианты?

Answer 1

Печать и предварительный просмотр печати - адская работа, если вы не используете MFC Document / View Architecture .Будет ли ваш COM предоставлять такой расширенный пользовательский интерфейс?

Если ваш COM должен быть независимым от .NET, тогда MFC - это путь, иначе я бы использовал .NET.Если вы выбираете MFC, убедитесь, что вы ссылаетесь на него статически.В противном случае вы, скорее всего, столкнетесь с ошибками времени выполнения на машинах, где отсутствует необходимая версия MFC.

За исключением этого, я бы не стал беспокоиться о совместимости, поскольку идея COM заключается в том, чтобы основная магия могламаршалинг целых чисел, строк и других объектов.

Answer 2

Вы можете использовать MFC в своей собственной dll для внутренних целей и предоставлять своим пользователям функциональность с помощью функции, не связанной с MFC: например, если вам нужно передать точку от / до вызывающего абонента ypur, используйте стандартную структуру POINT GDI, а затем преобразуйте ее CPoint для внутреннего использования. В этом случае вам не нужно включать использование MFC в проекте ATL (это возможно в любом случае), но, конечно, вам нужно распространять или связывать с MFC dll. Если вы хотите, чтобы вызывающий компонент был как можно более чистым, вы можете создать свой собственный ATL + MFC dll и выставлять свои функции также через com-интерфейсы, но имейте в виду, чтобы избежать размещения объектов, связанных с MFC, в интерфейсе.