`
`
`
` zitROLESIEaEE SL UES REESE A EEE EEE ET TTEIR EOten
`
`
`
`Nowit’s time to change gearsa little. In the first half of the book we concentrated on the whys and howsof
`developing reusable software components. We focused primarily on the COM and OLEtechnologies that pro-
`vide us withthe 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 developmenttools, such as Microsoft's Visual Basic and Visual C++. Once we have a
`broad understanding of the technology used to implementcontrols, we'll use the remaining chapters to
`focus on the developmentof various types of ActiveX controls. This chapter provides an introduction to the
`technology. After this, it will be all coding.
`
` JLE’s Compound Document Architecture
`Theinitial 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 addedsignificantly 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, I 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
`betweenapplications 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 notthe applications needed to combine and produceit, is the user’s focus.
`
`291
`
`NFLE 1009 - Page 1
`NFLE1009 - Page 1
`
`

`

`2Q2_+ CHAPTER 7
`eenen
`
`snneneeretarerininniennaetttbetrttattbentemteenremcanatnittastninnaentnse
`
`ii
`ugh?
`RCLLICLLEUULLEALUTEAL GELLECISAULALUTELACLLERSCCLCAMILLEMOALILLELEELACELINEOLALIAETTLEALECLLILLALLAMEECRCULE
`LI
`Se
`gg5
`g4
`bsZ
`gZg
`¢ggggZ
`g%e
`g5gZ
`3Z
`gzgg%gg
`g%.
`
`_
`
`[ehenticontaner
`
`Properties.
`
`Methods
`
`gg4
`
`
`
`
`
`lJ
`
`OLE Gontro!
`
`
`
`
`sennaeenean]
`
`Figure 7.1 Visio drawing embedded in a Word document.
`
`There are some problems with this shift in paradigms. Many usersinitially get confused when the Word
`menu changesto 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 modulesof 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 documentstandard, so J won’t spend muchtimeonit here
`except whenit directly pertains to the development of ActiveX controls.
`
`Compound Document Containers and Embedded
`Servers
`
`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 menusis called visual editing. The user double-clicks on the server’s site—its screen location
`within the container—and the embeddedserveris launched and becomesactivated in-place.
`Compound documentservers 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
`NFLE1009 - Page 2
`
`

`

`
`
`Sree
`
`ActiveX Controls 293
`
`tion. This is one reason that the effective use of compound documenttechnology wasinitially viewed as
`requiring extensive system resources. But with advances in hardware and the moveto 32-bit operating sys-
`tems, this is no longer a serious problem.
`Many compound documentcontainers are also compound documentservers. 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 embeddedservers that are designed
`to perform quite differently from compound documentservers.
`
`ActiveX Controls
`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 andits client.
`
`ActiveX ControlContainer Ce
`ee “Properties
`=
`
`
`
`=~ Methods©
`
`
`
`
`
`
`ActiveX Control
`
`
`
`
`
`Persistence
`
`Figure 7.2 Interaction between a controlandits 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
`NFLE1009 - Page 3
`
`

`

`294 ~ CHAPTER 7
`
`that users of the control can use these events to signal other programmatic actions. A simple exampleis a
`timer control whose only purpose is to provide a consistent series of events that the control user can tie to
`some other programmaticaction.
`Another important capability of ActiveX controls is their ability to save their state. This quality of per-
`sistence allows a control userto 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.
`
`
`
`ctiveX Contr
`Types
`
`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 Windowscontrol. 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, providesall 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 workeffectively in low-bandwidth environments and to carefully implementuser services.
`Wewill discuss these requirementsin detail in Chapter12.
`
`o c
`
`Controls as Software Components
`tiveX
`We've come a long wayin ourquest for a technique to build robust and reusable software components, and
`we've finally reached a comprehensive destination. In Chapter 6, we saw howeffective 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
`secondlimitation 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
`NFLE1009 - Page 4
`
`

`

`
`
`
`ActiveX Controls ~ 295
`
`From now on wewill focus exclusively on the design, development, anduse 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 otheractions 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, andits design is completely documentedforall to
`use. This arrangement creates an environment where vendors will develop tools for using this technology.
`Theavailability of third-party tools can only benefit those who develop software components.
`Thecreation of rich, control-based development environments is important to the ultimate success of
`the component-based development paradigm. One of the problems of component developmentis the appli-
`cation’s dependency on many different system-level and application-level components. The ultimate success
`of component-based software depends on robusttools that ease the tasks of distribution and managementof
`the application and its components. Today, ActiveX controls are supported by nearly all major development
`tools. They have becomethe 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 Exploreritself is implemented using a robust and feature-laden ActiveX control. ActiveX con-
`trols can be embedded within HTML-based Web pages to add tremendousapplication-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.
`
`Some Terminology
`A lot of terminology is associated with the OLE compound documentstandard, so I'll provide you with
`someshort definitions to help as we move forward. The terminology for OLE changes often, and someof the
`terms are equivalent. Some ofthe definitions are cyclical, so you may have to loop throughtwice.
`
`Ul-Active Object
`Embeddable objects are Ul-active when they have been activated in-place and are being acted upon by the
`user. The Ul-active server merges its menus with that of the containing application (such as Word). Only one
`server can be Ul-active within a containerat a time.
`
`Active Object
`When embeddable objects are not Ul-active, they are active, loaded, or passive. (Local server objects have an
`additionalstate: running.) Most ActiveX controls prefer to remain in the active state, because it provides the
`control with a true HWND in which to renderitself. In the loaded state, an embeddable object typically pro-
`
`NFLE 1009 - Page 5
`NFLE1009 - Page 5
`
`

`

`296 + CHAPTER 7
`
`vides a metafile representation of itself for the container to display and lies dormant waiting to be in-place
`activated.
`
`Embeddable Object
`An embeddable object supports enough.of the OLE documentinterfaces that it can be embedded within an
`OLEcontainer. This doesn’t mean that it supports in-place activation, only that it can renderitself within the
`container. The object is said to be “embedded”becauseit 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 .DOCfile, which is a compound documentfile.
`
`Passive Object
`A passive object exists only in the persistent storage stream, typically on disk. To be modified, the object
`must be “loaded” into memory andplaced in the running state. A passive object is just a string of bits ona
`storage device. Software is required to load, interpret, and manipulate the object.
`
`
`
`Visual Editing and in-Place Activation
`These terms describe the capability of an embeddable object to be activated in-place. In-place 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 ULactivestate 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.
`
`Outside-in Object
`Outside-in objects becomeactive and Ul-active at the same time. Outside-in objects are activated and imme-
`diately become Ul-active by a double-click of the mouse. Compound documentservers are outside-in
`objects. You must double-click the Visio object to invoke Visio when editing within Microsoft Word.
`
`Inside-Out Object
`Inside-out objects become Ul-active with a single mouseclick. 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
`NFLE1009 - Page 6
`
`

`

`
`
`ActiveX Controls @ 297
`teteratNNURSECERteNeNANITONCTORCLETETBLSIETASEtatttetsteatanitainincCanaiat
`penvanencrcncaisivocnc
`
`
`ActiveX Control Containers
`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 presenceofa scripting languagethat is used to allow pro-
`grammatic interaction withthe various controls within the container.
`ActiveX control containers are similar to the compound documentcontainers that we describedearlier,
`but the older compound documentcontainers lack a few newinterfaces specified for ActiveX controls.
`ActiveX controls can still function within compound documentcontainers(if they're designed properly), but.
`manyof their most discerning features will not be accessible.
`Although compound documentcontainers 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 examplein Figure 7.1.
`
`Figure 7.3 Two Visual Basic forms, each with some ActiveX controls.
`
`Container
`
`
`
`In typical visual development environments, the container operates in various modes. When the developeris
`designing a form (control container) or Web page, the control should behave differently than whenit is actu-
`ally being executed. To use Visual Basic as an example, when a Visual Basic developer needsa listbox con-
`trol, the developerclicksthe listbox icon on thetool palette, drags a representation of the listbox control, and
`
`NFLE 1009 - Page 7
`NFLE1009 - Page 7
`
`

`

`298 & CHAPTER7 _
`
`drops it on a form. Thelistbox representation is merely a rectangle with a namein thetop left corner. During
`design time, there is no need to create a window just to provide a representation of the contro]. When the
`Visual Basic form andits associated code are executed by a user of the application, the listbox control win-
`dow is actually created and therefore needs to behavelike a listbox and perform any special functions
`through its exposed properties, methods, and events. These two modesare referred to as the design-phase
`and rius-time modes.
`
`Visual Basic also allows a developer to single-step through the application. At each break-point, you
`can examinevariables, check the call stack, and so on. When VisualBasic 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 numberof 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.
`Ambientproperties are containerstates that can be queried by the contained controls. If the ambient prop-
`erty UserModeis TRUE,it indicates that the containeris in a mode in whichthe application user can interact
`with a control. This mode would normally equate to a run-time mode in the Visual Basic example.If
`UserMode 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 modeof Visual Basic.
`Throughouttherest of the chapters,I’ll use the terms design phase, run-time mode, and debug modeto
`distinguish the differences in a container’s states.
`
`Control and Container Interfaces
`
`Although we haven't directly covered OLE compound documentservers 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 andits ability to be embedded andin-place activated in an OLE compound
`documentcontainer.
`
`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 implementsaseries of interfaces that a container expects and vice
`versa. Figure 7.4 showsthe large numberofinterfaces 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 compound documentserverto
`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 standardsshortly.
`
`NFLE 1009 - Page 8
`NFLE 1009 - Page 8
`
`

`

`evvcsrsinonnroucsepntnsnnanentnabenstimstnaitestituteeitesietiitiittrittitseNHbCt
`
`ActiveX Controls + 299
`
`
`
`
`
`
`
`
`
`
`
`~%
`
`:
`
`Y (DataObject
`§ Ioeech
`lleCache
`4 Innne
`§ (kCocol
`lDkeInFlaceActiveDbject
`P 1lelnPlaceDbiect
`~~ Y% 1DteObject
`Y 1PeiPropestyBrowsing
`—D iPersist
`© iPetsistMemary
`= ® jPersistPropertyBag
`~% iPersistStorage
`? iPersitSteamtnt
`2 IProvideClazetnfo
`<~% tProvideClazelnfo2
`iG [SpeciyPropertyPages
`? Wrknown
`2 ® MewObject
`Y MewObject2
`ideCl Object
`
`
`CLSID = (00954144-3861-1010-92F3-040224009C02)
`
`:
`
`{A8C39720-0954-101B-822E-G0440037B2FC} = Grid Contial
`Control =
`
`
`
`InprocServer2 = CAWINNT\System32\GRID32Z.0C%
`
`
`HiceStatus = 0
`i
`1 = 131473
`
`
`
`
`1 ProglD = MSGrid Grid
`
`
`TookboxBitmap32 = C:AWINNTSystemn324GRID32,00%, 1
`
`
`TypeLlis = (46B28723-0854-101B-B22E0044003782FC}
`Version = 1.0
`
`
`MSGurid.Grid = Grid Control
`
`
`CLSID = (A8C28720-0854-101B8-B22E-004A003782FC}
`
`
`
`
`
`
`TypeLib = {E1S68843-3803-101C-AC6E-040224009C02}
`{88838723-0854-1018-B22E-00440037B2FC}
`
`
`21.0 = Microsoft Grid Control
`
`
`~O
`
`
`&
`yain32 = CAWINNTASpstem32\GRID32.00%
`FLAGS =2
`
`HELPDIR = C:\VB4
`
`
`
`Figure 7.4 Control-implemented interfaces.
`
`S
`ActiveX Controls and Containers:
`
`story
`
`ActiveX controls—called OLE controls at the time—were introduced as an OLE-basedtechnologyin early
`1994 as a replacementfor 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 implementa large number of COM-basedinterfaces. Most of these interfaces were part of
`the compound documentspecification, because ActiveX controls were really in-process compound docu-
`mentservers with a couple of new interfaces (such as I0leContro1). During this period, OLE control con-
`tainers were just compound documentcontainers that implemented a few additional, control-specific inter-
`faces (such as LOleControlSite).
`
`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 numberof performanceissues 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
`
`

`

`300 + CHAPTER 7
`The OLE Controls 94 Specification
`
`The original OLE control architecture was specified as an extension to the existing compound document
`specification. An OLE control had to implementall the interfaces required by a compound document
`embedded server with in-place activation capabilities (such as IOleObject and IOleInPlaceoObject). In
`addition to these original interfaces, OLE controls had to implementall the control-specific interfaces (such
`as IDispatch and IO0leContro1). In all, a control that meets the OLE controls 94 specification and pro-
`vides supportfor 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.
`
`Conirol-Side Interface
`
`IOleObject
`
`IOleInPlaceObject
`
`IOleInPlaceActiveObject
`
`IoleControl
`
`IDataObject
`IViewObject2
`
`IPersistStream,
`IPersistStreamInit,
`IPersistStorage
`
`IProvideClassInfo
`
`Table 7.1 OLE Controls 94 Interfaces
`Purpose/MFC Methods
`
`Providesthe essence of the OLE compound documentarchitecture. Through this inter-
`face, the container and server communicate to negotiate the size of the embedded
`object(the control, in our case} as well as get the MiscStatusbits for the control.
`Manyofits methods are not needed in an ActiveX control.
`A control must implement 10leInPlaceObject 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 whenits size changesorit is moved within the container.
`A control must implement [0leInPlaceActiveObject to provide support for the
`use, and translation of, accelerator keys within the control. Many of
`IOleInPlaceActiveObject’s methods are not required for ActiveX controls.
`Anewinterface added to support ActiveX controls. It provides methods to enhance the
`interaction with the control’s container. I0leContro1 primarily adds functionality so
`that the control and container can work together when handling keyboard input.
`A control implementsthis interface to provide graphical renderings to the container.
`implemented by controls that provide a visual aspect. IviewObject2 provides the
`container with methodstotell the controlto renderitself within the container’s client
`area,
`
`Thepersist interfaces are implemented by the controlso that they may persist their
`values within the container’s structured storage. A control’s properties can persist
`betweeninstantiations.
`
`Implemented by an ActiveX controlto allow a client application (usually a container) to
`efficiently obtain the type information for the control. It contains only one method,
`GetClassInfo,which returns aninterface pointer that provides access to the con-
`trol’s binary representation ofits type library.
`
`NFLE 1009 - Page 10
`NFLE1009 - Page 10
`
`

`

`ActiveX Controls + 301
`cnnnHNACACETATESOTEENTNCROOMNSPAAESTATETE
`
`Gontrol-Side Interface
`
`IspecifyPropertyPages
`
`IPerPropertyBrowsing
`IpropertyPage2
`
`IconnectionPointContainer
`
`Table 7.1 OLE Controls 94 Interfaces (continued)
`Purpose/MFC Methods
`
`Provides a wayforthe container to query the controlforits list of property pages.
`ISpecifyPropertyPages has only one method: GetPages. The Get Pages
`methodis called by the container. The container provides a pointer fo a CAUUIDstruc-
`ture that returns a counted array of CLSIDs. This enumeratesall the property page
`CLSIDsused by the control. The container uses these CLSIDs with a COM function,typ-
`ically cocreateInstance,to instantiate the page objects.
`Provides a wayforthe controlto furnish additional information aboutits properties.
`Implemented by each property page component, it provides the container with meth-
`odsto get the size, move, create, destroy, activate, and deactivate the component's
`property page windows.
`Used to provide the container with an outgoing IDispatchinterface. 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 IconnectionPointinterface.
`IDispatch A control's properties and methods are provided through its IDispatchinterface.
`
`
`
`As you can imagine, implementing a control without the help of MFC would be an arduoustask at best.
`Implementation of a control container is even more difficult. It also requires a large numberofinterfaces,
`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 howa container and its controls should interact with each other. Muchof this coordination was
`already specified via the compound documentspecification, but there wasstill a need for a documentthat
`would help developers understand the complex relationship between a controland its container. The result-
`ing document, OLE Controls and Container Guidelines Version 1.1, was releasedin 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 numberof interfaces, methods, and techniques and the inherentlimita-
`tions of human language madeit 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 goodset of rules
`to follow when developing a control or container.
`
`OLE Controls 96 Specification
`Although OLE controls were a wonderful new technology that validated the concept of component-based
`development, they weren't perfect. The large numberof interfaces and methodsthat 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
`NFLE1009 - Page 11
`
`

`

`302 + CHAPTER 7
`
`
`
`were also some functionality holes that needed to befilled. To address these issues, Microsoft released, in
`early 1996, the OLE Controls 96 specification.
`Thefull text of the specification is part of the ActiveX SDK andis available from Microsoft. Following
`are someof the new features.
`
`° Mouseinteraction for inactive objects. The previous control specification stated that most controls
`should stay in the active state by setting the OLEMISC_ACTIVATEWHENVISIBLEflag. 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 userinteraction (such as mouseclicks and drag-
`and-drop) with the control. The new specification adds a new interface, [PointerInactive,that
`allowsa control to interact with the user while in the inactive state. The presence of this capability is
`communicated to the container with the OLEMISC_TGNOREACTIVATEWHENVISIBLEflag.
`° Drawing optimizations. The old control specification required a contro] 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 mustreset 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 pvAspect 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.
`° 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.
`
`° 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 IViewObjectEx interface adds methods and parameters to makeflicker-
`free drawing easier to implementat 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 moreefficient.
`
`°¢ Windowless controls. The previous specification required in-place active objects to maintain a win-
`dow whenactive. This requirement was necessary, as we mentionedearlier, to support user interac-
`tion within the control. This issue has now been addressed with the [PointerInactiveinterface.
`Controls that require a window also make nonrectangular and transparent regions difficult to im