`
`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 teclmologies that pro(cid:173)
`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(cid:173)
`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.
`
`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, I can do so within Word by double-clicking on the embedded drawing; Visio exe(cid:173)
`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 t11e assem(cid:173)
`bling of different application "pieces" into a complete document, explaining the origin of the term document(cid:173)
`centric. The document, and not the applications needed to combine and produce it, is the user's focus.
`
`291
`
`APPLE 1109 - Page 1
`
`
`
`292 + CHAPTER 7
`
`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(cid:173)
`icant performance problems when users attempt to launch several large applications at once. These prob(cid:173)
`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(cid:173)
`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.
`
`Compound document containers are those applications that allow the embedding of OLE-compliant com(cid:173)
`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(cid:173)
`pound document container application. This technique of being invoked within another application and
`merging its menus is called visual editing. The user double-dicks on the server's site-its screen location
`within the container-and the embedded server 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-
`
`APPLE 1109 - Page 2
`
`
`
`ActiveX Controls + 293
`
`tion. This is one reason that the effective use of compound document teclmology was initially viewed as
`requiring extensive system resources. But with advances in hardware and the move to 32-bit operating sys(cid:173)
`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.
`
`ActiveX controls incorporate, or use, much of the teclmology provided by COM, OLE, and ActiveX-in par(cid:173)
`ticular, those technologies pioneered in compound documents. Many COM-based interfaces must be imple(cid:173)
`mented by both the client (or container) and the control to provide this powerful component-based environ(cid:173)
`ment. Figure 7.2 illustrates the communication between a control and its client.
`
`ActiveX Control Container
`
`Properties
`
`Methods
`
`Events
`
`ActiveX Control
`
`Figure 7.2 Interaction between a control and its client.
`
`In Chapter 1, we discussed the importance of discrete software components to the future of software devel(cid:173)
`opment. The underlying teclmology 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
`
`APPLE 1109 - Page 3
`
`
`
`+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(cid:173)
`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.
`
`Is
`
`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(cid:173)
`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(cid:173)
`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 enviromnents and to carefully implement user services.
`We will discuss these requirements in detail in Chapter 12.
`
`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(cid:173)
`trast to controls, lacks a persistence mechanism. Persistence of control properties is an important feature not
`provided through Automation.
`
`APPLE 1109 - Page 4
`
`
`
`ActiveX Controls + 295
`
`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(cid:173)
`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(cid:173)
`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(cid:173)
`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 tedmolo(cid:173)
`gies. Internet Explorer itself is implemented using a robust and feature-laden ActiveX control. ActiveX con(cid:173)
`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.
`
`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.
`
`Ul-Adive Obied
`Embeddable objects are DI-active when they have been activated in-place and are being acted upon by the
`user. The DI-active server merges its menus with that of the containing application (such as Word). Only one
`server can be DI-active within a container at a time.
`
`Active Obied
`When embeddable objects are not DI-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-
`
`APPLE 1109 - Page 5
`
`
`
`+CHAPTER 7
`
`vides a metafile representation of itself for the container to display and lies dormant waiting to be in-place
`activated.
`
`Embeddable Obied
`An embeddable object supports enough of 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(cid:173)
`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.
`
`Passive Obied
`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.
`
`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(cid:173)
`tions, this process also forces the object into the VI-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.
`
`Outside-In Obied
`Outside-in objects become active and VI-active at the same time. Outside-in objects are activated and imme(cid:173)
`diately become VI-active by a double-click of the mouse. Compound document servers are outside-in
`objects. You must double-click the Visio object to invoke Visio when editing within Microsoft Word.
`
`lnside=Out Object
`Inside-out objects become VI-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.
`
`APPLE 1109 - Page 6
`
`
`
`ActiveX Controls + 297
`
`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(cid:173)
`tant feature of an ActiveX control container is the presence of a scripting language that is used to allow pro(cid:173)
`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 fw1ction 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(cid:173)
`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.
`
`In typical visual development environments, the container operates in various modes. When the developer is
`designing a form (conh·ol container) or Web page, the control should behave differently than when it is actu(cid:173)
`ally being executed. To use Visual Basic as an example, when a Visual Basic developer needs a listbox con(cid:173)
`trol, the developer clicks the listbox icon on the tool palette, drags a representation of the listbox control, and
`
`APPLE 1109 - Page 7
`
`
`
`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(cid:173)
`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 nm-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(cid:173)
`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(cid:173)
`erty UserMode 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
`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 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.
`
`Although we haven't directly covered OLE compound 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(cid:173)
`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(cid:173)
`trol is that the Expression object is missing a few ActiveX control-based interfaces. Many of these inter(cid:173)
`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 compound
`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 compound document server to
`being a small and nimble COM-based component. The newer control specifications reduce to one the num(cid:173)
`ber of interfaces a control must implement. We'll discuss these new standards shortly.
`
`APPLE 1109 - Page 8
`
`
`
`ActiveX Controls +
`
`L+.1 < Ga~Conltol
`:7 ~·ri~!e~1ry%~ConlaW.er
`'f IDo!aObjecl
`?
`?
`9 IOleCache
`? IO!tConl1ol
`? JOle!nPlaceActiveObject
`? JOlelnPloceObject
`?
`'( IP"P''°"''''~'°w:,rng
`?
`?
`'( 1p.,,;;,tP10P'<l)'Etag
`? !Per:i;\Stornge
`? !PettittStreamlni\
`? !P1ovideCkmtnfo
`l' !P1ovideCla~drJo2
`'i' !Spec~yPropertyPage;
`? !Unknown
`?
`?
`
`W.n32"' C:\W1MNT\System32\GRlD32.0CX
`FLAGS" 2
`HELPD!R "'C:\VB4
`
`Figure 7.4 Control-implemented interfaces.
`
`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(cid:173)
`vided support for OLE controls, would not be delivered until late 1995. Microsoft Access version 2.0 pro(cid:173)
`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 conh·ol to implement a large number of COM-based interfaces. Most of these interfaces were part of
`the compow1d document specification, because ActiveX controls were really in-process compound docu(cid:173)
`ment servers with a couple of new interfaces (such as IOleControl). During this period, OLE control con(cid:173)
`tainers were just compound document containers that implemented a few additional, control-specific inter(cid:173)
`faces (such as IOleControlSi te).
`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 conh·ols 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.
`
`APPLE 1109 - 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 implement all the interfaces required by a compound document
`embedded server with in-place activation capabilities (such as IOleObj ect and IOleinPlaceObj ect). 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(cid:173)
`vides support for all control feahires would implement more than 15 interfaces. These interfaces are listed in
`Table 7.1 along with a short description of their purpose.
`
`Control-Side Interface
`
`IOleObject
`
`IOleinPlaceObject
`
`IOleinPlaceActiveObject
`
`IOleControl
`
`IDataObject
`
`IViewObject2
`
`IPersistStream,
`IPersistStreaminit,
`IPersistStorage
`
`IProvideClassinfo
`
`Table 7.1 OLE Controls 94 Interfaces
`Purpose/ MFC Methods
`
`Provides the essence of the OLE compound document architecture. Through this inter(cid:173)
`face, the container and server communicate to negotiate the size of the embedded
`object (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(cid:173)
`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 IOleinPlaceActi veObj ect lo provide support for the
`use, and translation of, accelerator keys within the control. Many of
`IOleinPlaceActiveObject'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.
`
`Implemented by controls that provide a visual aspect. IViewObject2 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(cid:173)
`trol's binary representation of its type library.
`
`APPLE 1109 - Page 10
`
`
`
`Control-Side Interface
`
`rspecifyPropertyPages
`
`ActiveX Controls + 301
`
`Table 7.1 OLE Controls 94 Interfaces {continued)
`Purpose/ MFC Methods
`
`Provides a way for the container to query the control for its list of property pages.
`ISpeci fyPropertyPages has only one method: GetPages. The GetPages
`method is called by the container. The container provides a pointer to a CAUUID struc(cid:173)
`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(cid:173)
`ically CoCreateinstance, to instantiate the page objects.
`
`rPerPropertyBrowsing
`
`Provides a way for the control to furnish additional information about its properties.
`
`IPropertyPage2
`
`rconnectionPointContainer
`
`IConnectionPoint
`
`Implemented by each property page component, it provides the container with meth(cid:173)
`ods to get the size, move, create, destroy, activate, and deactivate the component's
`property page windows.
`
`Used to provide the container with an outgoing IDispatch interface. This enables
`the control to communicate events to the container.
`
`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(cid:173)
`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(cid:173)
`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.
`
`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 number of interfaces and methods that a control had to imple(cid:173)
`ment, coupled with the requirement that most controls display a window when running, made them some(cid:173)
`what "heavy." Building an application with a large number of OLE controls could be problematic; there
`
`APPLE 1109 - Page 11
`
`
`
`302 + 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.
`
`" 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(cid:173)
`ment required the container to load and activate a control whenever it was visible. Activating a con(cid:173)
`trol required the creation of a window to handle any user interaction (such as mouse clicks and drag(cid:173)
`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 pvAspect para(cid:173)
`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,
`IOleinPlaceSi teEx, communicates to the control whether or not a redraw is necessary. The new
`interface adds three methods to IOleinPlaceSi te.
`• 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(cid:173)
`tional resources. The new IViewObj ectEx interface adds methods and parameters to make flicker(cid:173)
`free drawing easier to implement at the control. Nonrectangular and transparent controls were sup(cid:173)
`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.
`" Windowless controls. The previous specification required in-place active objects to maintain a win(cid:173)
`dow when active. This requirement was necessary, as we mentioned earlier, to support user interac(cid:173)
`tion within the control. This issue has now been addressed with the IPointerinacti ve interface.
`Controls that require a window also make nonrectangular and transparent regions difficult to imple(cid:173)
`ment. Windowless controls draw their representation directly on a device context provided by the
`container. There is no need for a true HWND. To support this capability, though, several issues must
`
`APPLE 1109 - Page 12
`
`
`
`ActiveX Controls -+ 303
`
`be handled. User interaction beyond mouse clicks and drag-and-drop, such as keystrokes, must be
`handled by the container and passed
`to
`the control. Another new interface,
`IOleinPlaceSi teWindowless, which is derived from IOleinPlaceActi veObj ect, supports
`these new requirements. It provides methods to handle focus, mouse capture, and painting of a con(cid:173)
`trol without a window.
`• In-place drawing for windowless controls. A windowless control draws directly on a device con(cid:173)
`text provided by the container. Several methods in IOleinPlaceSi teWindowless enab