The following table provides a description of the attributes available from the Edit Attributes dialog box. Note that some attributes are available only for methods, while others are available only for properties. For more information about these and other attributes, see the Microsoft Interface Definition Language (MIDL) reference, available in the Platform SDK.
| Attribute | Purpose |
| call_as | Enables a nonremotable function to be mapped to a remote function. This is particularly helpful in interfaces that have numerous nonremotable types as parameters. Rather than using many represent_as and transmit_as types, you can combine all the conversions using call_as routines. You supply the two call_as routines (client side and server side) to bind the routine between the application calls and the remote calls. The call_as attribute can be used for object interfaces, where the interface definition can be used for local calls as well as remote calls because it allows a nonremotable interface to be remoted transparently. The call_as attribute cannot be used with /osf mode. |
| helpcontext | Specifies a context ID that lets the user view information about this element in the Help file. The helpcontext-value is a 32-bit context identifier within the Help file that can be retrieved with the GetDocumentation functions in the ITypeLib and ITypeInfo interfaces. |
| helpstring | Specifies a character string that is used to describe the element to which it applies. You can apply the helpstring attribute to library, importlib, interface, dispinterface, module, or coclass statements, and to typedefs, properties, and methods. Use the GetDocumentation functions in the ITypeLib and ITypeInfo interfaces to retrieve the help string. |
| hidden | Indicates that the item exists but should not be displayed in a user-oriented browser. This attribute allows you to remove members from your interface (by shielding them from further use) while maintaining compatibility with existing code. You can use the hidden attribute on properties, methods, and the coclass, dispinterface, interface, and library statements. When specified for a library, the hidden attribute prevents the entire library from being displayed. This usage is intended for use with controls. Hosts need to create a new type library that wraps the control with extended properties. |
| id | Specifies a DISPID for a member function (either a property or a method, in an interface or dispinterface). You use the id attribute when you want to assign a standard DISPID (like DISPID_VALUE, DISPID_NEWENUM, etc.) to a method or property, or when you implement your own IDispatch::Invoke instead of delegating to DispInvoke/ITypeInfo::Invoke. |
| restricted | Specifies that a library, or member of a module, interface, or dispinterface, cannot be called arbitrarily. For example, this prevents a data item from being used by a macro programmer. You can apply this attribute to a member of a coclass, independent of whether the member is a dispinterface or interface, and independent of whether the member is a sink (incoming) or source (outgoing). A member of a coclass cannot have both the restricted and default attributes. |
| source | Indicates that a member of a coclass, property, or method is a source of events. For a member of a coclass, this attribute means that the member is called rather than implemented. On a property or method, the source attribute indicates that the member returns an object or VARIANT that is a source of events. The object implements IConnectionPointContainer. |
| vararg | Specifies that the function takes a variable number of arguments. To accomplish this, the last argument must be a safe array of VARIANT type that contains all the remaining arguments. You cannot apply the optional or defaultvalue attributes to any parameters in a function that has the vararg attribute. |
| Methods only: | |
| callback | Declares a static callback function that exists on the client side of the distributed application. Callback functions provide a way for the server to execute code on the client. The callback function is useful when the server must obtain information from the client. If server applications were supported on Windows 3.x, the server could make a call to a remote procedure on the Windows 3.x server to obtain the needed information. The callback function accomplishes the same purpose and lets the server query the client for information in the context of the original call. Callbacks are special cases of remote calls that execute as part of a single thread. A callback is issued in the context of a remote call. Any remote procedure defined as part of the same interface as the static callback function can call the callback function. Only the connection-oriented and local protocol sequences support the callback attribute. If an RPC interface uses a connectionless (datagram) protocol sequence, calls to procedures with the callback attribute will fail. Handles cannot be used as parameters in callback functions. Because callbacks always execute in the context of a call, the binding handle used by the client to make the call to the server is also used as the binding handle from the server to the client. Callbacks can nest to any depth. |
| local | Can be applied to individual functions or to the interface as a whole. When used in the interface header, the local attribute allows you to use the MIDL compiler as a header generator. The compiler does not generate stubs for any functions and does not ensure that the header can be transmitted. For an RPC interface, the local attribute cannot be used at the same time as the uuid attribute. Either uuid or local must be present in the interface header, and the one you choose must occur exactly once. For an OLE interface (identified by the object interface attribute), the interface attribute list can include the local attribute even though the uuid attribute is present. When used in an individual function, the local attribute designates a local procedure for which no stubs are generated. Using local as a function attribute is a Microsoft extension to DCE IDL; therefore, this attribute is not available when you compile using the MIDL /osf switch. Note that an interface without attributes can be imported into a base IDL file. However, the interface must contain only datatypes with no procedures. If even one procedure is contained in the interface, a local or uuid attribute must be specified. |
| Properties only: | |
| bindable | Indicates that the property supports data binding. This allows the client to be notified whenever a property has changed value. (If you want the client to be notified of impending changes to a property, use the requestedit attribute.) Because the bindable attribute refers to the property as a whole, it must be specified wherever the property is defined; therefore, you need to specify the attribute on both the property-accessing function and the property-setting function. |
| defaultbind | Indicates the single, bindable property that best represents the object. Properties that have the defaultbind attribute must also have the bindable attribute. Only one property in an interface or dispinterface can have the defaultbind attribute. This attribute is used by containers that have a user model involving binding to an object rather than binding to a property of an object. An object can support data binding but not have this attribute. |
| defaultcollelem | Flags the property as an accessor function for an element of the default collection. Used for Visual Basic code optimization. If this attribute is present on a Get, it must also be present on a Put. |
| displaybind | Indicates a property that should be displayed to the user as bindable. Properties that have the displaybind attribute must also have the bindable attribute. An object can support data binding but not have this attribute. |
| immediatebind | Indicates that the database will be notified immediately of all changes to a property of a data-bound object. This attribute allows controls to differentiate between properties that need to notify the database of every change, and those that do not. For example, every change to a check box control should be sent to the underlying database immediately, even if the control has not lost the focus. However, for a list box control, a change occurs whenever a different selection is highlighted. Notifying the database of a change before the control loses focus would be inefficient and unnecessary. The immediatebind attribute allows individual properties on a form to specify, by setting the ImmediateBind bit, that changes should be reported immediately. Properties that have the immediatebind attribute must also have the bindable attribute. |
| nonbrowsable | Indicates that the property appears in an object browser, which does not show property values, but does not appear in a properties browser (which shows property values). |
| requestedit | Indicates that the property supports the OnRequestEdit notification. This means that, before a change is made, the object will send the client a request for permission to change a property. An object can support data binding but not have this attribute. |