在COM服务器中使用MFC-我的选项是什么？ Visual C++。我必须实现一些绘图和打印功能，这些功能将合并到（其他开发人员的）COM dll中。首先，我想用纯GDI来做所有的事情，但与MFC实现相比，在GDI中打印和打印预览似乎是一件非常糟糕的工作。所以我决定专注于MFC。这里有一个简短的附带问题：我的选择正确吗？我的意思是，在没有MFC的情况下实现打印（和打印预览）有什么简单的方法吗

现在我需要MFC（假设您也同意这一点），我有两个关于如何实现的问题：

1） 我相信COM dll是ATL项目（它不是我的代码，是其他开发人员独立开发的）。我可以在该dll中启用MFC支持吗？在COM服务器中使用MFC运行时有哪些风险/限制/缺点？如果你建议我这么做，我该怎么做

2） 虽然我希望尽可能少地影响第三方COM服务器的代码，但我认为将我的代码实现为一个单独的基于MFC的DLL，并从COM服务器加载和使用该DLL可能是更好的方法。你建议这样做吗？这种情况下有哪些风险/限制/缺点

---

简而言之，我想在我的代码中使用MFC的绘图功能，尤其是打印功能，它本身应该集成到另一个开发人员的COM dll中（它本身在大型企业应用程序中使用）。我不是COM技术专家，所以我有点困惑。我的最佳选择是什么？

您可以在自己的dll内部使用MFC，并使用非MFC侵入函数向用户公开功能：例如，如果您需要从ypur调用方传递点，请使用GDI标准点结构，然后将其转换为CPoint以在内部使用。在这种情况下，您不需要在ATL项目中使用MFC（这无论如何都是可能的），但是您当然需要分发或链接MFCDLL。如果您想保持调用方com dll尽可能干净，您当然可以创建自己的ATL+MFC dll，并通过com接口公开您的函数，但请保留mynd以避免将MFC相关对象放入接口中。

除非您使用MFC，否则打印和打印预览是一项艰巨的工作。你的COM会公开这样的高级UI吗

如果你的COM必须独立于.NET，那么MFC就是最好的选择，否则我会使用.NET。如果选择MFC，请确保静态链接到它。否则，在缺少必要的MFC版本的计算机上，很可能会出现运行时错误

除此之外，我不担心兼容性，因为COM的思想是让底层的魔法来处理整数、字符串和其他对象