Microsoft KB Archive/146120

From BetaArchive Wiki
< Microsoft KB Archive
Revision as of 09:08, 21 July 2020 by X010 (talk | contribs) (Text replacement - """ to """)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Knowledge Base


How to use an OLE control as an automation server in Visual C++

Article ID: 146120

Article Last Modified on 11/21/2006



APPLIES TO

  • Microsoft Foundation Class Library 4.2, when used with:
    • Microsoft Visual C++ 4.0 Standard Edition
    • Microsoft Visual C++ 4.1 Subscription
    • Microsoft Visual C++ 4.2 Enterprise Edition
    • Microsoft Visual C++ 5.0 Enterprise Edition
    • Microsoft Visual C++ 6.0 Enterprise Edition
    • Microsoft Visual C++ 4.2 Professional Edition
    • Microsoft Visual C++ 5.0 Professional Edition
    • Microsoft Visual C++ 6.0 Professional Edition
    • Microsoft Visual C++ 6.0 Standard Edition
    • Microsoft Visual C++ .NET 2002 Standard Edition
    • Microsoft Visual C++ .NET 2003 Standard Edition



This article was previously published under Q146120

Note Microsoft Visual C++ .NET 2002 and Microsoft Visual C++ .NET 2003 support both the managed code model that is provided by the Microsoft .NET Framework and the unmanaged native Microsoft Windows code model. The information in this article applies only to unmanaged Visual C++ code.

SUMMARY

In situations where an OLE container doesn't support control containment, you may want to use an OLE control as an automation server to gain access to its properties and methods. This article explains the necessary modifications you need to make in order for an OLE control to function as a normal automation server.

MORE INFORMATION

Prior to Visual C++ 4.0, an OLE control could be used as an automation server without any modification. However, in MFC 4.0, the framework's implementation of IDispatch::Invoke calls the virtual function IsInvokeAllowed to determine if an automation server is in the appropriate state to handle automation calls. The default implementation in CCmdTarget::IsInvokeAllowed returns TRUE, implying that a server can handle automation calls.

In the case of an OLE control, COleControl::IsInvokeAllowed checks to see if the control has been either initialized or loaded properly through the persistent storage interfaces. If the control has the appropriate state information, then this function returns TRUE. When an OLE control is created as a normal automation server, it is not created as an embedding in the client. Hence, none of the persistent state initialization will take place, which thereby causes IsInvokeAllowed to return FALSE. The effect of this is that a call to an automation object method generates a run-time error of (8000ffff) : "Catastrophic failure".

In order to use an OLE control only as an automation server, you need to override COleControl::IsInvokeAllowed() and return TRUE. If any of the control's properties and methods should not be accessed when invoked as a normal automation server, then that automation function could be bypassed and/or an error code can be returned when COleControl::m_bInitialized is FALSE.

Sample code

   BOOL CMyOleControl::IsInvokeAllowed (DISPID)
   {
      // You can check to see if COleControl::m_bInitialized is FALSE
     // in your automation functions to limit access.
     return TRUE;
   }
                


Additional query words: ocx OLE Automation error

Keywords: kbautomation kbcode kbctrlcreate kbhowto kbinprocsvr KB146120