Information
The topic you requested is included in another documentation set. For convenience, it's displayed below. Choose Switch to see the topic in its original location.

Runtime Storage Control Overview

Applies to

The information in this topic applies only to the specified Visual Studio Tools for Office projects and versions of Microsoft Office.

Project type

  • Document-level projects

Microsoft Office version

  • Microsoft Office 2003

For more information, see Features Available by Application and Project Type.

The Runtime Storage Control is an ActiveX control embedded in a document or workbook that is part of a document-level customization for Microsoft Office 2003. The Runtime Storage Control contains the following information needed by the Visual Studio Tools for Office runtime to run the customization:

  • The application manifest.

  • Zero or more cached data objects.

The Runtime Storage Control is embedded in the document when you build the project. It is not visible in the document at run time.

NoteNote:

Document-level customizations for the 2007 Microsoft Office system do not use the Runtime Storage Control. Instead, the Visual Studio Tools for Office runtime stores information as custom XML parts that are embedded in the documents.

The application manifest stores information needed to run the managed code extensions. The application manifest points either to a deployment manifest on the server, which contains the most recent location of the assembly, or it points directly to the customization assembly. For more information, see Application and Deployment Manifests in Office Solutions.

You can cache a data object in the document by using the CachedAttribute attribute when you declare the object. Caching reduces the number of round trips to the server, and makes it possible to interact with the data offline. For more information, see Data in Document-Level Customizations and Caching Data.

It is possible for end users to delete or copy the Runtime Storage Control. The following examples show how the Visual Studio Tools for Office runtime can detect and correct these circumstances.

End User Performs Select All and Presses Delete

The Runtime Storage Control is deleted. However, the control calls the Visual Studio Tools for Office runtime with information that it is about to be deleted. The runtime adds a new instance of the control to the document, hooks up to the new event sink, and provides persisted information.

End User Performs Select All, Then Copies and Pastes into the Same Document

There are now two Runtime Storage Controls. However, the runtime checks whether there are multiple instances of the control. If there are, it deletes the extra instances.

End User Performs Select All, then Copies and Pastes into a Different Document that Has Managed Code Extensions

There are two Runtime Storage Controls claiming to contain the primary stored information for the document. However, a unique identifier (GUID) is created for the control when it is embedded in the document at design time. This GUID is also embedded in the custom document property _AssemblyLocation. Any Runtime Storage Control in the document must also have this GUID. If an extra Runtime Storage Control is found in the document at load time, it is deleted from the document if the GUID does not match the one stored in the document.

End User Performs Select All, then Copies and Pastes into a New Blank Document

There is now a new document with an unused Runtime Storage Control. Without the proper customizations in the document, the control does not do anything. However, it still takes up space in the document.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

Show:
© 2014 Microsoft