Skip to content

Latest commit

 

History

History
164 lines (125 loc) · 9.04 KB

nf-objidl-irunningobjecttable-register.md

File metadata and controls

164 lines (125 loc) · 9.04 KB
UID title description helpviewer_keywords old-location tech.root ms.assetid ms.date ms.keywords req.header req.include-header req.target-type req.target-min-winverclnt req.target-min-winversvr req.kmdf-ver req.umdf-ver req.ddi-compliance req.unicode-ansi req.idl req.max-support req.namespace req.assembly req.type-library req.lib req.dll req.irql targetos req.typenames req.redist ms.custom f1_keywords dev_langs topic_type api_type api_location api_name
NF:objidl.IRunningObjectTable.Register
IRunningObjectTable::Register (objidl.h)
Registers an object and its identifying moniker in the running object table (ROT).
IRunningObjectTable interface [COM]
Register method
IRunningObjectTable.Register
IRunningObjectTable::Register
ROTFLAGS_ALLOWANYCLIENT
ROTFLAGS_REGISTRATIONKEEPSALIVE
Register
Register method [COM]
Register method [COM]
IRunningObjectTable interface
_com_irunningobjecttable_register
com.irunningobjecttable_register
objidl/IRunningObjectTable::Register
com\irunningobjecttable_register.htm
com
40f815b2-dfea-416c-aae1-7ba3a710ad91
12/05/2018
IRunningObjectTable interface [COM],Register method, IRunningObjectTable.Register, IRunningObjectTable::Register, ROTFLAGS_ALLOWANYCLIENT, ROTFLAGS_REGISTRATIONKEEPSALIVE, Register, Register method [COM], Register method [COM],IRunningObjectTable interface, _com_irunningobjecttable_register, com.irunningobjecttable_register, objidl/IRunningObjectTable::Register
objidl.h
Windows
Windows 2000 Professional [desktop apps only]
Windows 2000 Server [desktop apps only]
ObjIdl.idl
Windows
19H1
IRunningObjectTable::Register
objidl/IRunningObjectTable::Register
c++
APIRef
kbSyntax
COM
ObjIdl.h
IRunningObjectTable.Register

IRunningObjectTable::Register

-description

Registers an object and its identifying moniker in the running object table (ROT).

-parameters

-param 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.

Value Meaning
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.

-param punkObject [in]

A pointer to the object that is being registered as running.

-param pmkObjectName [in]

A pointer to the moniker that identifies punkObject.

-param pdwRegister [out]

An identifier for this ROT entry that can be used 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.

-returns

This method can return the standard return values E_INVALIDARG and E_OUTOFMEMORY, as well as the following values.

Return code Description
S_OK
The method completed successfully.
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.

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 Service Application.

Registering a second object with the same moniker, or re-registering 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.

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 re-register 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 re-register it with the ROT and call IOleObject::SetMoniker for any embedded objects in the document to give them an opportunity to re-register 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 objects registration is revoked.

As of Windows Server 2003, if there are stale entries that remain in the ROT due to unexpected server problems, COM will automatically remove these stale entries from the ROT.

The system's implementation of 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.

-see-also

IRunningObjectTable