All geek questions in one place

IsWindow (activeX.GetSafeHwnd ()) is always false after upgrading to VS2010

I have an MFC application that uses an antique (circa 1999) third-party ActiveX control.

I have been having problems since updating the project from VS2008 to VS2010 ...

In the OnSize handler of the parent dialog, IsWindow always returns false for the handle returned by the control. GetSafeHwnd (), even if GetSafeHwnd () returns a non-NULL value. The rest of the parental control dialog is displayed in order, but it does not seem to respond to any data.

I saw this article , but GetSafeHwnd () does not return NULL in this case (after the first time it is called, which is before the control is created).

The control causes the trace message "Management wants to be windowless" is displayed at boot time. However, it also does this when compiling in VS2008, so it could be a red herring. A search for this message tells me to create a class derived from COleControlSite and give up control without windows, but there seems to be no good example of this, and as I said, it is unclear that this is really causing the problem.

I also found this problem mentioned on the MSDN VS2010 migration page :

"An ActiveX control compiled using Visual C ++ 6.0 when embedded in a dialog box in a project developed using Visual C ++ 2010 can cause your program to approve at run time. In this situation, open an ATL or MFC project, associated with the ActiveX control in Visual C ++ 2010, and recompile it. The statement will be in the occcont.cpp file, on this line in the source: ASSERT (IsWindow (pTemp-> m_hWnd)).

I assume that something is related to VS6-compiled ActiveX controls, which make window descriptors invalidated by the current Win32 IsWindow implementation. The proposed solution, of course, is useless, because it is a third-party control, and we can not recompile it.

Could anyone get around this?

I already found solutions for VS2010 projects that do not work in Windows 2000, and ODBC related errors, but don't seem to be able to find anything on this.

Thanks,

Chris

0
source share
2 answers

In the end, I did not find a solution for this - I updated the controls to a version compatible with VS2010.

0
source

Why is it worth it: if you don't care if the control is transparent or not, you can force the control to have a window anyway - even if it can work without a window.

You see that the ActiveX control must first ask the container (the window in which the control will be placed) if it is activated without a window. This is simply because not all containers support windowless activation.

If this interface ( IOleInPlaceSiteWindowless ) returns to normal, it proceeds to this special windowless activation unless a window is created for the control as usual.

Disclaimer: I do not know if this "unnecessary" window with the approval error will disappear. In other words: I don't know if the window handle is passed “deep” to the AX control.

More information about the IOleInPlaceSiteWindowless interface: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682300(v=vs.85).aspx

0
source

Source: https://habr.com/ru/post/1442266/

More articles:


All Articles