Creating Interfaces for Use With the Implements Statement

When you create interfaces for use with the Implements statement, you can use Visual Basic or any tool that creates type libraries, such as the MkTypLib utility or the Microsoft Interface Definition Language (MIDL) compiler.

Most classes created in Visual Basic define interfaces that work with Implements. When you create an interface by defining a class in Visual Basic, simply make sure that none of the properties or methods have underscores in their names.

Interfaces created with tools other than Visual Basic must follow certain restrictions in order to work with Implements. The following list includes most of these restrictions.

• Interface methods cannot have underscores in their names.
  
  
• Only [in] and [in,out] params are allowed; neither [out] only params nor [lcid] arguments are allowed.
  
  
• Method return types must be HRESULT, in order for errors to be propagated. You will not see the HRESULT in Visual Basic, as it is translated into an exception (raised error). To create a method that will have a return type when used in Visual Basic code, you must use [out, retval] on the final parameter.
  
  
• Only Automation data types may be used:

  VB Data Type	MIDL Equivalent
  Integer	short
  Long	long
  Single	float
  Double	double
  Byte	unsigned char
  Boolean	boolean or VARIANT_BOOL
  String	BSTR
  Variant	VARIANT
  Date	DATE
  Currency	CURRENCY or CY
  Object	IDispatch
  IUnknown	IUnknown

  
  
• SAFEARRAY parameters containing any of the simple data types from the list above are allowed.
  
  
• Enum parameters are allowed.
  
  
• Dispinterface interface pointers are allowed as parameters.
  
  
• Dual interface pointers are allowed as parameters.
  
  
• CoClass parameters are allowed.

Warning   If you're creating a type library in order to make a system interface usable with Implements, you must not use the [oleautomation] or [dual] attributes. Type libraries must be registered before you can add them to the Visual Basic References dialog box, and registering a type library with the [oleautomation] attribute will overwrite information required to remote the system interface. This will cause other applications on the system to fail. The [dual] attribute must not be used because it implies [oleautomation].

Note   It may be useful to specify [oleautomation] while creating the typelib, in order to enforce correct types, but the type library must be built without the attribute before you reference it through the Visual Basic References dialog box.

• Unsigned long and unsigned short parameters are not included in the data type table and are not allowed.
  
  
• User-defined data types (structures) are not allowed as parameters.
  
  
• Interfaces must be based on IUnknown or IDispatch. The full vtable (after IUnknown/IDispatch) must be described in a single interface.
  
  
• Restricted vtable entries are ignored and do not prevent the Implements statement from working.
  
  
• Most pointers cannot be passed as [in] parameters. (For example, as a remoting optimization, a C++ interface can declare a parameter as [in] VARIANT* pVar. This will not work with Implements.) An [in] parameter can be a BSTR, a pointer to an interface (for example, IDispatch*), or a SAFEARRAY pointer (SAFEARRAYs are always passed as pointers). An [in,out] parameter can be a pointer to an Automation type, or a double pointer to an interface (for example, IDispatch**). (Note that 'ByVal As String' in Visual Basic maps to [in] BSTR. You cannot use [in] BSTR* with Visual Basic.)
  
  
• Implements does not work with dispinterfaces.

For More Information   See "Polymorphism" in "Programming with Objects" in the Programmer's Guide, and also "Providing Polymorphism by Implementing Interfaces" in "General Principles of Component Design" in Creating ActiveX Components in the Component Tools Guide.