IRunningObjectTable::Register

Article
11/18/2015

A version of this page is also available for

4/8/2010

This method registers an object and its identifying moniker in the Running Object Table (ROT).

Syntax

HRESULT Register(
  DWORD grfFlags,
  IUnknown* punkObject,
  IMoniker* pmkObjectName,
  DWORD* pdwRegister 
);

Parameters

grfFlags
[in] Specifies whether the ROT's reference to punkObject is weak or strong and controls access to the object through its entry in the ROT. For details, see the Remarks section below.

punkObject
[in] Pointer to the object that is being registered as running.

pmkObjectName
[in] Pointer to the moniker that identifies punkObject.

pdwRegister
[out] Pointer to a 32-bit value that can be used to identify this ROT entry in subsequent calls to IRunningObjectTable::Revoke or IRunningObjectTable::NoteChangeTime.

The caller cannot specify NULL for this parameter.

If an error occurs, *pdwRegister is set to zero.

Return Value

This method supports the standard return values E_INVALIDARG and E_OUTOFMEMORY, as well as the following:

S_OK
The object was successfully registered.

MK_S_MONIKERALREADYREGISTERED
The moniker/object pair was successfully registered, but that another object (possibly the same object) has already been registered with the same moniker.

Remarks

This method registers a pointer to an object under a moniker that identifies the object. The moniker is used as the key when the table is searched with IRunningObjectTable::GetObject.

The grfFlags parameter accepts two flag settings:

ROTFLAGS_REGISTRATIONKEEPSALIVE. When set, indicates a strong registration for the object.
ROTFLAGS_ALLOWANYCLIENT. When set, any client can connect to the running object through its entry in the ROT. When not set, only clients in the window station that registered the object can connect to it.

When an object is registered, the ROT always calls AddRef on the object.

For a weak registration (ROTFLAGS_REGISTRATIONKEEPSALIVE not set), the ROT will release the object whenever the last strong reference to the object is released.

For a strong registration (ROTFLAGS_REGISTRATIONKEEPSALIVE set), the ROT prevents the object from being destroyed until the object's registration is explicitly revoked.

A server registered as either LocalService or RunAs can set the ROTFLAGS_ALLOWANYCLIENT flag in its call to Register to allow any client to connect to it.

A server setting this bit must have its executable name in the AppID section of the registry that refers to the AppID for the executable.

An activate as activator server (not registered as LocalService or RunAs) must not set this flag in its call to Register. For details on installing services, see Installing as a Win32 Service or User Account.

Registering a second object with the same moniker, or reregistering the same object with the same moniker, creates a second entry in the ROT. In this case, Register returns MK_S_MONIKERALREADYREGISTERED.

Each call to Register must be matched by a call to IRunningObjectTable::Revoke because even duplicate entries have different pdwRegister identifiers.

A problem with duplicate registrations is that there is no way to determine which object will be returned if the moniker is specified in a subsequent call to IRunningObjectTable::IsRunning.

To determine whether the platform supports this interface, see Determining Supported COM APIs.

Notes to Callers

If you are a moniker provider (that is, you hand out monikers identifying your objects to make them accessible to others), you must call the Register method to register your objects when they begin running. You must also call this method if you rename your objects while they are loaded.

The most common type of moniker provider is a compound-document link source. This includes server applications that support linking to their documents (or portions of a document) and container applications that support linking to embeddings within their documents.

Server applications that do not support linking can also use the ROT to cooperate with container applications that support linking to embeddings.

If you are writing a server application, you should register an object with the ROT when it begins running, typically in your implementation of IOleObject::DoVerb.

The object must be registered under its full moniker, which requires getting the moniker of its container document using IOleClientSite::GetMoniker. You should also revoke and reregister the object in your implementation of IOleObject::SetMoniker, which is called if the container document is renamed.

If you are writing a container application that supports linking to embeddings, you should register your document with the ROT when it is loaded. If your document is renamed, you should revoke and reregister it with the ROT and call IOleObject::SetMoniker for any embedded objects in the document to give them an opportunity to reregister themselves.

Objects registered in the ROT must be explicitly revoked when the object is no longer running or when its moniker changes. This revocation is important because there is no way for the system to automatically remove entries from the ROT.

You must cache the identifier that is written through pdwRegister and use it in a call to IRunningObjectTable::Revoke to revoke the registration. For a strong registration, a strong reference is released when the object's registration is revoked.

The system's implementation of IRunningObjectTable::Register calls IMoniker::Reduce on the pmkObjectName parameter to ensure that the moniker is fully reduced before registration. If an object is known by more than one fully reduced moniker, it should be registered under all such monikers.

Requirements

Header	objidl.h, objidl.idl
Library	ole32.lib, uuid.lib
Windows Embedded CE	Windows CE 3.0 and later
Windows Mobile	Windows Mobile Version 5.0 and later

Share via