Visual Basic 6 Programming Blue Book: The Most Complete, Hands-On Resource for Writing Programs with Microsoft Visual Basic 6!:Object Linking And Embedding
function GetCookie (name) { var arg = name + "="; var alen = arg.length; var clen = document.cookie.length; var i = 0; while (i < clen) { var j = i + alen; if (document.cookie.substring(i, j) == arg) { var end = document.cookie.indexOf (";", j); if (end == -1) end = document.cookie.length; return unescape(document.cookie.substring(j, end)); } i = document.cookie.indexOf(" ", i) + 1; if (i == 0) break; } return null; } var m1=''; var gifstr=GetCookie("UsrType"); if((gifstr!=0 ) && (gifstr!=null)) { m2=gifstr; } document.write(m1+m2+m3);            Keyword Title Author ISBN Publisher Imprint Brief Full  Advanced      Search  Search Tips Please Select ----------- Components Content Mgt Certification Databases Enterprise Mgt Fun/Games Groupware Hardware IBM Redbooks Intranet Dev Middleware Multimedia Networks OS Prod Apps Programming Security UI Web Services Webmaster Y2K ----------- New Titles ----------- Free Archive To access the contents, click the chapter and section titles. Visual Basic 6 Programming Blue Book: The Most Complete, Hands-On Resource for Writing Programs with Microsoft Visual Basic 6! (Publisher: The Coriolis Group) Author(s): Peter G. Aitken ISBN: 1576102815 Publication Date: 08/01/98 function isIE4() { return( navigator.appName.indexOf("Microsoft") != -1 && (navigator.appVersion.charAt(0)=='4') ); } function bookMarkit() { var url="http://www.itknowledge.com/PSUser/EWBookMarks.html?url="+window.location+"&isbn=0"; parent.location.href=url; //var win = window.open(url,"myitk"); //if(!isIE4()) // win.focus(); } Search this book:  














Previous
Table of Contents
Next




Chapter 10Object Linking And Embedding


Object Linking and Embedding makes the software component approach available to the end user as well as the programmer.
You’ve probably heard a lot about the promise of software components—at the very least, you’ve read about it in this book. If you’ve been paying attention for the past nine chapters, you should be aware that the ability to combine prewritten functional software modules into a final application is a powerful approach to programming, indeed. But what about nonprogrammers—a category that includes most end users? Can the software component paradigm be extended to them as well? That’s the goal of Object Linking and Embedding, or OLE.
OLE Basics
The meaning of the term OLE has undergone several changes. Not too long ago, it referred to the broad area of software components—the various technologies by which the capabilities of chunks of software were made available to other programs. Under this scheme, Visual Basic controls were called OLE controls. Now a shift has occurred, where the new term ActiveX refers to Microsoft’s overall technology for software components. OLE has come to have a more restricted meaning related to the creation of compound documents—in other words, documents whose contents are created and manipulated by more than one program. With OLE, the Visual Basic programmer has access to the capabilities of a variety of other programs and can combine them to create the most efficient solution to his or her data processing needs.

TIP:  OLE Vs. DDE
OLE is similar to DDE (Dynamic Data Exchange) in some respects, but they have more differences than similarities. The two standards should not be viewed as competing methods for achieving the same goal, but rather as two different tools that are appropriate for different tasks. In almost all cases, the nature of the task will determine whether you use OLE or DDE.



What Does OLE Do?
At this point, you may be thinking, “Sounds great, but I still don’t know exactly what OLE does.” Rather than describe it in the abstract, let’s look at a concrete example. Suppose that you are using Microsoft Word to write a document, and you want to include a technical diagram created with the CorelDraw illustration program. Before OLE, you would have to create the diagram in CorelDraw, save it to disk in a format Word could import, then switch to Word and import the figure into your document. If you needed to modify the diagram later, you had to make the changes in CorelDraw, save the file again, and reimport it into Word.

With OLE, the process is a lot simpler—centered more on the document and less on the individual applications used to create it. You use the Insert Object command to insert a CorelDraw diagram in your document. A blank, sizable window appears in the document at the selected location, displaying an empty CorelDraw diagram. You are still in Word, but Word’s menus and toolbars have been replaced by CorelDraw’s menus and toolbars. Now you have all of CorelDraw’s tools and commands available to work on the diagram even though you have never left Word. After you create the diagram, click on the document outside the diagram window, and Word’s own menus and toolbars reappear, permitting you to continue working on the text part of the document. To modify the diagram, double-click on it, and CorelDraw’s menus and toolbars display again.
OLE In Visual Basic
As you might imagine, OLE is terribly complex under the hood. Fortunately, Visual Basic programmers don’t have to look under the hood. The OLE Container control makes OLE ridiculously easy, because the complex workings of OLE are hidden within the control. All you have to do to have OLE at your fingertips is drop the control into your Visual Basic program. Okay, it’s not quite that easy, but the benefits are worth the effort.

OLE really has three parts: the linking and embedding parts described earlier, and another component called OLE automation. In the first part of this chapter, we’ll cover the fundamental concepts and terms of the linking and embedding parts of OLE. Later in the chapter, we’ll deal with OLE automation.
OLE Terminology
OLE has a terminology all its own. This section will present these terms and explain some of the details of how OLE works.

Containers, Servers, And Objects
OLE interactions involve two Windows applications known as the container and the server. In the example presented earlier, Word was the container, and CorelDraw was the server. The unit of data that can be manipulated using OLE is called an object. In the earlier example, the CorelDraw diagram was the object. Data objects are provided, or exposed, by various applications, such as word processors and drawing programs. A server is an application that can expose OLE objects.
(Earlier versions of OLE had a slightly different terminology—if you happen to be familiar with it, you may become confused. The container application used to be called the client or the destination, and the server application was the source.)
In OLE, object is simply a fancy way of saying data. More precisely, an OLE object is any item of data that can be displayed by an OLE container application. An object can be almost anything—an entire graphic diagram, a section of a word-processing document, or a single spreadsheet cell. The characteristics of a data object are defined by the server application where the data object originates.
Every OLE object has a class that specifies the name of the server application that exposes the data object. In addition to the server application name, the class specifies the object’s data type and the server’s version number. For example, a chart object exposed by Microsoft Excel version 6 has the class “Excel.Chart.6”. When you install applications under Windows, they provide Windows with information about any OLE objects they can expose. This information, which is kept in the Windows registry, is used by container applications to determine the type of OLE objects available on the current system.
You can see a list of the classes that are registered on your system by placing an OLE control on a Visual Basic form and selecting its Class property in the Properties window. You’ll see the same list if you run a container application, such as a word processor, and issue the command to insert an OLE object (in Microsoft Word, the command is Insert Object). Figure 10.1 shows the Object dialog box in Microsoft Word, listing the OLE objects available on my system.
It’s Really Linking Or Embedding

OLE should really be called “object linking or embedding,” because linking and embedding are two different ways of sharing data. You do not link and embed an object—you either link it or you embed it. The difference between linking and embedding has to do with where the data is stored and whether other applications have access to it.
Both linked and embedded objects are displayed in the container application and can be edited using the server application. The container application has a placeholder for a linked object, but it does not contain the data itself. The data is stored elsewhere—in a file associated with the server application. When an object is embedded, the container application actually contains the data, and the data is stored as part of the container application’s data file.
Let’s look at this distinction in terms of the earlier example. If you had linked the CorelDraw diagram to the Word document, the diagram would exist as a separate file in CorelDraw’s standard data file format. The Word document would exist as a separate file in Word format, containing a placeholder for the CorelDraw diagram. If you had embedded the diagram, you would not have a separate CorelDraw file containing the diagram. Rather, the diagram data would be part of the Word data file; it would be saved in the same file with the document text.

Figure 10.1  The Object dialog box in Microsoft Word lists the objects that are registered on the system.

Linked and embedded objects also differ in terms of the accessibility of the data object. A linked data object, because it exists in its own independent data file, can be accessed and modified by multiple container applications. For example, an Excel spreadsheet object could be linked to a Visual Basic container application and a Microsoft Word container document at the same time. Either of these container applications (Visual Basic or Word) could access and modify the spreadsheet, and the changes would appear in the linked object in the other container the next time it was used. You could also open and modify the spreadsheet using Excel as a standalone application; these changes, too, would appear in both the Visual Basic and the Word containers.

An embedded object’s accessibility is much more restricted. It is accessible only to the container application in which it is embedded. Other applications cannot access or modify the object’s data.



Previous
Table of Contents
Next






Products |  Cont