?? ch02.htm
字號(hào):
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<TITLE>Chapter 2</TITLE>
<META NAME="Author" Content="Steph Mineart">
<META NAME="GENERATOR" CONTENT="Internet Assistant for Microsoft Word 2.03z">
</HEAD>
<BODY>
<H1><!--last modified on Thu, Apr 10, 1997 4:25 PM--> <!-- This document was created from RTF source by rtftohtml version 3.0.1 -->
<BODY TEXT="#000000" BGCOLOR="#FFFFFF">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>
<HR SIZE="4">
<H1><A NAME="Heading1">What Can ActiveX Do for You?</A></H1>
<UL>
<LI><B>Application requirements<SPACER TYPE="VERTICAL" SIZE="2"></B>
It is important to understand as many of the requirements as possible
before starting your development project. <BR>
<LI><B>Choosing the correct architecture and component type<SPACER TYPE="VERTICAL" SIZE="2"></B>
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. <BR>
<LI><B>Choosing the correct tool<SPACER TYPE="VERTICAL" SIZE="2"></B>
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. <BR>
<LI><B>Basic ActiveX component architecture<SPACER TYPE="VERTICAL" SIZE="2"></B>
Each ActiveX Component type has its particular architecture and
construction. Understanding this architecture is important. <BR>
<LI><B>Basic ActiveX support tools<SPACER TYPE="VERTICAL" SIZE="2"></B>
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">Defining the Needs and Requirements of
Your Application</A></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">What Type of ActiveX Component Do You Need?</A>
</H2>
<P>
The first thing you must decide is what kind of component best
fits your requirements.
<H3><A NAME="Heading4">Automation Servers and Controllers</A>
</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">ActiveX Controls</A></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">COM Objects</A></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 will then require
its own proxy-stub marshaling code.</P>
<P>
Proxy-stub marshaling is what takes place when an application
resides in a process space other than the application it is communicating
with. It is necessary to translate function calls and data to
a context that can be understood by both applications. This is
the responsibility of the proxy-stub code and is true for all
types of OLE components. Going out-of-process with any type of
component will have a profound effect on the performance of the
application because a lot more work is taking place in order to
perform the specific set of operations.</P>
<P>
Automation Servers rely on built-in proxy-stub marshaling code,
whereas COM interfaces are required to create their own. This
problem is not insurmountable, but it does add to the development
time and effort, maintenance of the code, distribution of the
Object, and overall performance of the application, so it needs
to be considered when deciding on what type of component to develop.
If you are going to go out-of-process with the COM Object, you
should probably consider using an Automation Server because the
performance will be comparable between the two, that is unless
you are going to come up with your own marshaling code that significantly
outperforms the built-in mechanisms.</P>
<P>
COM Objects are useful for the cases where the limited set of
data types available to Automation Servers has a significant impact
?? 快捷鍵說明
復(fù)制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號(hào)
Ctrl + =
減小字號(hào)
Ctrl + -