📄 ch02.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<!--last modified on Thu, Apr 10, 1997 4:25 PM-->
<HTML>
<HEAD>
<!-- This document was created from RTF source by rtftohtml version 3.0.1 -->
<META NAME="GENERATOR" Content="Symantec Visual Page 1.0">
<META NAME="Author" Content="Steph Mineart">
<title>ActiveX Programming with Visual C++ -- Chapter 2</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF">
<H1>Chapter 2<BR>
What Can ActiveX Do for You?</H1>
<UL>
<LI><A HREF="#Heading1">What Can ActiveX Do for You?</A>
<UL>
<LI><A HREF="#Heading2">Defining the Needs and Requirements of Your Application</A>
<LI><A HREF="#Heading3">What Type of ActiveX Component Do You Need?</A>
<UL>
<LI><A HREF="#Heading4">Automation Servers and Controllers</A>
<LI><A HREF="#Heading5">ActiveX Controls</A>
<LI><A HREF="#Heading6">COM Objects</A>
</UL>
<LI><A HREF="#Heading7">Selecting the Right Tool for the Right Job</A>
<UL>
<LI><A HREF="#Heading8">Microsoft Foundation Classes</A>
<LI><A HREF="#Heading9">ActiveX Template Library</A>
<LI><A HREF="#Heading10">BaseControl Framework</A>
<LI><A HREF="#Heading11">Create Your Own Framework</A>
</UL>
<LI><A HREF="#Heading12">Basic ActiveX Component Architecture</A>
<UL>
<LI><A HREF="#Heading13">ActiveX Automation Servers</A>
<LI><A HREF="#Heading14">ActiveX Controls</A>
</UL>
<LI><A HREF="#Heading15">Support Tools Needed for Building ActiveX Components</A>
<UL>
<LI><A HREF="#Heading16">MIDL Compiler</A>
<LI><A HREF="#Heading17">Mktyplib</A>
<LI><A HREF="#Heading18">GUIDGEN</A>
<LI><A HREF="#Heading19">RegEdit</A>
<LI><A HREF="#Heading20">Registration Server</A>
<LI><A HREF="#Heading21">Ole2View</A>
<LI><A HREF="#Heading22">Adding the Tools to the Visual C++ Development Environment</A>
</UL>
<LI><A HREF="#Heading23">From Here...</A>
</UL>
</UL>
<P>
<HR SIZE="4">
<H1><A NAME="Heading1"></A>What Can ActiveX Do for You?</H1>
<P>
<UL>
<LI><B>Application requirements</B>
<SPACER TYPE="VERTICAL" SIZE="2">
It is important to understand as many of the requirements as possible before starting
your development project.
<P>
<LI><B>Choosing the correct architecture and component type</B>
<SPACER TYPE="VERTICAL" SIZE="2">
The various ways in which ActiveX components can be created are crucial to a successful
project. You don't want to do too much or too little.
<P>
<LI><B>Choosing the correct tool</B>
<SPACER TYPE="VERTICAL" SIZE="2">
The tool used to develop your component also affects the success of the project.
Picking the right tool for the job is as important as is understanding the job itself.
<P>
<LI><B>Basic ActiveX component architecture</B>
<SPACER TYPE="VERTICAL" SIZE="2">
Each ActiveX Component type has its particular architecture and construction. Understanding
this architecture is important.
<P>
<LI><B>Basic ActiveX support tools</B>
<SPACER TYPE="VERTICAL" SIZE="2">
You will find a collection of development support to tools that are invaluable to
your ActiveX development.
</UL>
<P>Gone are the days of hacking together simple stand-alone applications that had
all the interoperability of two semi-trailer trucks screaming toward each other at
100 miles an hour. With the advent of OLE (Object Linking and Embedding) and more
recently ActiveX and the Internet, applications are expected to be flexible, modifiable,
and extendible (with "clairvoyant" running a close fourth).</P>
<P>Spending a little time up front working out the design and architecture of your
application can and will make all the difference in the world. Almost any application
worth its salt has resulted from some forethought, regardless of whether that information
is crammed into the head of one of your developers, scribbled on restaurant napkins,
or written in formal documentation. I recommend the latter two since removing your
developer's head to take to a strategy meeting is probably not an option.</P>
<P>The basic principles of OLE and ActiveX are going to determine most of the specific
component architecture and design. For example, ActiveX Controls and Documents are
developed within a specific set of parameters and rules so that they will interact
with Containers correctly. Automation Servers and Controllers have to conform to
OLE Automation rules. And COM Objects have to support the basic fundamentals of COM.
But what about component relationships and lifetimes? What about access to interfaces
and support for security? What if your component is going to be utilized by users
who speak another language?
<H2><A NAME="Heading2"></A>Defining the Needs and Requirements of Your Application</H2>
<P>A specification is important to establish the basic requirements of the component
you are asked to create. Before you can proceed, you must have a clear understanding
of what kind of component or application is needed and why you are creating it. Appropriate
questions to ask are, "What created the need for the component, and how is it
going to be used?" If the person or persons can't describe the problem, they
probably don't understand the problem. The last thing anyone needs is an incomplete
picture of the problem, which tends to create delays and promote last minute changes
that can cause unexpected results. Try to get as much of the specification as possible
on paper.</P>
<P>After you determine the need, you can move on to designing the component. Again,
it is critical to get as much information as possible. Does the problem require a
single component or multiple components? Do the components need the capability to
interact together? And, if so, is speed an issue? What about the skill level of your
developers? How are they able to cope with change or possibly new and unfamiliar
development methods? What are the support and maintenance requirements?</P>
<P>What is the problem? And what is going to be the solution? Take for example the
need for creating in-house purchase requests. Is it simple enough to say, "We
will create an ActiveX Document and use our Web browsers to interact with the Document"?
Probably not. What about e-mail integration? What about training for how to use the
Web browser and the purchase request application? What if the purchase request application
must integrate with a legacy application in-house? What if the development tool that
you normally use can't create ActiveX Documents? What if there aren't any developers
on staff who can handle the effort? Most of these issues can be boiled down to a
single question, "What is the level of effort versus the amount of gain?"
That is, is it worthwhile to pursue a development project that is difficult to understand,
implement, and maintain? Or is it worthwhile to use a simpler approach and live with
its limitations?</P>
<P>All these issues and more will affect the kind of component you create and how
you will develop it. As a developer of ActiveX components, it is your responsibility
to know the answers to these questions. You have the specific domain knowledge, that
is, the capabilities and limitations of yourself and the tools that you use. This
book will hopefully aid you in making the correct choices when choosing and implementing
a development plan.
<H2><A NAME="Heading3"></A>What Type of ActiveX Component Do You Need?</H2>
<P>The first thing you must decide is what kind of component best fits your requirements.
<H3><A NAME="Heading4"></A>Automation Servers and Controllers</H3>
<P>Automation Servers and Controllers probably have the greatest amount of flexibility.
The Servers' <TT>IDispatch</TT> interface can be used from just about every major
application available from Microsoft and hundreds of other manufacturers. Because
it won't suffer from the same versioning requirements placed on strict COM interfaces,
the interface also lends itself well to prototyping and modeling component interactions.</P>
<P>A dual-interface Automation Server created in-process is the fastest type of Automation
Server. Dual-interface refers to the fact that a Server contains two interfaces one
based on <TT>IDispatch</TT> and the other based on COM. The COM interface is actually
the fastest of the two. An in- process Server means that the application resides
in the same memory address space as the application that created it. This allows
the invocation of methods defined within the Server to be performed significantly
faster because there is no burden of having to cross process boundaries every time
a method is called. For the same reason, Server load times are fast because of the
minimal number of steps involved in creating the Server and getting its <TT>IDispatch</TT>
or COM interface pointer.</P>
<P>Nothing inherent to Automation architecture promotes the use of User Interface
(UI), and nothing prevents its use either. You have complete freedom and control
over how the Servers are implemented and used. Your Automation Servers could potentially
contain UI in the form of a dialog or a form.</P>
<P>Automation Servers also lend themselves well to the increasingly popular multitiered
applications architectures that have appeared in recent years. The separation of
UI from function is perfect for Automation Servers because you have complete freedom
over how your Servers are implemented and used. Creating Servers with thin UI layers
that utilize other Servers with no UI to accomplish a task is at the heart of multitiered
applications development. Automation Servers should be used in the same fashion as
any other DLL. The only difference between an Automation Server and a standard Windows
DLL is the fact that the Server uses only a restricted set of data types whereas
a DLL can use any type.</P>
<P>Designing Automation Servers that work without the need for UI also makes them
prime candidates for Distributed COM (DCOM) and other distributing technologies.
<H3><A NAME="Heading5"></A>ActiveX Controls</H3>
<P>You should use ActiveX Controls primarily as they were intended to be used: as
UI components to enhance or support a dialog, form, or document. Controls can be
expensive to load because they can potentially require a large number of interfaces,
depending on the functionality the Control supports. The OC 96 specification added
the QuickActivate interface to help with Control load times, but the improvement
was not significant. In addition, the OC 96 specification identified a number of
interfaces that are considered optional or conditional, depending on the type of
Control you are implementing. It is wise to review the specification to determine
what can and cannot be removed from your implementation in order to improve its performance
and overall size.</P>
<P>When creating Controls, be sure to make them as lean as possible. If the Control
will not be commercially distributed, remove the "AboutBox" code. Also,
see whether you can get away with relying on the property editor of the application's
development tool that will be used rather than supporting property pages. Avoid large
amounts of persistence, and save the data only if you must. The real message here
is to implement only those features that are truly useful and helpful for your Control
implementation.
<H3><A NAME="Heading6"></A>COM Objects</H3>
<P>COM Objects (Custom Interfaces) are far more flexible than any other component
type when it comes to interface design. They are also the fastest interfaces in terms
of execution times, although that is with the caveat that the COM interface is in-process
to the application using it. COM Objects can use any data type within their interface
definitions and do not suffer from the same restrictions as Automation Servers. This
situation does present a problem when crossing process boundaries because the Object
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -