KnowledgeBase Archive

An Archive of Early Microsoft KnowledgeBase Articles

View on GitHub

Q193265: PRB: VB Doesn’t Generate Compile Error for Misspelled Methods

Article: Q193265
Product(s): Microsoft Visual Basic for Windows
Version(s): 5.0,6.0
Operating System(s): 
Keyword(s): kbActiveX kbCOMt kbCtrlCreate kbVBp kbVBp500 kbVBp600 kbVC500 kbVC600 kbGrpDSVB kbDSupp
Last Modified: 07-MAY-2001

-------------------------------------------------------------------------------
The information in this article applies to:

- Microsoft Visual Basic Learning Edition for Windows, versions 5.0, 6.0 
- Microsoft Visual Basic Professional Edition for Windows, versions 5.0, 6.0 
- Microsoft Visual Basic Enterprise Edition for Windows, versions 5.0, 6.0 
- Microsoft Visual C++, 32-bit Enterprise Edition, versions 5.0, 6.0 
- Microsoft Visual C++, 32-bit Professional Edition, versions 5.0, 6.0 
- Microsoft Visual C++, 32-bit Learning Edition, version 6.0 
-------------------------------------------------------------------------------

SYMPTOMS
========

When using a COM component from Visual Basic, you may not receive a compile-
time error if you accidentally misspell a property or method name. Instead,
Visual Basic will generate the following error at run-time:

  Run-time error '438':
  Object does not support this property or method.

CAUSE
=====

This situation occurs when the object being referenced supports a dual or
dispinterface, and therefore can be late-bound. If the component designer did
not mark the interface as being "nonextensible," then Visual Basic cannot
determine if the misspelled method/property name is misspelled, or if it is a
new method or property added to the interface at a later time. Consequently,
Visual Basic does not raise an error at compile-time, but rather checks at
run-time whether the component supports a method/property by that name. The
run-time error occurs if the object does not have the named method/property.

The COM component creator can indicate whether or not an interface can be
extended at a later time. If the interface is marked as "nonextensible," then
Visual Basic will know at compile-time whether the object supports the named
method/property.

STATUS
======

This behavior is by design.

MORE INFORMATION
================

If you use Visual C++ to write your COM components, the default IDL files
generated by the IDE do not contain the "nonextensible" keyword. COM components
created in Visual Basic always contain this keyword.

If you are building a COM component in Visual C++, and would like to make your
dual or dispinterfaces nonextensible, simply add the "nonextensible" keyword to
the interface attributes. For example:

      importlib("StdOle2.tlb");

      [
        odl,
        uuid(ACF8C871-1A73-11D2-AC0A-00600832A1F6),
        version(1.0),
        dual,
        nonextensible,     // This is the line you need to add
        oleautomation
      ]
      interface IMyInterface : IDispatch {
          [id(0x68030000), propget]
          HRESULT __stdcall Name([out, retval] long* );
          [id(0x68030000), propput]
          HRESULT __stdcall Name([in] long );
          [id(0x60030001)]
          HRESULT __stdcall PopMsg();
      };

Additional query words: exist nonexistent

======================================================================
Keywords          : kbActiveX kbCOMt kbCtrlCreate kbVBp kbVBp500 kbVBp600 kbVC500 kbVC600 kbGrpDSVB kbDSupport 
Technology        : kbVCsearch kbVBSearch kbAudDeveloper kbZNotKeyword6 kbZNotKeyword2 kbVB500Search kbVB600Search kbVB500 kbVB600 kbVC500 kbVC600 kbVC32bitSearch kbVC500Search
Version           : :5.0,6.0
Issue type        : kbprb

=============================================================================

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Copyright Microsoft Corporation 1986-2002.