What is an OCX?

Written by Embarcadero USA on Posted in PROGRAMMING

 Technical Information Database

TI2475C.txt   What is an OCX?
Category   :General
Platform    :All
Product    :Borland C++  5.0

Description:
What is an OCX?
What are OLE Custom Control's, OLE Automation, OCX and ActiveX?
They are all names for Microsoft's (MS) component technology.
Basically, they are OLE Custom Controls, which are OLE Automation
servers also known as OCX's, and now that MS is moving to Internet
tools they are known as ActiveX.  This document will explain what
OCX's are how the tools necessary to build them work. A 
familiarity with OLE will be needed for the both documents.
                   -- What is a Component --
For those who are not familiar with the term components or
component based development, it is the future of programming.
Components are objects you can embed in your program to add
functionality. They save you time from having to write the code
yourself. Common types of components are mini-spreadsheets, 
graphic tools, word processors, specialized edit fields, and 
all sorts of fancy buttons and controls for windows.
Components are "Black-Boxes" and as a component user you only
need to know the interface to the component.  You don't need to
know anything about how the component was written.  As long as
the interface does not change, a component can be maintained and
updated without your code ever having to change.  Most components
are visual, however, there are non-visual components that provide
communications tools, database connectivity, and other services.
Application developers combine components with their code to
build powerful applications quickly.  Component writers are the
other side of the coin.  Components programmers developer
components for companies that provide business model, data
validation, access to specialized hardware, and other services.
By using components, maintenance\updates can be easily made and
distributed to the whole application development team.  There is
also a lucrative business writing commercially available
components.  Now components have found a new application in 
Internet applets.  Soon you will either be a user or developer of
components, maybe both.  If want more details on components, books
on OLE, Object-Oriented Design, COM (Component Object Model) and
Rapid Application Development system (i.e. Borland Delphi) will
discuss their place in development.
                   -- Microsoft Components --
A form of components have been part of Windows all along as
DLLs.  But it was Visual Basic Controls (VBX) that made
developers think in terms of component based development.  VBX's
were far more popular than anyone expected, but they had one
major problem, their architecture is married to the 16-bit world.
MS started pushing everyone to Win32, but developers wanted take
their VBX's with them.  MS, instead of hacking VBX's to work
with Win32, decided to come up with true 32-bit components that
would be platform independent.  In 1994 OLE 2 and OLE Custom
Controls appeared.  Programmer's hung the name OCX on OLE Custom
Controls for 32-bit VBX's.  MS is moving all their products to
OLE and OCX is part of that paradigm.
Now that the Internet, Intranets, and Java are catching on, MS
wants to make sure their components are a part of it.  So, this
week (March 1996) MS renamed OCX to ActiveX.  ActiveX components
along with active scripts, active document, and ability to
use ActiveX with Java are all part of MS's Internet strategy.
Besides tightly integrating into the new active technologies
and Java, ActiveX reduces components in size by as much as 300%.
MS has already stated the ActiveX componented will be a major
parts of the next release of Windows.  Knowledge of OLE and
ActiveX is important for developers in the future.
                  -- Basic OCX Architecture --
Here is basic view of how the OCX works:
Application                       Control Container .EXE
                                        Client  Site
                                         |  |  |  |
                                         o  o  o  o
Control                                  ^  ^  ^  ^
                                         |  |  |  |
                                        OCX  Control
                                              ^
                                              |
                                              V
Control Developer Kit                Control Runtime DLL
                                              ^
                                              |
                                              v
OLE 2.01                                   OLE DLL
OCX communication is based on Common Object Model (COM)
interfaces.  A COM interface is represented in the diagrams by a
line with a circle on the end.  COM interfaces are actually
arrays of function pointers; you communicate with an object by
calling a function within an interface.  To use an interface, you
get a pointer to a COM interface, offset from that pointer to
index into the function you want, and then execute the function.
As you see, the container?s client site exposes interfaces to the
control, the control exposes interfaces to the container?s client
site, the control exposes interfaces directly to the container,
and the container exposes interfaces outside the client site.
The run-time DLL performs several services for the control it
implements. It includes support for the stock properties, stock
events, and stock methods, the stock property pages, and the
property page frame.
Stock Support in the Control Run-time DLL
Stock Properties    Stock Events    Stock Methods
----------------    ------------    -------------
BackColor           Click           AboutBox
BorderStyle         DblClick        DoClick
Caption             Error           Refresh
Enabled             KeyDown
Font                KeyPress        Stock Property Pages
ForeColor           KeyUp           --------------------
hWnd                MouseDown       Colors
Text                MouseMove       Pictures
                    MouseUp
The property page is a dialog resource for the user to
graphically view and edit properties.  The code for the dialog
is contained in the control.  Property pages are used at design
time, but they are sometimes displayed to users at run time.
The property page frame handles the display of the control?s
property pages, which includes an implementation of tabbed
dialogs to switch between various pages. The OCX architecture is
built on standard OLE interfaces, so controls do not require the
CDK run-time DLL.
                      -- Under the Hood --
MS OLE is built on COM the binary standard between components and
DLLs.  An OCX is an OLE object with an extended interface that
lets it behave like a windows control.  In OLE 2 terms, an OCX is a
compound document object designed as an in-process server that
supports OLE automation and visual editing.  More simply put, it
is a standard OLE 2 object that can be embedded within a
container, activated in-place, and can utilize OLE automation.
An COM enhancement, that is important for OCX, is Self-Registering
Servers.  Self-Registering Servers are able to create their own
registry entries and do not rely on a separate .REG file.  This
allows even the registry information to be contained in the
object, and the object can dynamically update the path entries
based on where the .DLL (or .EXE) is located.  Since the registry
is critical to OLE, self-registration removes the external
dependency of a .REG file, without which, an object would be
useless.
In the OCX design, there are five required mechanisms, each with
their own of interfaces and protocols, that controls use in order
to fulfill their responsibilities. These five mechanisms are:
 - Control Properties: The mechanism the container uses to
   retrieve\modify properties and call methods. The control must
   expose properties names and parameters for its methods. This
   includes the visual interface that allows end users to
   control properties.
 - Events: The mechanism that the control notifies the
   control container of events that occur.
 - Visual Interface: The mechanism the control will use to draw
   itself but give the container the ability to manage the
   control's size and position.
 - Keyboard Mnemonics: A mechanism through which the control
   processes the keyboard mnemonics and accelerators. These
   include ALT key combinations and arrow keys. Additionally,
   buttons and labels have special handling requirements as far
   as accelerators are concerned.
 - Persistence: A mechanism so the container can ask the
   control to save its state information.
These are the basic mechanisms that the control requires. However,
the document that will contain the control has requirements too. 
Namely, the container properties that define the controls 
environment. This allows the container to specify default colors, 
fonts, alignment, and other behavioral aspects.  It is up to the 
control to retrieve these properties at runtime.  The container 
must also supply entry points for the objects events.  The 
container must provide points for a controls entire set of entry
points.  The control can not be restricted in what events it can 
trigger.
The container is an executable program (EXE) with one or more
client sites. When you want to insert a new control in the
container, the container creates a new client site to receive it.
Each client site can handle all communication between the
container and a OCX embedded within the container. A  control is
essentially a DLL with an OCX extension.
Besides handling properties and events, the container is also
responsible for providing the facilities for the object layout,
ordering, and keyboard processing. This is because only the
container is aware of all the objects in a form and the
relationships between them.  It must also facilitate saving the
document to a file for later reloading.
Collectively all of these requirements make up another list of
necessary mechanisms.
 - Layout: A mechanism to create, place, size, and order
   controls.
 - Form Persistence: Methods to save and retrieve the state of
   the controls and mapping of their events to the container's
   actions.
 - Environment Properties: A mechanism to expose ambient
   properties to all controls.
 - Event Handlers: Functions to provide and expose event entry
   points to each specific control.
 - Extended Controls: The ability for the container to wrap
   controls into an "extended control" that layers
   container-controled properties and methods on top of other
   controls.  This allows the container to treat all controls in
   a like manner through those properties and methods.
-        Container Keyboard: A mechanism to inform controls of
   accelerator and other keyboard events, as well as handling
   special-purpose buttons and labels.
Below are OLE Container and Control Interfaces:
General OLE Interfaces
Container (EXE)           Control (DLL)
---------------           -------------
IOleClientSite            IOleObject
IOleInPlaceFrame          IOleInPlaceObject
IAdviseSink               IOleInPlaceActiveObject
                          IDataObject
                          IViewObject
                          IPersistStorage
Specific Control Interfaces
---------------------------
IControlSite              IDispatch (Prop/Meth)
[ISimpleFrameSite]        IPersistStreamInit
IDispatch (Ambient)       IControl
IDispatch (Extender)      IConnectionPointContainer
IDispatch (Event)         ISpecifyPropertyPages
IBoundObjectSite
IPropertyNotifySink
Descriptions of OLE 2 Interface Controls:
Container Interfaces
---------------------
IControlSite - Used by the control to communicate with its client
site. Specifically, it supports mnemonic keys, focus changes, and
coordinate transformations.
ISimpleFrameSite (optional) - Used by a simple frame control to
allow its container to hook window messages during the execution
of the control's window procedure.
IDispatch (Ambient) - Used by the control to access the
container's ambient properties.
IDispatch (Extender) - Implemented by the container to "extend"
the set of properties that a control appears to have.
Specifically it adds the container?s extender properties to the
list of properties exposed by the control.
IDispatch (Event) - The interface that a control calls to fire
its events.
IBoundObjectSite - Used by the control to send data binding
notifications and additional information to the container about
the state of a bound property. The additional information might,
for instance, be that the user started to edit the value, but
then canceled.
IPropertyNotifySink - Used by the control to report changes in
its property values.
Control Interfaces
------------------
IDispatch (Properties/Methods) - The control interface that
exposes the control?s properties and methods to OLE automation
clients.
IPersistStreamInit - An extended version of the IPersistStream
interface. If a container uses this interface, it is obligated to
call IPersistStreamInit::InitNew if it does not call
IPersistStreamInit::Load, IPersistStorage::Load, or
IPersistStorage:: InitNew.
IControl - Used by the container to communicate with the control
regarding mnemonic keys, changes in ambient properties, and
freezing/unfreezing of events.
IConnectionPointContainer - Provides access to the control's
connection points. A control typically has two connection points:
one for its events, and one for its property notifications.
ISpecifyPropertyPages - Enumerates the class IDs of the property
pages that can be used to view and change the control's
properties.
                 -- Tools for Building OCX's --
You should have a good idea of how a OCX operates and the
requirements for both the control and container.  There are few
tools for building OCX's.
The first method is to manually write all the OLE code yourself
using the OLE libraries. Anyone who has written OLE code
knows this is a monumental task.  For example, a small OCX
project written by hand contains about 600k of sources files.
So if your a true hacker, this is the method for you.
The next method is to use Borland OCF tools to generate the
basic OLE code for you. Then, you can modify the OCF code to
build a OCX.  A TI that outlines this process is in the works
and should be available soon.
Microsoft has a tool, called the Control Developers Kit (CDK),
that will generate the base code for a OCX.  Every book and
article on writing OCX's I found, in preparing this document, used
the CDK to generate the base code.  This previously was a
problem because the CDK generate MFC OLE code.  Now that Borland
C++ v5.0 contains a option to compile MFC code, you too can use
the CDK*. If you plan to use the CDK, there are many books and
that cover OLE and custom controls.
Components are part of all developer's future, either in using or
writing them.  Now, you can decide which you want to be.
References:
Inside OLE by Kraig Brockschmidt, MS-Press
OLE Controls by Adam Denning, MS-Press
Programming Windows 95 Unleashed by Lawerance Harris et all, Sam
Publishing
Teach Yourself OLE in 21 Days by Lawerance Harris, Sams
Publishing
Microsoft Developers Network CD-ROM has many articles on OLE and
OLE Controls including many reprints from Microsoft Systems
Journal.  A highly recommended source of information for all
Windows programming topics.


Reference:


7/2/98 10:40:55 AM
 


Article originally contributed by Borland Staff

Tags: C++Builder



Check out more tips and tricks in this development video: