temp&latelt, claseThreadModel >
clase CComObjectRootEx: CComObjectRootBase pública
Parámetros
ThreadModel
La clase cuyos métodos de aplicación el modelo de subprocesamiento deseado. Puede elegir el modelo de subprocesamiento explícitamente estableciendo ThreadModel en CComSingleThreadModel, CComMultiThreadModelo CComMultiThreadModelNoCS. Puede aceptar el modelo de subproceso predeterminado del servidor mediante el establecimiento de ThreadModel a CComObjectThreadModel o CComGlobalsThreadModel.
CComObjectRootEx gestiona la administración de recuento de referencia de objeto para los objetos nonaggregated y agregados. Contiene el número de referencia de objeto si su objeto no es ser agregado y mantiene el puntero a lo desconocido exterior si su objeto es ser agregado. Para los objetos agregados, métodos de CComObjectRootEx pueden utilizarse para manejar el fracaso del objeto interno a construir y proteger el objeto externo que no se borren cuando se liberan las interfaces internas o se elimina el objeto interior.
Una clase que implementa un servidor COM debe heredar de CComObjectRootEx o CComObjectRoot.
Si la definición de clase especifica la macro DECLARE_POLY_AGGREGATABLE , ATL crea una instancia de CComPolyObjectlt;CSuClase > cuando se llama a IClassFactory::CreateInstance . Durante la creación, se comprueba el valor de lo desconocido exterior. Si es NULL, se implementa IUnknown para un objeto nonaggregated. Si el desconocido exterior no es NULL, se implementa IUnknown para un objeto agregado.
Si la clase no especifica la macro DECLARE_POLY_AGGREGATABLE , ATL crea una instancia de CComObjectlt;CSuClase > para objetos agregados o una instancia de CComAggObject <CYourClass> de nonaggregated objetos.
La ventaja de utilizar CComPolyObject es que se evita tener CComAggObject y CComObject en el módulo para manejar los casos agregados y nonaggregated. Un único objeto CComPolyObject maneja ambos casos. Por lo tanto, sólo un ejemplar de la vtable y uno de las funciones existentes en el módulo. Si tu vtable es grande, esto puede reducir considerablemente el tamaño del módulo. Sin embargo, si tu vtable es pequeño, utilizando CComPolyObject puede resultar en un tamaño ligeramente mayor de módulo porque no está optimizado para un objeto agregado o nonaggregated, como son CComAggObject y CComObject.
La macro DECLARE_POLY_AGGREGATABLE se agrega automáticamente a la definición de clase por el Asistente para objetos ATL cuando se crea un control total o el control de Internet Explorer.
Si el objeto es agregado, CComAggObject o CComPolyObjectimplementa IUnknown . Estas clases delegan llamadas a QueryInterface, AddRefy Release CComObjectRootEx OuterQueryInterface, OuterAddRefy OuterRelease a lo desconocido exterior. Normalmente, reemplazar CComObjectRootEx::FinalConstruct en su clase para crear los objetos agregados y reemplazar CComObjectRootEx::FinalRelease para liberar los objetos agregados.
Si el objeto no se agrega, se implementa IUnknown por CComObject o CComPolyObject. En este caso, llamadas a QueryInterface, AddRefy Release se delegan a CComObjectRootEx InternalQueryInterface, InternalAddRefy InternalRelease para realizar las operaciones reales.
# include lt;atlcom.h>
Vea tambié&nnbsp;CComAggObject, CComObject, CComPolyObject