Ureader.com  
Microsoft software help and Community
   home   |   control panel login   |   archive   |  
 
platform
active.directory
adsi
adsi.iis-admin
base
com_ole
complus_mts
component_svcs
database
directx
gdi
graphics_mm
internet.client
internet.server
internet.server.isapi-dev
localization
mapi
messaging
msi
mslayerforunicode
multimedia
networking
networking.ipv6
sdk_install
security
shell
telephony.tapi_2
telephony.tapi_3
telephony.tsp
telephony.wte
tools
ui
ui_shell
win_base_svcs
win16
  
 
date: Mon, 28 Nov 2005 08:03:00 +0100,    group: microsoft.public.platformsdk.com_ole        back       


2.) Does every CoClass have to support IClassFactory?   
Here is my second question:

2. Is it really true, that every class object must derive from
IClassFactory? Well, Don Box says something different on page 116:
"Class objects are not required to implement IClassFactory, but, for
uniformity, they often do." I understand that there are at least two
situations that make the IClassFactory interface necessary: (a) When I
want to aggregate an object. (b) When I want to access an out-of-proc
object (since COM wants to call LockServer() ).
I think the necessity to implement IClassFactory is extremely annoying.
Since I cannot pass any parameters for object creation (CreateInstance
takes no parameters), I cannot initialize the objects properly. One way
would be to adopt the MFC way of creating objects (like for CWnd objects
where one has to call some init() method AFTER the c'tor has finished).
I think that this is not the way object oriented code should be written,
such code is highly coupled. Is there some way to get around
IClassFactory (other than 'yes, but you can't use out-of-proc objects
any more')?

Thanks in advance,
Stuart
date: Mon, 28 Nov 2005 08:03:00 +0100   author:   Stuart Redmann

Re: 2.) Does every CoClass have to support IClassFactory?   
Stuart Redmann  wrote:
> Here is my second question:
>
> 2. Is it really true, that every class object must derive from
> IClassFactory?

In principle, it is possible to use a custom class factory, and indeed 
they are used in certain situations - see e.g. IPSFactoryBuffer. For 
most COM objects, the clients are hard-wired to use IClassFactory to 
instantiate them, so implementing a non-standard class factory would be 
pretty pointless - nobody will be able to use your object. If you have 
tight control over both the client and the server, and for some strange 
reason find it beneficial to implement a custom class factory, you are 
free to do it.

> I think the necessity to implement IClassFactory is extremely
> annoying. Since I cannot pass any parameters for object creation
> (CreateInstance takes no parameters), I cannot initialize the objects
> properly.

That's what persistence interfaces are for, such as IPersistPropertyBag, 
IPersistStreamInit.
-- 
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
date: Mon, 28 Nov 2005 10:59:06 -0500   author:   Igor Tandetnik

Google
 
Web ureader.com


    COPYRIGHT 2007, YARDI TECHNOLOGY LIMITED, ALL RIGHT RESERVE  |   contact us