IsWindow(activeX.GetSafeHwnd()) always false after upgrade to VS2010

0
votes

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

2
visual-studio-2010visual-c++mfcactivex
support.microsoft.com/kb/949107 – Hans Passant
Sorry, I don't think that's relevant: "Development or migration of an MFC application with ActiveX controls in Visual Studio 2005 SP1." – Chris
Is there any code generated from typelib import or similar that may be hanging around from before the upgrade from a VS2008 project? Some of these files will not be removed by a clean. – Aidan Ryan
Yes, they would be as they're under source control. I'll try re-importing it tomorrow. – Chris
I can't reimport the control. I suppose it's just not going to work. Guess we'll be shelling out $1000 for the latest version... – Chris

2 Answers

0
votes

I didn't find a solution to this in the end - upgraded the controls to a VS2010-compatible version.

0
votes

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 IOleInPlaceSiteWindowless interface: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682300(v=vs.85).aspx