| Previous | Next |
| TAPI_E_INVALCALLPRIVILEGE | TAPI_E_INVALCALLSTATE |
OLE_E_NOT_INPLACEACTIVE
OLE object is not in an in-place active state
OLE_E_NOT_INPLACEACTIVE is HRESULT 2147745808 (0x80040010) from winerror.h. The documented description is “Object is not in any of the inplace active states.” It belongs to IOleInPlaceObject or container commands that require an embedded object to have completed the appropriate activation transition. Diagnose it from the object’s current OLE state, not merely from whether its server process is running.
The caller reached a command that is valid only while the embedded object is active inside its container, but the object is inactive, only running, or has already been UI-deactivated.
Where the result appears
- This result can surface in a compound-document containers, embedded or linked objects, OLE activation, advising, caching, conversion, and persistence.
- Map the failure to one concrete operation among IOleObject, IOleLink, IOleCache, IAdviseSink, IPersistStorage, IOleInPlaceObject, monikers, verbs, and client-site callbacks.
- Preserve CLSID, object and client-site identity, storage or moniker, advise cookie, verb, activation state, window generation, and presentation format before releasing or replacing the object that returned this result.
Record the exact verb or interface method, the object and client-site identities, and the activation/deactivation callbacks immediately before the failure. Those details show whether the caller raced a state transition or invoked a command at the wrong lifecycle stage.
Typical causes and interpretation
The immediate contract boundary is a mismatch between the command and the object’s current container state. Common cause branches include the following:
- The activating verb was never completed.
- The object was deactivated before the command arrived.
- Container and server disagree about activation state.
Confirm the branch by correlating the failing call with DoVerb, client-site callbacks, window activation, UI deactivation, and any object replacement or teardown that occurred in the same generation.
Correct handling and recovery
The primary recovery is to synchronize the container and server lifecycle, then issue the command only after the required activation transition has completed. If the object has already been deactivated, start a new activation cycle instead of reusing stale window or interface state.
When it follows cancellation or replacement, create a fresh object/site generation, complete the activation callback sequence, and replay the command only after the object reaches the required embedded-active state.
Practical scenario
A toolbar sends a resize command after the embedded editor has UI-deactivated; the container waits until the object re-enters the state in which IOleInPlaceObject operations are valid.
Difference from related HRESULTs
OLE_E_NOTRUNNING concerns server execution; an object may be running yet still return it.
Developer and administrator guidance
A runbook should preserve the storage, verb/callback trace, client-site identity, and window-state evidence before reactivating or recreating the embedded object.
References
Looking for a different code? Search another status or error code.