升级到VS2010后 IsWindow(activeX.GetSafeHwnd()) 始终为 false
我有一个 MFC 应用程序，它使用古老的（大约 1999 年）第三方 ActiveX 控件。
自从将项目从 VS2008 升级到 VS2010 以来，我遇到了问题...
在父对话框的 OnSize 处理程序中，IsWindow 始终为 control.GetSafeHwnd() 返回的句柄返回 false，即使 GetSafeHwnd() 返回非 NULL价值。控件的父对话框的其余部分显示正常，但它似乎没有响应任何输入。
我看过这篇文章，但是 GetSafeHwnd( ) 在这种情况下不会返回 NULL（在第一次调用它之后，即在实例化控件之前）。
该控件在加载时确实会导致输出跟踪消息“控件想要无窗口”。然而，在 VS2008 中编译时它也会这样做，所以这可能是一个转移注意力的事情。搜索此消息指出我要创建一个从 COleControlSite 派生的类，并否认控件无窗口性，但似乎没有可用的好示例，正如我所说，尚不清楚这是否真的是导致问题。
我还在 MSDN 的 VS2010 移植页面上发现了这个问题：
“使用 Visual C++ 6.0 编译的 ActiveX 控件，嵌入时 使用Visual C++ 2010开发的项目中的对话框，可以 使您的程序在运行时断言。在这种情况下，打开 与 Visual C++ 中的 ActiveX 控件关联的 ATL 或 MFC 项目 2010，然后重新编译它。断言将位于文件 occcont.cpp 中， 在源代码中的这一行：ASSERT(IsWindow(pTemp->m_hWnd))。”
我假设 VS6 编译的 ActiveX 控件存在一些问题，导致 IsWindow 的当前 Win32 实现将窗口句柄视为无效。解决方案当然没有帮助，因为它是第三方控件，我们无法重新编译它，
解决这个问题吗？
有人设法 VS2010 项目未在 Windows 2000 上运行，并且链接到 ODBC 时出错，但似乎无法在该项目上找到任何内容，
谢谢，
Chris 。
I have an MFC application that uses an ancient (circa 1999) third-party ActiveX control.
Since upgrading the project from VS2008 to VS2010, I'm having problems...
In the OnSize handler of the parent dialog IsWindow always returns false for the handle returned by control.GetSafeHwnd(), even when GetSafeHwnd() returns a non-NULL value. The rest of the control's parent dialog is displayed fine, but it doesn't seem to respond to any input.
I've seen this article, but GetSafeHwnd() isn't returning NULL in this case (after the first time that it is called, which is before the control is instantiated).
The control does cause the trace message "Control wants to be windowless" to be output when it's loaded. However it also does this when compiled in VS2008, so this may be a red herring. Searching for this message points me to creating a class derived from COleControlSite, and denying the control windowless-ness, but it seems there are no good example of this available, and as I say, it's not clear that this is really the cause of the problem.
I've also found this issue mentioned on MSDN's VS2010 porting page:
"An ActiveX control compiled by using Visual C++ 6.0, when embedded in
a dialog box in a project developed by using Visual C++ 2010, may
cause your program to assert at run time. In this situation, open the
ATL or MFC project associated with the ActiveX control in Visual C++
2010, and recompile it.. The assert will be in the file occcont.cpp,
on this line in source: ASSERT(IsWindow(pTemp->m_hWnd))."
I assume that there's something about VS6-compiled ActiveX controls that causes the window handles to be treated as invalid by the current Win32 implementation of IsWindow. The suggested solution is of course unhelpful as it's a third-party control, and we can't recompile it.
Has anyone managed to get around this?
I've already found solutions for VS2010 projects not running on Windows 2000, and errors linking to ODBC, but don't seem to be able to find anything on this one.
Thanks,
Chris
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我最终没有找到解决方案——将控件升级到VS2010兼容版本。
I didn't find a solution to this in the end - upgraded the controls to a VS2010-compatible version.
不管怎样，如果您不关心控件是否显示透明，您可以强制控件具有窗口 - 即使它可以在没有窗口的情况下运行。
您会看到，ActiveX 控件必须首先询问容器（将承载该控件的窗口）是否可以在没有窗口的情况下激活。这只是因为并非所有容器都支持无窗口激活。
如果此接口 (
IOleInPlaceSiteWindowless) 返回正常，则它将继续进行此特殊的无窗口激活，如果没有返回，将照常为控件创建一个窗口。免责声明：
我不知道这个“不必要的”窗口是否会让断言失败消失。换句话说：我不知道窗口句柄是否足够“深入”地传递到 AX 控件中。
有关 IOleInPlaceSiteWindowless 接口的更多信息：
https://msdn.microsoft。 com/en-us/library/windows/desktop/ms682300(v=vs.85).aspx
For what it's worth: if you don't care whether the control will appear transparent or not, you may force the control to have a window anyway - even though it can operate without a window.
You see, the ActiveX control must first ask the container (the window which will host the control) if it's okay to be activated without a window. This is simply because not all containers support windowless activation.
If this interface (
IOleInPlaceSiteWindowless) returns okay then it proceeds with this special windowless activation, if not a window will be created for the control as normal.Disclaimer:
I don't know if this 'unnecessary' window will make the assertion failure go away. In other words: I don't know if the window handle is passed down 'deep' enough into the AX control.
More about the
IOleInPlaceSiteWindowlessinterface:https://msdn.microsoft.com/en-us/library/windows/desktop/ms682300(v=vs.85).aspx