Prior to the release of MICROSOFT.NET technologies, MICROSOFT ACTIVEX controls were a preferred technology for creating reusable components. One use of ACTIVEX controls is document hosting. Applications (such as MICROSOFT Excel and MICROSOFT Word) provided a design-time environment that allows end users to add ACTIVEX controls to a document, and through user interface elements (such as a property browser), define the behavior and attributes of the control. The applications also provided a runtime environment whereby the control would execute. In addition, many applications provide a scripting language (e.g., MICROSOFT VISUAL BASIC for Applications) which enables the end user to add code that would govern the ACTIVEX control's behavior at runtime. By supporting ACTIVEX controls, applications enabled a rich level of component use and customization by end users.
Unfortunately, the promise of ACTIVEX controls as reusable and customizable components on the document did not materialize. First, the controls themselves are extremely difficult and time consuming to develop. Second, the powerful customization that they offered is extremely susceptible to abuse. Documents containing ACTIVEX controls typically run the controls on load, which means that the mere act of opening a document makes end users vulnerable both to malicious controls and “good” controls being used in unintended and/or malicious ways.
With the advent of .NET, the WINDOWS Forms (WinForms) form package became available, which provides a way to create controls in managed code. Managed code is code that has its execution managed by the .NET Framework Common Language Runtime. WinForms controls can be easily created either from scratch or by extending an existing control. Because the controls are written in managed code, they run within constraints of the .NET Development Platform (NDP) security model, which makes them far less susceptible to abuse.
However, while WinForms controls eliminate the two disadvantages of their ACTIVEX counterparts, they cannot easily be hosted in unmanaged hosts (e.g., documents). The basic problem is that WinForms controls were designed to be hosted in Windows Forms, not on documents. WinForms controls expose the ACTIVEX interfaces that would enable them to be hosted in an ACTIVEX container, however, not all interfaces are provided. Most notably, IDataObject is missing, which means that WinForms controls cannot be cut, copied, or pasted. In addition, some of the existing implementation does not follow the rules of ACTIVEX. For example, WinForms controls do not support scaling. At runtime, the expected behavior is for such controls to deactivate if scaling is attempted. WinForms controls do not do this which results in poor behavior when hosts attempt to scale them.
In addition, the ACTIVEX implementation exposed by WinForms ensures that the control will be run immediately when a document is loaded. This is undesirable behavior because, as noted above, it means that opening a document may cause arbitrary code to run. Even though that code will run within the context of security policy, there is no guarantee that the user will be fully protected from all possible harm that could befall them, particularly if the user has granted full trust to any controls that are already installed on their machine.
Therefore, there is a need for a system of improving upon the WinForms ACTIVEX implementation, adding back the missing ACTIVEX implementation, and providing a mechanism for instantiating the managed control which occurs independently of document load and therefore can be accomplished in a secure way. The present invention provides solutions to this and other limitations in the prior art.
USPTO Backgrounds
USPTO Backgrounds