Ole

Object List Hierarchy Next Object

Definition:

The OLE control provides an interface to the technology of Object Linking and Embedding.

The OLE technology allows Windows-based application programmers to create applications that can display data from several other Windows-based applications as well as integrate the functions of the active application into the Phoenix application's toolbar. A user can then edit and update the data from within the original application without having to exit the Phoenix application.

Applications that allow OLE automation allow you to use their objects, properties, and methods just as you use custom Phoenix objects, and methods.

Icon:

images/Phx00203.gif

Specialized Features:

The following tables list and describe the properties, methods, and events that are added by OLE:

Properties Use to...

Action Determine an action the OLE control will take to do something with the object.

AppIsRunning Determine whether the application that created the object in the OLE control is currently running.

Automate Return an Automation object if the Ole Server supports it.

Class Determine the class name of an embedded OLE object.

HostName Determine the user-readable name of your Phoenix application.

lpOleObject Provide the memory address of an OLE object.

ObjectVerbs Return one of the verbs or actions that an object supports.

ObjectVerbsCount Return the total number of verbs currently supported by an object.

ObjectVerbFlags Determine the menu state for each verb supported by a particular OLE object.

ObjectVerbsIndex Indexes the ObjectVerbs and ObjectVerbFlags properties.

OleType Specify the type of object in an OLE control.

OleTypeAllowed Determine the kind of object the OLE control can contain.

PasteOk Indicate whether the contents of the Clipboard can be pasted into the designated OLE control.

SizeMode Determine how the OLE control is sized or how its image is displayed when it contains an object.

SourceDoc Determine the file name to use when you create an OLE object.

Text Sends or retrieves a string from an OLE object that was created in an application that does not support OLE automation.

Verb Specify which of the supported actions to perform when an object is activated using Action 7 - Do Verb.

Methods Use to...

GetData Get an XferData object containing the data formats of an OLE object.

GetPicture Get an XferData object containing Metafile, Dib, and Bitmap presentations of the OLE Server.

SetData Set an object's data formats from an XferData object.

Events Use to...

DoInsertObject Replaces the default Insert Object dialog.

Copied Features:

images/Phx00204.gif Properties images/Phx00205.gif Methods images/Phx00206.gif Events

Details:

Use the OLE control on a form to display an OLE object in your Phoenix application. To create the object, use the OLE Insert Object dialog or set the Class or Action properties.

The capability to incorporate the functions of several applications for which you haven’t written any code, provides you with almost endless possibilities for creating very powerful applications in a relatively short amount of time.

OLE Terms and Concepts

To gain a better understanding of the OLE technology, it is helpful to know the definition of certain fundamental terms and concepts. This information is provided as follows:

OLE Object: An OLE object points to a particular unit of data that is provided by an OLE application. One application can reveal a surprizing number of object types. For example, a spreadsheet application can support several distinct object types such as chart, cell or range of cells, worksheet, or macro sheet.

With the OLE control you can create linked and embedded objects. These linked or embedded objects contain the name of the application that provided the object or the object's data, and an image of what the data looks like. Only one object is allowed in an OLE control at any one time.

Class: An object’s class identifies the program that supplies the OLE object along with the object’s data and data type. Some example class names include MSDraw, CorelChart, SoundRec, and ExcelWorksheet. The available classes vary from system to system.

Container Application: An application becomes a “container” when the OLE control is used to embed or link data from another application. This container application then receives the object’s data and also displays it.

Linked Objects: One way an OLE control allows data from other applications to be brought into an Phoenix application is by linking. When an OLE object is linked, the OLE control simply stores an image of the data and a link pointing back to the original data. The original data is stored in the source file for that object. This is the feature that allows an object’s data to be accessed from within several different applications that contain a link to that data.

If modifications are made to a linked object, the changes will appear in all the applications linked to it.

Embedded Objects: Another way an OLE control allows data from other applications to be brought into an Phoenix application is by embedding. Data associated with an embedded object is actually stored in the OLE control itself. This data can be saved by your Phoenix application and stored in a file. This file contains the name of the application that created the object originally, the actual data, and an image of the data for display. It is this feature that prevents all other applications from accessing the data.

You have complete control of embedded data, meaning that only your application can maintain the data that is produced and edited in another application.

OLE Automation: OLE Automation is supported by a growing number of applications. These applications provide compatible objects for operations involving OLE automation. Some objects that support OLE automation also support linking and embedding. If an object in the OLE control supports OLE Automation, you can access its data using the Automate property.

In-place editing: Some OLE Objects support in-place editing, meaning there is no need to launch the application of origin in a separate window. You can use the Phoenix application to manipulate these objects as if they were its own. The menu, toolbars, etc. of the container application are automatically replaced with those of the object’s application.

DDE-vs-OLE: Although DDE (Dynamic Data Exchange) and OLE are a lot alike because they both allow you to share data and send commands back and forth between applications, they are also very different.

One such difference is the fact that OLE exchanges it’s data in the format of its original application; DDE exchanges totally unformatted data. You must provide all the formatting.

Another difference is that data exchanged using OLE is completely editable; information exchanged using DDE is not. You must provide the means for further manipulating data received in a Dynamic Data Exchange. When you edit an OLE object in your Phoenix program you are using the menus, tools, etc., of the actual application.

These previous differences result from the fact that OLE temporarily shifts control back to the originating application for any data manipulation; DDE operates entirely within your Phoenix application.