| Home | Previous Lesson: Why Implement OLE? Next Lesson: Which One To Choose, DDE Or OLE ? |
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 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.
| Home | Previous Lesson: Why Implement OLE? Next Lesson: Which One To Choose, DDE Or OLE ? |