temp&latelt, classeThreadModel > ;
Class CComObjectRootEx : public CComObjectRootBase
Paramètres
ThreadModel
La classe dont les méthodes implémentent le modèle de thread désiré. Vous pouvez explicitement le modèle de thread en affectant à ThreadModel CComSingleThreadModel, CComMultiThreadModelou CComMultiThreadModelNoCS. Vous pouvez accepter le modèle de thread du serveur par défaut en définissant ThreadModel sur la CComObjectThreadModel ou CComGlobalsThreadModel.
CComObjectRootEx gère la gestion comte de référence des objets pour les objets non agrégées et agrégées. Il tient le décompte de références objet si votre objet n'est pas être agrégée et détient le pointeur à l'extérieur inconnu si votre objet est être agrégée. Pour les objets agrégés, les méthodes de CComObjectRootEx peuvent servir à gérer l'échec de l'objet interne de construire et de protéger l'objet externe de suppression lorsque les interfaces internes sont libérés ou l'objet interne est supprimé.
Une classe qui implémente un serveur COM doit hériter de CComObjectRootEx ou CComObjectRoot.
Si votre définition de classe spécifie la macro DECLARE_POLY_AGGREGATABLE , ATL crée une instance de CComPolyObjectlt ;CYourClass > quand IClassFactory::CreateInstance est appelée. Lors de la création, la valeur de l'inconnu externe est vérifiée. Si elle est NULL, IUnknown est mis en œuvre pour un objet non agrégée. Si l'inconnu externe n'est pas NULL, IUnknown est mis en oeuvre pour un objet agrégé.
Si votre classe ne spécifie pas la macro DECLARE_POLY_AGGREGATABLE , ATL crée une instance de CComObjectlt ;CYourClass > pour les objets agrégés ou une instance de CComAggObject <CYourClass> pour les objets non agrégées.
L'avantage de l'utilisation de CComPolyObject est que vous éviter d'avoir les CComAggObject et CComObject dans votre module pour gérer les affaires agrégés et non agrégées. Un seul objet CComPolyObject gère les deux cas. Par conséquent, seule une copie de la vtable et une copie des fonctions existent dans votre module. Si votre vtable est importante, cela peut réduire considérablement la taille de votre module. Toutefois, si votre vtable est petite, à l'aide de CComPolyObject peut entraîner une taille légèrement plus grande du module parce qu'il n'est pas optimisé pour un objet agrégé ou non agrégée, comme sont CComAggObject et CComObject.
La macro DECLARE_POLY_AGGREGATABLE est automatiquement ajoutée à votre définition de classe par l'Assistant objet ATL lorsque vous créez un contrôle complet ou Internet Explorer.
Si votre objet est agrégée, IUnknown est mis en œuvre par CComAggObject ou CComPolyObject. Ces classes représentant des appels QueryInterface, AddRefet Release de CComObjectRootExde OuterQueryInterface, OuterAddRefet OuterRelease de transmettre à l'extérieur inconnu. Généralement, vous substituez CComObjectRootEx::FinalConstruct dans votre classe pour créer tous les objets agrégés et substituez CComObjectRootEx::FinalRelease à libérer tous les objets agrégés.
Si votre objet n'est pas agrégé, IUnknown est mis en œuvre par CComObject ou CComPolyObject. Dans ce cas, les appels QueryInterface, AddRefet Release sont déléguées à CComObjectRootExde InternalQueryInterface, InternalAddRefet InternalRelease pour effectuer les opérations réelles.
# include lt;atlcom.h>
Voir aussi ;CComAggObject, CComObject, CComPolyObject