DOCUMENT:Q193265  28-SEP-1998  [vbwin]
TITLE   :PRB: VB Doesn't Generate Compile Error for Misspelled Methods
PRODUCT :Microsoft Visual Basic for Windows
PROD/VER:WINDOWS:5.0,6.0; WINNT:5.0,6.0
OPER/SYS:WINDOWS winnt
KEYWORDS:

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

 - Microsoft Visual Basic Learning, Professional, and Enterprise Editions
   for Windows, versions 5.0, 6.0
 - Microsoft Visual C++, 32-bit Editions, versions 5.0, 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: kbDSupport kbDSD kbVBp kbVBp500 kbVBp600
kbCtrlCreate kbActiveX kbCOMt kbVC500 kbVC600
======================================================================
Version           : WINDOWS:5.0,6.0; WINNT:5.0,6.0
Platform          : WINDOWS winnt
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 1998.