我正在构build一个基于C ++（Qt）的应用程序来控制基于Flash的用户界面。 由于Flash运行时会泄漏大量的内存，因此我们将UI作为独立Flash Player中加载的.swf执行，与用C ++编写的命令与控制应用程序分开。
C ++以适当的参数作为外部进程启动Flash播放器，并通过连接到本地主机的TCP套接字与它进行通信。
该应用程序主要运行在Windows XP及更高版本上。
单独运行Flash播放器的不幸副作用是两个应用程序显示在Alt +选项卡列表中以及窗口上的任务栏（一个是我们的应用程序，另一个是Flash播放器）。 此外，由于应用程序全屏运行，Flash必须pipe理整个屏幕。 允许C ++应用程序绘制屏幕的一部分将是一个巨大的改进。
我们想以某种方式合并这两个，而把我们自己的应用程序控制。 我正在考虑一些Google Chrome浏览器，这些浏览器在单独的一个窗口中显示所有的输出结果，并在单独的过程中运行每个浏览器标签。
我一直在读Win32 API（和谷歌），以确定是否完成这是甚至可能的。 迄今为止，我已经提出了dll注入作为唯一的半可行的解决scheme，但我非常想考虑这个计划B.
任何build议，将不胜感激。
Alt + Tab列表显示顶层（无父窗口）可见的窗口，没有WS_EX_TOOLWINDOW扩展样式。 因此，如果您有两个窗口来自两个进程，但您只想在Alt-Tab列表（和任务栏上）中看到一个窗口，那么您有几个选择：
将WS_EX_TOOLWINDOW添加到其中一个窗口。
将其中一个窗口重新保存到隐藏的顶层窗口。
将其中一个窗口（可能是Flash播放器）重新保存到另一个窗口。 这很棘手，但这可能是Chrome和其他多进程单窗口应用程序的工作原理。 什么让棘手的是处理窗口的生命周期和无意中序列化消息队列。
我想这个问题和它的答案是与你的问题相关的：将Flash Player嵌入到C ++或Java应用程序中？
如果您将Flash Player实例化为进程内服务器，则DLL注入将不会将您带到任何地方，但仍然会在主进程中分配内存。
如果你想保持对内存泄漏的控制，你必须保持在一个单独的过程中的Flash播放器。
你目前的做法听起来是可行的，你唯一的问题似乎是，这个过程仍然是可见的像Alt + Tab列表…就我所知，设置扩展窗口样式WS_EX_TOOLWINDOW应该帮助你。
从任务栏隐藏进程请参阅例如这里 。