`
`
`
`Now it’s time to change gears a little. In the first half of the book we concentrated on the whys and hows of
`developing reusable software components. We focused primarily on the COM and OLE technologies that pro~
`vide us with the ability to build software components. We now understand what COM, OLE, and ActiveX are
`all about. We investigated using C++, custom COM interfaces, and Automation in the creation of software
`components, and now we’re ready to develop the ultimate software components: ActiveX controls.
`
`In this chapter we’ll investigate what it takes to implement an ActiveX control. We’ll look at the history
`of the OLE and ActiveX control standards and discuss various ways ActiveX controls can be used in con-
`junction with visual development tools, such as Microsoft’s Visual Basic and Visual C++. Once we have a
`broad understanding of the technology used to implement controls, we’ll use the remaining chapters to
`focus on the development of various types of ActiveX controls. This chapter provides an introduction to the
`technology. After this, it will be all coding.
`
` apeend ecu ant Arehéeecture
`The initial goal of OLE was to provide software users with a document—centric environment. OLE defines
`COM—based interfaces that enable applications to embed software objects developed by various vendors.
`This important capability has added significantly to the ease of use of various software products.
`
`Figure 7.1 shows Microsoft Word with a Visio drawing embedded within the Word document. If I want
`to edit the Visio drawing, 1 can do so within Word by double-clicking on the embedded drawing; Visio exe-
`cutes “in—place," and the Word menu changes to a Visio one. This arrangement allows me to use Visio’s
`functionality completely within Word. The benefit of this technology is that the user doesn’t have to switch
`between applications to get work done. The focus is on the creation of the document and not on the assem—
`bling of different application ”pieces” into a complete document, explaining the origin of the term document
`centric. The document, and not the applications needed to combine and produce it, is the user’s focus.
`
`2%
`
`NFLE 1009 - Page 1
`NFLE 1009 - Page 1
`
`

`

`”WMme
`292 e» CHAPTER 7
`
`.MWWWWWMWWWMWWMWWMWW‘M
`
`,0 arm/xzm/g/m/m x/x/tz/zq/qg/wmm mmmzzm-zmm em/mr/aaa/mw'wamxxmzmx/zmlaw/«mam,
`
`
`
`
`
`
`
`.n ‘ I” _ _ i',.I r 5/
`\\\
`
`Properties
`
`Marinade L
`
`L
`
`
`
`
`
`
`\\\\\\\\\\\\5\\\\\\\
`
`\\\\\\\\\\\\\\\\\~:l.\\\\\\\\\\\\\
`
`l
`
`OLE 611mm!
`
`
`
`
`i
`
`‘mMmeewuuwwmwww_
`
`Figure 7.1 Visio drawing embedded in a Word document.
`
`There are some problems with this shift in paradigms. Many users initially get confused when the Word
`menu changes to Visio's or Excel’s. Also, most applications are large and cumbersome and experience signif-
`icant performance problems when users attempt to launch several large applications at once. These prob-
`lems will be overcome as users assimilate the changes and as developers restructure their applications to
`include smaller modules of functionality that operate independently (and as a whole).
`
`ActiveX controls are built using many of the techniques of OLE compound documents. Plenty of mater-
`ial is available that explains OLE as a compound document standard, so I won’t spend much time on it here
`except when it directly pertains to the development of ActiveX controls.
`
`éemeeend Qeeemeee iemaners and Embe eied
`Servere
`
`Compound document containers are those applications that allow the embedding of OLE-compliant com»
`pound document servers. Examples of containers include Microsoft’s Word and Excel, Corel’s WordPerfect,
`and others.
`
`Applications such as Visio are embedded servers that support being activated in-place within a com~
`pound document container application. This technique of being invoked within another application and
`merging its menus is called visual editing. The user doubleuclicks on the server’s site—its screen location
`within the container—and the embedded sewer is launched and becomes activated in-place.
`
`Compound document servers are typically implemented as executables and therefore are large. They
`include the complete functionality of the application that is being embedded within the container applica-
`
`NFLE 1009 - Page 2
`NFLE 1009 - Page 2
`
`

`

`
`
`WWWHMmmwmnmwawwmmammmcmwmm
`
`ActiveX Controls e 23423::
`
`fion. This is one reason that the effective use of compound document technology was initially viewed as
`requiring extensive system resources. But with advances in hardware and the move to 32~bit operating sys—
`tems, this is no longer a serious problem.
`
`Many compound document containers are also compound document servers. You can embed a Word
`document in an Excel spreadsheet as well as embed an Excel spreadsheet within a Word document. (This is
`one reason they are such large applications.) Most ActiveX controls are embedded servers that are designed
`to perform quite differently from compound document servers.
`
`eeriee genereis
`
`ActiveX controls incorporate, or use, much of the technology provided by COM, OLE, and ActiveX—in par~
`ticular, those technologies pioneered in compound documents. Many COM-based interfaces must be imple~
`mented by both the client (or container) and the control to provide this powerful component—based environ—
`ment. Figure 7.2 illustrates the communication between a control and its client.
`
`
`ActiveX Control Container“
`'
`'
`= *
`'
`-
`*
`'
`
`,
`
`'_
`,
`_
`,
`~ Properties
`
`~
`3
`‘ methods '
`
`'
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`ActiveX Control
`
`Persistence
`
`Figure 7.2 Interaction between C: control and its client.
`
`In Chapter 1, we discussed the importance of discrete software components to the future of software devel-
`opment. The underlying technology required to build robust software components is provided by COM and
`the ActiveX control specification. Problems must be overcome, but today ActiveX controls provide the most
`comprehensive solution.
`
`In Chapter 6, we used Automation to encapsulate a nonvisual software component, our Expression
`class. The ActiveX control architecture provides a robust method of building visible software components.
`In addition to the visible aspect, ActiveX controls also provide a way to communicate events externally so
`
`NFLE 1009 - Page 3
`NFLE 1009 - Page 3
`
`

`

`294- % CHAPTER 7
`
`that users of the control can use these events to signal other programmatic actions. A simple example is a
`timer control whose only purpose is to provide a consistent series of events that the control user can tie to
`some other programmatic action
`
`Another important capability of ActiveX controls is their ability to save their state. This quality of per-
`sistence allows a control user to initially define a control's characteristics knowing that they will persist
`between application design, running, and distribution. This capability is not intrinsically supported by the
`Automation servers discussed in Chapter 6.
`
`
`There are three basic ActiveX control types. Graphical controls provide significant functionality by their
`visual representation and manipulation of data. An example might be an image display control. The second
`type is also graphical, but it implements or extends a standard Windows control. Its behavior is based on,
`and uses, the functionality of an existing control provided by Windows. An example is a standard listbox
`that has been enhanced to contain checkboxes. The third type, nonvisual controls, provides all their func-
`tionality without any graphical requirements. Examples of nonvisual controls include a timer control, a
`Win32 API control, and a network services control. Their main purpose is to expose Automation methods,
`properties, and events for a visual developer. Except for the timer control (whose purpose is to provide a
`uniform timer event and would be prohibitively expensive to implement using Automation), most nonvi-
`sual controls can function as Automation servers. However, providing an implementation using ActiveX
`controls makes them easier to use within graphical development environments, provides persistence of
`state, and supports an event mechanism to communicate with the container. We will develop examples of
`all three control types in the remaining chapters.
`
`An additional control type is the Internet-aware control. An Internet-aware control can take the form of
`any of the three control types but has additional environmental requirements. Internet-aware controls must
`be designed to work effectively in low—bandwidth environments and to carefully implement user services.
`We will discuss these requirements in detail in Chapter 12.
`
`6
`
`a as E frigate ia genmts
`stage
`as:
`We’ve come a long way in our quest for a technique to build robust and reusable software components, and
`we’ve finally reached a comprehensive destination. ’In Chapter 6, we saw how effective Automation is at
`providing reusable components by wrapping C++ classes and exposing their functionality. We also found
`three limitations of Automation. First, it provides only limited outgoing notification capabilities.
`Automation components are inherently synchronous and provide only one-way communication in their
`basic configuration. This is one reason that Automation objects are driven by Automation controllers. The
`second limitation involves the lack of a visual aspect to Automation components. Third, Automation, in con-
`trast to controls, lacks a persistence mechanism. Persistence of control properties is an important feature not
`provided through Automation.
`
`NFLE 1009 - Page 4
`NFLE 1009 - Page 4
`
`

`

`
`
`
`A tiveX Controls 4%» 2@5
`
`From now on we will focus exclusively on the design, development, and use of ActiveX controls. They
`provide a sophisticated event mechanism so that they can notify their users of events. Events are fired asyn—
`chronously, notifying the user of an important occurrence within the component and allowing the control
`user to harness the event and perform other actions in a larger component-based application. ActiveX con—
`trols also allow easy implementation of the visual or GUI aspect of a software component. This and other
`features of ActiveX controls provide a rich environment on which to build visually oriented development
`tools. And remember, the COM standard is an open one, and its design is completely documented for all to
`use. This arrangement creates an environment where vendors will develop tools for using this technology.
`The availability of third—party tools can only benefit those who develop software components.
`
`The creation of rich, control—based development environments is important to the ultimate success of
`the component-based development paradigm. One of the problems of component development is the appli—
`cation’s dependency on many different system~level and application—level components. The ultimate success
`of component-based software depends on robust tools that ease the tasks of distribution and management of
`the application and its components. Today, ActiveX controls are supported by nearly all major development
`tools. They have become the de facto software component.
`
`Another important feature of ActiveX controls is that Microsoft has placed them at the center of its new
`Internet-based software focus. ActiveX controls are used throughout Microsoft’s new Web—based technolo—
`gies. Internet Explorer itself is implemented using a robust and feature-laden ActiveX control. ActiVeX con-
`trols can be embedded within HTML-based Web pages to add tremendous application—like functionality to
`static Web-based documents. Thousands of ActiveX controls are available, and the market will only grow as
`the Internet and corporate intranets continue to flourish.
`
`game Termmeéogy
`A lot of terminology is associated with the OLE compound document standard, so I’ll provide you with
`some short definitions to help as we move forward. The terminology for OLE changes often, and some of the
`terms are equivalent. Some of the definitions are cyclical, so you may have to loop through twice.
`
`U|=Active Obect
`
`Embeddable objects are UI-active when they have been activated in-place and are being acted upon by the
`user. The UI-active server merges its menus with that of the containing application (such as Word). Only one
`server can be UI—active within a container at a time.
`
`Active @biect
`
`When embeddable objects are not UI-active, they are active, loaded, or passive. (Local server objects have an
`additional state: running.) Most ActiveX controls prefer to remain in the active state, because it provides the
`control with a true HWND in which to render itself. In the loaded state, an embeddable object typically pro—
`
`NFLE 1009 - Page 5
`NFLE 1009 - Page 5
`
`

`

`29$ 6’ CHAPTER 7
`
`vides a metafile representation of itself for the container to display and lies dormant waiting to be in—place
`activated.
`
`EmbeddIhle @iqeti
`
`An embeddable object supports enoughtof the OLE document interfaces that it can be embedded within an
`OLE container. This doesn’t mean that it supports in—place activation, only that it can render itself within the
`container. The object is said to be “embedded” because it is stored in the container's data stream. For exam-
`ple, in our previous Visio demonstration, the Visio object, which Microsoft Word knows nothing about, is
`actually stored or embedded within Word’s .DOC file, which is a compound document file.
`
`PIssive @bjeti
`A passive object exists only in the persistent storage stream, typically on disk. To be modified, the object
`must be ”loaded” into memory and placed in the running state. A passive object is just a string of bits on a
`storage device. Software is required to load, interpret, and manipulate the object.
`
`Visml Editing Ind n-Plce Activation
`
`These terms describe the capability of an embeddable object to be activated in-place. In~p1ace activation is
`the process of transitioning the object to the active state. In most compound document container applica—
`tions, this process also forces the object into the UI—active state if it is an outside-in object. Once the object is
`activated, the user can interact with the embedded object. When the object is in-place active, the server and
`container can merge their menus.
`
`@uiside=in @bieti
`
`Outside-in objects become active and UI—active at the same time. Outside—in objects are activated and imme-
`diately become UI-active by a double-click of the mouse. Compound document servers are outside-in
`objects. You must doub1e~click the Visio object to invoke Visio when editing within Microsoft Word.
`
`inside=®ut @bieti
`Inside-out objects become UI—active with a single mouse click. They are typically already in the active state
`within the container. ActiveX controls are inside-out objects, although this option can be controlled by the
`control developer. With the creation of the OLE Controls 96 specification, which we will discuss in detail
`shortly, controls are not required to support any in-place activation interfaces.
`
`NFLE 1009 - Page 6
`NFLE 1009 - Page 6
`
`

`

`
`
`WW"
`
`amWW.WWWMMMWMmeWWWWWWWMWWWKWWWWMmWWW”
`ActiveX Controls 9 29?
`
`
`artiste gentrsé streamers
`
`ActiveX controls are discrete software elements that are similar to discrete hardware components and are of
`little use by themselves. You need a control container to actually use an ActiveX control. Control containers
`make it easy to tie together various ActiveX controls into a more complex and useful application. An impor~
`tant feature of an ActiveX control container is the presence of a scripting language that is used to allow pro—
`grammatic interaction with the various controls within the container.
`ActiveX control containers are similar to the compound document containers that we described earlier,
`but the older compound document containers lack a few new interfaces specified for ActiveX controls.
`ActiveX controls can still function within compound document containers (if they’re designed properly), but.
`many of their most discerning features will not be accessible.
`
`Although compound document containers and ActiveX control containers share many internal charac—
`teristics, their ultimate goals differ. As we’ve discussed, compound document containers focus on the
`assembly of documents for viewing and printing and are typically complete applications. ActiveX control
`containers are usually used as ”forms” that contain controls that are tied together with a scripting language
`to create an application. Figure 7.3 shows two Visual Basic forms, each containing some ActiveX controls.
`Contrast this with the Word and Visio example in Figure 7.1.
`
`
`
`Figure 7.3 Two Visual Basic forms, each with some ActiveX controls.
`
`gontafigs
`
`
`
`In typical visual development environments, the container operates in various modes. When the developer is
`designing a form (control container) or Web page, the control should behave differently than when it is actu~
`ally being executed. To use Visual Basic as an example, when a Visual Basic developer needs a listbox con-
`trol, the developer clicks the listbox icon on the tool palette, drags a representation of the listbox control, and
`
`NFLE 1009 - Page 7
`NFLE 1009 - Page 7
`
`

`

`293 fEHAPTER7 ,
`
`drops it on a form. The listbox representation is merely a rectangle with a name in the top left corner. During
`design time, there is no need to create a window just to provide a representation of the control. When the
`Visual Basic form and its associated code are executed by a user of the application, the listbox control win-
`dow is actually created and therefore needs to behave like a listbox and perform any special functions
`through its exposed properties, methods, and events. These two modes are referred to as the design-phase
`and run—time modes.
`
`Visual Basic also allows a developer to single—step through the application. At each break-point, you
`can examine variables, check the call stack, and so on. When Visual Basic is in this mode—debug mode—the
`listbox control is frozen and doesn’t act on any window events.
`
`I used Visual Basic for this example, but there are a large number of other control containers, including
`Visual C++, Borland’s Delphi, Microsoft’s Internet Explorer, and so on. The ActiveX control standard pro-
`vides two ambient properties that can be implemented by the container to indicate its various modes.
`Ambient properties are container states that can be queried by the contained controls. If the ambient prop—
`erty Us erMode is TRUE, it indicates that the container is in a mode in which the application user can interact
`with a control. This mode would normally equate to a run-time mode in the Visual Basic example. If
`Us erMode is FALSE, the container is in a design-type mode. The UIDead property indicates, when TRUE,
`that the control should not respond to any user input. This is similar to the debug mode of Visual Basic.
`
`Throughout the rest of the chapters, I’ll use the terms design phase, run—time mode, and debug mode to
`distinguish the differences in a container’s states.
`
`isssrsé as assasisss Esessgsees
`
`Although we haven’t directly covered OLE comporuid document servers in this book, we understand how
`the technology works. Compound document servers can be implemented as local servers, in—process
`servers, or both. ActiveX controls are almost always implemented as in~process servers. Most of the compo—
`nents that we’ve developed so far have been in—process servers, so we’re comfortable with them.
`
`The primary difference between the Expression in—process server of Chapter 5 and an ActiveX con—
`trol is that the Expression object is missing a few ActiveX control—based interfaces. Many of these inter-
`faces are required for a control to be classified as a compound document server and concern themselves
`with the control's visual aspect and its ability to be embedded and in—place activated in an OLE compormd
`document container.
`
`The act of building a component or a container amounts to a process of implementing and exposing a
`series of COM—based interfaces. A control implements a series of interfaces that a container expects and vice
`versa. Figure 7.4 shows the large number of interfaces that a control typically implements. I say ”typically,”
`because the requirements for implementing an ActiveX control have recently been loosened significantly.
`The basic concept of an ActiveX control has changed from its being a hybrid compotmd document server to
`being a small and nimble COM-based component. The newer control specifications reduce to one the num—
`ber of interfaces a control must implement. We'll discuss these new standards shortly.
`
`NFLE 1009 - Page 8
`NFLE 1009 - Page 8
`
`

`

`1“AWWNWWMMMVMasawmwmtmv“MWNWMWMWWWWWMWWMa.WNWMWWMV,MMWM”cw-"M”,MMmama.“,s»..~MM,MyWMMWW/,WNW/Mawmwwmm.“MAMWMWW,MMWMW/rw M
`ActiveX Controls % 29?
`
`
`
`
` . Gauge Como!
`Biirlafic hi!
`
`
`; Ionneclbccwflonlahel
`/
`
`
`? lDataniecl
`
`
`I
`. 3C ..
`crsmqwmwsaemm . 3~04022a00sc021
`g :DW‘C"
`
`
`
`Control:
`Mama-sandman; mmoaamzrc) 250d Comet
`9 Igiicmha
`
`
`.
`r
`ac CNE
`MECSIatu: = Cl
`‘
`InptocSelverZZnE:\WIHHT\Sy;tem32\EFt|D32UD<
`g BEIGE”: r Obi
`
`
`1.131473
`? Imelnnmoaea
`-~? (DEDbiccl
`
`
`'1 Hogan = MSGvid Enid
`? tF’evF'IopeMflvowzing
`
`
`Tooktoxffivlmfi = E:\WINNT\Sy:tem32'\GR|DSZ,UD<. 1
`: ? (Penis?
`
`
`
`
`Typciib x $883872DBSA-1 UiB-EZZEDOAADQSFBZFE}
`rVetzion x10
`? lFersithemoty
`
`
`MSGcid Grid 1: Grid Control
`‘? lPetsizlPropellyBag
`
`
`~ ? IPelaizlSlolege
`ELSIU = U-‘xSC3872IJ-DBSA-1mB-DZZE-UUAADDWBZ‘FC}
`? lPetcizlSlleemlnh
`
`
`
`
`TypeLib =iE1AEBEA3~3503401E-AEEE-UJDZZWIJSCUZ}
`? thvideELaszlrdo
`$3838723DBSA-1 UiB‘BZZEEflGADflSYBZFCi
`
`
`- ? tPtm-idefllaxlrloZ
`i 1.0 = Microsoft GM Comet
`- U
`, »? ISpecuwmpenyPage:
`
`
`
`
`9 IUI‘JLnown
`' win32 1: C:\W1NNT\Sy3tEm32'\GHIU32IJD<
`
`
`FLAGS = 2
`‘ 9 Niewflbiecl
`
`
`HELPDIR = E:\V84
`? IVrewCIbgcQ
`
`ideCtlUbiecl
`
`
`
`
`.
`
`
`
`‘35
`
`‘
`
`
`
`
`
`Figure 7.4 Control-implemented interfaces.
`
`4?
`sassy
`Assists gentrsés ass ' isstasess:
`
`ActiveX controls—called OLE controls at the time—were introduced as an OLE-based technology in early
`1994 as a replacement for the aging Visual Basic custom control (VBX). However, the technology was new,
`and very few development tools supported the use of OLE controls. Visual Basic 4.0, the version that pro—
`vided support for OLE controls, would not be delivered until late 1995. Microsoft Access version 2.0 pro—
`vided minimal support, as did Microsoft FoxPro version 3.0. You could develop ActiveX controls starting
`with the late 1994 release of Visual C++ version 2.0. However, even though you could develop controls, you
`could not use them within Visual C++. This capability had to wait for the late 1995 release of Visual C++ 4.0.
`
`
`
`The initial version of the OLE control specification, now called the OLE Controls 94 spec, required an
`ActiveX control to implement a large number of COM-based interfaces. Most of these interfaces were part of
`the compound document specification, because ActiveX controls were really in—process compound docu—
`ment servers with a couple of new interfaces (such as IOleControl). During this period, OLE control con—
`tainers were just compound document containers that implemented a few additional, control—specific inter—
`faces (such as IOleControlSite).
`
`In early 1996, after more than a year’s experience with implementing and using OLE controls, Microsoft
`modified the specification significantly and called it the OLE controls 96 specification. The new specification
`addresses a number of performance issues inherent with controls implemented using the 1994 specification.
`The new specification also adds significant new features and capabilities for controls and containers.
`
`NFLE 1009 - Page 9
`NFLE 1009 - Page 9
`
`

`

`gee a CHAPTER 7
`
`The Olin? Ceatrais M §peritiretien
`
`The original OLE control architecture was specified as an extension to the existing compound document
`specification. An OLE control had to implement all the interfaces required by a compound document
`embedded server with in—place activation capabilities (such as IOleObj ect and IOleInPlaceObj ec t). In
`addition to these original interfaces, OLE controls had to implement all the control-specific interfaces (such
`as IDispatch and IOleControl). In all, a control that meets the OLE controls 94 specification and pro-
`vides support for all control features would implement more than 15 interfaces. These interfaces are listed in
`Table 7.1 along With a short description of their purpose.
`
`Control-Si e lnte ace
`
`Purpese MFG Met a s
`
`Table 7.1 OLE Controls 94 lnterfaces
`
`IOleObj ect
`
`IOleInPlaceObj ect
`
`IOleInPlaceActiveObj ect
`
`IOleControl
`
`IDataObj ect
`
`Ivi ewObj ect2
`
`IPersistStream,
`IPersistStreamInit,
`IPersistStorage
`
`IProvideClassInfo
`
`Provides the essence of the OLE compound document architecture. Through this inter-
`face, the container and server communicate to negotiate the size of the embedded
`obiect (the control, in our case) as well as get the MiscStatus bits for the control.
`Many of its methods are not needed in an ActiveX control.
`
`A control must implement IOleInPlaceObj ect to support the ability to be acti-
`vated and deactivated in-place within the container. The interface also provides a
`method to notify the control when its size changes or it is moved within the container.
`
`A control must implement IOleInPlaceActiveObj ect to provide support for the
`use, and translation of, accelerator l<eys within the control. Many of
`IOleInPlaceActiveObj ect’s methods are not required for ActiveX controls.
`
`A new interface added to support ActiveX controls. It provides methods to enhance the
`interaction with the control's container. IOleControl primarily adds functionality so
`that the control and container can work together when handling keyboard input.
`
`A control implements this interface to provide graphical renderings to the container.
`
`lmplemented by controls that provide a visual aspect. Iviewobj ect2 provides the
`container with methods to tell the control to render itself within the container’s client
`area.
`
`The persist interfaces are implemented by the control so that they may persist their
`values within the container's structured storage. A control’s properties can persist
`between instantiations.
`
`Implemented by an ActiveX control to allow a client application (usually a container) to
`efficiently obtain the type information for the control. It contains only one method,
`GetClassInfo, which returns an interface pointer that provides access to the con-
`trol's binary representation of its type library.
`
`NFLE 1009 - Page 10
`NFLE 1009 - Page 10
`
`

`

`,wwwwMWmWWWWWMWWWWWW
`
`ActiveX Controls ¢ 39?
`
`Controlfiiae lntefiuce
`
`Purposefifitc Methods
`
`Table 7.1 OLE Controls 94 interfaces (continued)
`
`ISpeCifyPrOpertyPages
`
`Provides a way for the container to query the control for its list of property pages.
`ISpecifyPropertyPages has only one method: GetPages. The GetPages
`method is called by the container. The container provides a pointer to a CAUUID struc-
`ture that returns a counted array of CLSIDs. This enumerates all the property page
`CLSIDs used by the control. The container uses these CLSIDs with a COM Function, typ-
`ically CoCreateInstance, to instantiate the page objects.
`
`IPerPropertyBrowsing
`
`Provides a way For the control to Furnish additional information about its properties.
`
`IPropertyPage2
`
`implemented by each property page component, it provides the container with meth-
`ods to get the size, move, create, destroy, activate, and deactivate the component's
`property page window;
`
`IConnectionPointContainer
`
`Used to provide the container with an outgoing IDispatch interface. This enables
`the control to communicate events to the container.
`
`IConnectionPoint
`
`A control can support several event sets. For each one, the control must provide an
`implementation of the IConnectionPoint interface.
`IDispatch A control’s properties and methods are provided through its IDispatch interface.
`
`
`
`As you can imagine, implementing a control without the help of MFC would be an arduous task at best.
`Implementation of a control container is even more difficult. It also requires a large number of interfaces,
`and a container must manage multiple controls within it.
`
`Shortly after the release of the OLE Controls 94 specification, Microsoft released a document that
`described how a container and its controls should interact with each other. Much of this coordination was
`
`already specified via the compound document specification, but there was still a need for a document that
`would help developers understand the complex relationship between a control and its container. The result—
`ing document, OLE Controls and Container Guidelines Version 1.1, was released in late 1995.
`
`The guidelines put forth the minimum requirements of a control or control container. They describe the
`interfaces that are mandatory and those that are optional. It basically provides a set of guidelines for control
`and container developers. The large number of interfaces, methods, and techniques and the inherent limita-
`tions of human language made it difficult to get all containers and controls to work together. This was to be
`expected with a new and complex technology. However, the guidelines gave developers a good set of rules
`to follow when developing a control or container.
`
`DEE Seatrais es gperii'utiaa
`
`Although OLE controls were a wonderful new technology that validated the concept of component-based
`development, they weren’t perfect. The large number of interfaces and methods that a control had to imple-
`ment, coupled with the requirement that most controls display a window when running, made them some-
`What ”heavy.” Building an application with a large number of OLE controls could be problematic; there
`
`NFLE 1009 - Page 11
`NFLE 1009 - Page 11
`
`

`

`332 a» CHAPTER 7
`
`
`
`were also some functionality holes that needed to be filled. To address these issues, Microsoft released, in
`early 1996, the OLE Controls 96 specification.
`
`The full text of the specification is part of the ActiveX SDK and is available from Microsoft. Following
`are some of the new features.
`
`a Mouse interaction for inactive objects. The previous control specification stated that most controls
`should stay in the active state by setting the OLEMISC_ACTIVATEWHENVISIBLE flag. This arrange-
`ment required the container to load and activate a control whenever it was visible. Activating a con-
`trol required the creation of a window to handle any user interaction (such as mouse clicks and drag-
`and—drop) with the control. The new specification adds a new interface, IPointerInactive, that
`allows a control to interact with the user while in the inactive state. The presence of this capability is
`communicated to the container with the OLEMISC_IGNOREACTIVATEWHENVISIBLE flag.
`
`- Drawing optimizations. The old control specification required a control to reselect the old font,
`brush, and pen into the container—supplied device context whenever it was finished processing the
`IOleview: :Draw call. The new specification adds a parameter to the Draw method that indicates
`whether the control must reset the state of the device context. It is up to the container to support this
`new feature, but the control can determine whether it is supported by checking the vaspect para-
`meter for the DVASPECTINFOFLAG__CANOPTIMIZE flag. If this flag is set, the control does not have
`to take the steps required to restore the state of the container—supplied device context after drawing
`its representation.
`
`0 Flicker-free activation and deactivation. When a control is activated in-place by a container, the
`control does not know whether its display bits are in a valid state. A new interface,
`IOleInPlaceSiteEx, communicates to the control whether or not a redraw is necessary. The new
`interface adds three methods to IOleInPlaceSite.
`
`0 Flicker-free drawing. Another new interface has been added to the OLE Controls 96 specification to
`support flicker—free drawing, nonrectangular objects, and transparent objects. As we’ll see in Chapter
`9, flicker-free drawing can be achieved by using an off-screen device context, but it consumes addi-
`tional resources. The new Iviewobj ectEx interface adds methods and parameters to make flicker-
`free drawing easier to implement at the control. Nonrectangular and transparent controls were sup-
`ported in the previous control specification, but they required a great deal of drawing work on the
`part of the control developer. The new specification provides additional drawing aspects (such as
`DVASPECT_TRANSPARENT) that make implementation of nonrectangular and transparent controls
`easier and more efficient.
`
`0 Windowless controls. The previous specification required in-place active objects to maintain a win~
`dow when active. This requirement was necessary, as we mentioned earlier, to support user interac~
`tion wi