Visual C ++。我必须实现一些绘图和打印功能，这些功能将被合并到（其他开发人员的）COM dll中。首先，我想到使用纯GDI做的一切，仅此而已，但似乎与MFC实现相比，打印和打印预览是GDI要完成的工作。所以我决定专注于MFC。快速提问：这是我的选择吗？我的意思是，在没有MFC的情况下实现打印（和打印预览）的简单方法是什么？
现在我需要MFC（假设你也同意这个），我有两个问题关于如何做：
1）我相信COM dll是ATL项目（它不是我的代码，其他一些开发人员独立开发它）。我可以在该DLL中启用MFC支持吗？在COM服务器中使用MFC运行时有哪些风险/限制/缺点？如果您建议这样做，我该怎么做？
2）尽管我想尽可能少地影响第三方COM服务器的代码，但我认为这可能是将我的代码实现为单独的基于MFC的DLL的更好方法，并加载和使用该DLL来自COM服务器。你建议这样做吗？在这种情况下有哪些风险/限制/缺点？
很快，我想在我的代码中使用MFC的绘图，尤其是打印功能，它本身应该集成在另一个开发人员的COM dll中（它本身用于大型企业应用程序中）。我不是COM技术的专家，所以我有点困惑。我最好的选择是什么？
答案 0 :(得分：0)
您可以在内部使用MFC，并使用非MFC入侵函数向用户公开功能：例如，如果您需要从/向ypur调用者传递一个点，请使用GDI标准POINT结构，然后将其转换到内部使用的CPoint。在这种情况下，您不需要在ATL项目中使用MFC（无论如何都可以），但当然您需要分发或链接MFC dll。如果你想让调用者尽可能干净，你绝对可以创建自己的ATL + MFC dll并通过com接口公开你的函数，但保留在mynd中以避免在界面中放入与MFC相关的对象。
答案 1 :(得分：0)
除非您使用MFC Document/View Architecture，否则打印和打印预览是一项很糟糕的工作。你的COM会暴露这样的高级用户界面吗？
如果你的COM必须独立于.NET，那么MFC就是你要走的路，否则我会使用.NET。如果选择MFC，请确保静态链接到它。否则，您很可能会在缺少必要MFC版本的计算机上遇到运行时错误。
除此之外，我不担心兼容性，因为COM的想法是让底层魔法对整数，字符串和其他对象进行编组。