| Home | Previous Lesson: Why Implement OLE? Next Lesson: Registration Database |
OLE and DDE allow you to perform similar actions. Both enable you to send commands to another application, perform actions in that application, and return data to your PowerBuilder application. There are, however, some fundamental differences between OLE and DDE.
OLE is currently implemented using the DDE protocol. Applications using OLE are not aware that DDE is being used, nor should they rely on this, because the implementation mechanism will not be there in future releases of the OLE components.
To illustrate some of the differences, consider a PowerBuilder application you've designed in which the user has access to a particular Microsoft Excel worksheet. Your PowerBuilder application contains the worksheet. In OLE operations, program control is actually temporarily transferred to Microsoft Excel for the purpose of manipulating the worksheet data. With DDE, operations occur when PowerBuilder sends a command to Microsoft Excel to start communication between the two applications. PowerBuilder, however, always has program control.
Another difference, which is an advantage of OLE, is that OLE automatically starts the object application when program control is transferred to the object application. When you use DDE, you must check to see if the source application (the DDE server) is started, and start it if necessary.
In addition, with OLE the data always is displayed in a bound or unbound object frame as it appears in the application that created the object. For example, if the object application is Microsoft Excel, a bound or unbound object frame displays worksheet data in your PowerBuilder application (the container application) as it appears in Microsoft Excel itself. DDE doesn't allow you to view the worksheet as it appears in the application.
Lastly, with OLE you can also allow the user to edit data in another application (activate that application) when the user double-clicks on the bound or unbound object frame containing the OLE object. DDE doesn't provide this feature because DDE can only activate other applications.
In versions of OLE prior to version 2.0, it was difficult to access linked or embedded data using PowerScript. Well, PowerBuilder implemented OLE in Window object from OLE 2.0 only. For example, if you created a linked object from a Microsoft Excel spreadsheet, you could allow the user to edit the spreadsheet's data, but it was difficult for you to access that data using PowerScript. With the advent of OLE Automation, its easy to access and manipulate data in an OLE object, as long as the application that supplies the object also supports OLE Automation. If you want programmatic access to data in an application that doesn't support OLE Automation (PaintBrush), you may still prefer to use DDE.
Determining a need for DDE and/or OLE support is perhaps less clear. DDE provides an excellent method of importing live data to an application or exporting live data from it. If two applications want to share and manipulate a piece of data without the direct involvement of the user, DDE is the choice.
If an application wants to include facilities to show data types such as Microsoft Excel graphs or sound files provided by OLE servers, OLE client support should be added. If an application has data-rendering capability useful to other applications, it should become an OLE server.
Let us consider the following example: The live data comes to the application A, has the capability of managing communications and receiving and displaying the data. Application B has the capability of plotting the data into variety of graphs. Application D has the capability of recording audio and playing back. Application C is the word processor.
The customer requirement is to produce a document that gives information about the company, with a graph for the recent stock market data and chairman's speech in audio format. The purpose of this example is to help illustrate how to choose the most appropriate type of communication support to include in an application.
In the case here, we begin with a live data feed attached to a communications port, convert it to a stream of DDE data, and finally end up with a linked OLE object.
Does it make sense to add OLE support to the Application A as either a client or a server? Not really. We have data that we can provide to another application, but the application could easily render it for itself, so we wouldn't need to be an OLE server. We have no need to incorporate other data in our display, so we don't need to be an OLE client either.
You might say that we could be an OLE server and display the data, but what purpose would this serve? If we didn't provide the data via DDE as well, the client application would only be able to show an image of the data and not access it in any other way. That means that it couldn't plot a graph, set trigger alarms, or whatever because an OLE client treats the data as a black box and has no knowledge of its format.
The Graph application need to be at least DDE client application, to accept data from the Application A. You might add DDE Server support, but, it is not required; this is because, for plotting the graph, it needs the data from other applications, but, it has no need of sending the data. Making this as OLE Server makes sense, because other applications can embed or link to this graph. Since the graph is in a special format, other application can invoke this application whenever it needs to be manipulated. Similarly sound recording application also should be at least OLE Server enabled.
Word-Processor application doesn't have much use for live, changing data that it needs to manipulate, so we aren't really interested in becoming a DDE client. Making this application into an OLE client makes a lot of sense. It enables other data types to be attached to the text being displayed, i.e., attaching a graph of our stock market prices and a sound recording of the CEO. We don't need to be able to render the images of these data types because that's the responsibility of the OLE server. We also get a free editor for our graph because the OLE server provides that support.
We could also add OLE server support for the word-processor. That way, the entire document could be linked to or embedded in another application document.
| Home | Previous Lesson: Why Implement OLE? Next Lesson: Registration Database |