Re: Does it make sense to implement IProvideClassInfo with a noncreateable class
<renegade_master_12121@yahoo.co.uk> wrote in message
news:1168335286.209665.289060@51g2000cwl.googlegroups.com
I have a large object model with a hierarchy of objects where only the
top one is createable by the outside world (i.e. everything else if
marked noncreatable in the idl. Does it still make sense to provide
IProvideClassInfo on all these noncreatable classes? I guess I'm not
to sure of the intended use by clients of IProvideClassInfo - I'm
just trying to cover all the bases in my development of my app...
There is only one situation I know of where IProvideClassInfo[2] is used
in practice: to determine an object's default outgoing (source)
interface without knowing anything about the object besides an interface
pointer.
For example, scripts on HTML page require the object created by an
<object> tag to support this interface in order to sink events from it.
In this particular case, there is no syntax to sink events from
non-creatable objects. In another example, WScript.ConnectObject allows
a script running under WScript host to sink events from any object, no
matter how obtained. It too relies on the object implementing
IProvideClassInfo.
So, if your non-creatable objects are connection point containers, it is
prudent to have them support IProvideClassInfo[2].
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925