Introduction

This course is about how to build an ActiveX control using Delphi 3. In addition to presenting a tutorial on how to use Delphi 3''''s wizards to convert an existing VCL control into an ActiveX control, the course introduces areas where the control designer may want to extend the basic code, and provides in-depth explanation of Delphi''''s DAX class hierarchy.

Who should take this class?

The course is a programming tutorial. Students are expected to be familiar with the Delphi component model, and have an introductory knowledge of Microsoft COM. While they are not expected to be familiar with Delphi''''s interface syntax and class hierarchies, the course will not cover these in detail even though they are foundation material. Students are not required to be familiar with the ActiveX Control specifications and interfaces, and will be insulated from most of these details. Instead, the course will focus on Delphi''''s ActiveX Control class hierarchy and the wizards used to generate new ActiveX control components.

What is ActiveX™?

ActiveX is the brand name for Microsoft''''s component object model. Components are objects (in the conventional sense) with some special capabilities that allow them to be easily combined into an application. Regardless of the model used to implement them, components have properties, methods, events, and can load and save their properties to/from a definition file.

Traditional objects exist only at compile time (where they are really just symbol table entries in the mind of the compiler) and at runtime (where they''''re fully active and interacting with the user), but components also support design-time operation. A control in design mode usually is like one at runtime except it has restricted behavior and its primary methods and events aren''''t active. Some design-time controls have augmented capabilities not available at runtime, such as showing property-editor dialogs. Controls that are invisible at runtime are visible at design-time, so the user can interact with the control.

Components make programming easier than traditional OO languages because they allow the programmer to replace code statements with specifications. Instead of entering code to create an object and choosing the right constructor to initialize the object, you simply drag and drop the object onto its container (a form or other logical container, like a data module) and set its creation properties using a property editor. This not only makes the programming easier, it also makes learning how to use a new object much easier.

The ActiveX component object model provides all these basic facilities and varies only slightly from the Delphi object model''''s capabilities. For example, Delphi has no property pages but does have property editors.

The primary technical difference stems from how the components are written. Delphi''''s component model assumes language support from the Object Pascal compiler (or C++Builder) as well as using helper code from the Delphi runtime library. As a result, while programming is easy the binary details are less formalized. This is an intentional choice on the part of Delphi''''s designers-it''''s the compilers responsibility to create the appropriate connecting code and runtime type information (RTTI) for objects.

The ActiveX component model is designed to be language-independent and highly version-resilient in object form. The developer (perhaps with the help of wizards; perhaps a wizard himself) was expected to write all the code to satisfy the component model''''s requirements. As a result, the COM specification provides much less meat, but is more highly formalized-Microsoft has published three or four big volumes documenting the specification and updated the spec several times.

Types of ActiveX Controls

ActiveX defines several component patterns, each of which has characteristics that make it appealing for specific situations. Which type you''''re interested in building depends on the capabilities the control will be expected to have, and how you intend to use the component.

ActiveX Control

An ActiveX Control most closely resembles the TWinControl descendants found in Delphi. The control is intended to be inserted into a form-like container, it has a window, can be automated via properties and methods, it can fire events to its container, save its state to storage provided by its container and restore a saved stated. ActiveX Controls often provide a set of property pages that allow the user to edit the saved state, and supports property inspectors via a property-browsing interface.

Non-visual ActiveX Control

A non-visual control is not visible to the user at runtime. This component is most closely related to Delphi''''s TComponent, which is the base class of all the non-visual controls like TQuery. The control does not create a window at runtime, but it usually does at design-time so the user can manipulate it with a mouse.

Data-bound ActiveX Control.

This control is also like a standard ActiveX control, except that it receives some data from a data source. The data source is usually a field in a database, but it really could be from any source. Usually, a specific property (often named "Text" or "Value") is bound to the current value of the data source.

Design-time controls

A new feature of ActiveX Controls, this pattern allows the design-time behavior of a control to be separated from the runtime code. The two are built into separate libraries, and the runtime code is usually much smaller than the design-time code. This shrinks the size of the runtime module, which can be very beneficial when the code needs to be downloaded over the Internet. For commercial vendors, it also guarantees that the end-user can''''t use the control''''s design environment without purchasing it.

Internet data controls

These controls, which are in other ways normal ActiveX Controls, are designed to download data from a remote Internet site. An example of this might be a picture control with a property called Source that is an URL string. Internet data controls can download data asynchronously and update their display as the data arrives. The picture viewer control starts up empty and displays the picture in blocks as data blocks arrive over the Net.

Downloadable controls

These controls can be downloaded from an Internet site and installed locally. They contain a signature that identifies the control''''s author. They also implement behavior that determines whether the control can be trusted to not do something undesirable if it receives untrusted data or is scripted inside a Web page that contains untrusted scripts.

ActiveForms

An Active Form is really just an ActiveX-ified representation of a Delphi TForm. It''''s primarily intended as a delivery vehicle for an entire application function within an Intranet, and can be used to integrate Delphi applications seamlessly with a corporate Web. ActiveForms can make use of the Delphi VCL to bring up dialogs, and can connect to remote data or business object servers.

ActiveDocument

An Active Document is really a pair of objects based on the document-view design pattern, and is the most direct descendant of the original OLE specification. ActiveDocs contain code to read a document out of a file and to display and/or edit the data in a window.

Non-windowed controls

These are extremely lightweight ActiveX controls that don''''t create a window handle even though they do have a visual representation. These correspond to the VCL''''s TGraphicControl class in Delphi.

Why Should I Build an ActiveX control?

Delphi directly supports building ActiveX Controls, ActiveForms, and downloadable controls using wizards, the DAX class framework and its documentation. But since Delphi already comes with its own complete object model, why would you want to create ActiveX components? If you pay heed to Microsoft''''s messaging, there really are two reasons why you should be interested in building ActiveX components: Visual Basic and Internet Explorer.

I you prefer to focus on technical reasons to build an ActiveX component, the language independence is the main thing. Components built for ActiveX can be used in a wide variety of programming environments on Windows, not just Delphi or C++Builder. This means you can build business objects that can be reused across your organization by people using PowerBuilder, VB or other tools.

ActiveX Limitations

Although the ActiveX model offers significant advantages, there are still ways in which it can be better to stick with Delphi''''s native VCL model:

No containership hierarchy

An ActiveX component has no standardized means of locating one of its peers. Components speak only to their container, and there exists no standard allowing an object to inquire about another object. This doesn''''t mean that controls cannot communicate with other objects, only that the object''''s container must a specialized broker for this process. For example, ActiveX data-bound controls are given their data by their containers, unlike in Delphi where the control asks its container to locate a component with the same name as the DataSource property.

No property inspectors

ActiveX relies heavily on property pages for editing properties, rather than Delphi''''s notion of property inspectors. The main difference is that property pages can edit multiple properties, wh

[1] [2] [3] [4] [5] [6] [7] [8]  下一页