📄 ch37.htm
字号:
<html>
<head>
<title>Chapter 37 -- Integration Summary</title>
<meta NAME="GENERATOR" CONTENT="Microsoft FrontPage 3.0">
</head>
<body TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#CE2910">
<!-- Spidersoft WebZIP Ad Banner Insert -->
<!-- End of Spidersoft WebZIP Ad Banner Insert-->
<h1><font COLOR="#FF0000">Chapter 37</font></h1>
<h1><b><font SIZE="5" COLOR="#FF0000">Integration Summary</font></b> </h1>
<hr WIDTH="100%">
<h3 ALIGN="CENTER"><font SIZE="+2" COLOR="#000000">CONTENTS<a NAME="CONTENTS"></a> </font></h3>
<ul>
<li><a HREF="#DesignIssues">Design Issues</a> </li>
<li><a HREF="#TheFaxBackApplication">The FaxBack Application</a> </li>
<li><a HREF="#TheVoicePhoneApplication">The Voice Phone Application</a> </li>
<li><a HREF="#TheTalkMailProject">The Talk Mail Project</a> </li>
<li><a HREF="#SomeFinalRemarks">Some Final Remarks</a> </li>
</ul>
<hr>
<p>In this last part of the book, you've had the chance to build three sample applications
that combine two or more of the Windows Extension services covered in this book. You also
reviewed some of the common design issues that you'll face when building applications that
require access to multiple extension services. The sections below briefly summarize the
material covered in the last four chapters. </p>
<h2><a NAME="DesignIssues"><b><font SIZE="5" COLOR="#FF0000">Design Issues</font></b></a></h2>
<p>In <a HREF="ch33.htm">Chapter 33</a>, "Design Considerations for Integrated
Communications Applications," you learned some of the advantages and disadvantages of
deploying software that uses the MAPI, SAPI, and TAPI extension services for Windows
operating systems. The following general points were discussed:
<ul>
<li><font COLOR="#000000">First, remember the Rule of Complexity. Where possible, try to
limit the number and depth of service extensions used in a single application. With added
services comes added complexity-both for the user and the programmer.</font> </li>
<li><font COLOR="#000000">Consider the pros and cons of using native API calls versus
employing high-level third-party add-on tools to provide access to extension services. The
native API calls may be faster, but they will also require more coding and maintenance for
you and your staff. Building applications with third-party tools can be more efficient as
long as the tool is used correctly and is well supported and documented by its authors.</font>
</li>
<li><font COLOR="#000000">Also, when adding new extensions to your applications, consider
the advantages of building simple stand-alone versions of the target application instead
of adding features to existing applications. There are times when a stand-alone solution
is most efficient. However, if you need to deploy MAPI, SAPI, or TAPI services to a large
number of people who already have products they know and use often, it may be simpler to
distribute add-ins or extensions instead of attempting to replace well-established user
tools.</font> </li>
<li><font COLOR="#000000">As a general rule, if your application needs to distribute
information to a wide number of locations on demand, mostly in ASCII text format, your
best bet is to use MAPI services. If, however, you need to send binary data to just a few
sites on a regular schedule (daily or weekly, for example), you should consider building
smaller, more focused dedicated dialing applications that use the Comm API (or OCX).</font>
</li>
<li><font COLOR="#000000">Client-side applications usually need only outbound calling
services. It is quite possible that you can meet client-side design goals using Assisted
TAPI services and simple data/fax modems. If, however, you are building applications that
will act as telephony server devices-answering and routing incoming calls-you'll need to
use Full TAPI, and you will probably need a full-featured telephony card, too.</font> </li>
<li><font COLOR="#000000">Finally, current speech technology is more consistent when
delivering TTS (text-to-speech) services than SR (speech recognition) services. The SAPI
system requires a hefty pool of memory (no less than 16MB is recommended on the
workstation). Also, SR services are not always accurate. It is best to offer SAPI services
as an additional, rather than primary service at this time. As the technology matures and
users become more accustomed to hearing TTS output and to speaking in a manner more easily
understood by SAPI systems, you can increase the use of speech services in your
applications.</font> </li>
</ul>
<p>If you keep these general rules in mind, you'll save yourself a lot of headaches when
it comes time to deploy multiple-service applications. </p>
<h2><b><a NAME="TheFaxBackApplication"><font SIZE="5" COLOR="#FF0000">The </font><tt><font
SIZE="5" COLOR="#FF0000" FACE="Courier">FaxBack</font></tt><font SIZE="5" COLOR="#FF0000"
FACE="MCPdigital-B"> </font><font SIZE="5" COLOR="#FF0000">Application</font></a></b></h2>
<p>In <a HREF="ch34.htm">Chapter 34</a>, "Building the <tt><font FACE="Courier">FaxBack</font></tt>
Application," you built a Visual Basic 4.0 project that combined TAPI and MAPI
services to create a dialup fax server. With this application running on a workstation,
users can dial into the workstation, receive prompts for entering their own FAX telephone
number, and select a document number. Then, when the user hangs up, the workstation
formats and sends the selected FAX document to the user's FAX address. </p>
<p>This project used an evaluation version of Pronexus' VBVoice telephony control set. The
VBVoice controls were used to answer the incoming call, and prompt the caller through
entering their FAX number and the selected document number. Once this was done, the
VBVoice controls turned the collected data over to the MAPI system for delivery of the
selected FAX. </p>
<p>The Simple Mail API (SMAPI) interface was used to provide access to the message
services of Windows. The SMAPI interface was chosen because it has a very small
"footprint." While the <tt><font FACE="Courier">MAPI.OCX</font></tt> controls
and the OLE Messaging library would also work fine, the SMAPI provided all the MAPI access
that was needed for the FaxBack project. This was a good example of how you can simplify
programming and deployment by selecting the simplest implementation model that fulfills
the project requirements. </p>
<h2><a NAME="TheVoicePhoneApplication"><b><font SIZE="5" COLOR="#FF0000">The Voice Phone
Application</font></b></a></h2>
<p>In <a HREF="ch35.htm">Chapter 35</a>, "Creating the Voice Phone Application,"
you used SAPI and TAPI services to create a true "hands-free" telephone. With
this program and a pc speaker phone, users can look up and dial telephone numbers by
simply speaking voice commands to the workstation. Users are able to initiate database
adds, edits, and deletes, or issue a voice command that will search the database for a
name. Users can also tell the program to <i>Dial Mike</i> and Voice Phone will locate the
record in the database, pull up the phone number, place the call, and prompt the user to
begin speaking. </p>
<p>As an added bonus, this program has audible responses to help requests, and speaks the
names and telephone numbers of selected records in the database. Even the About box is
"read" to you. </p>
<p>Again, a simple TAPI interface was all that was needed for this project. Instead of
adding Full TAPI services to the application, only Assisted TAPI was implemented. This
provided all the power and features needed to implement a voice-activated outbound dialing
program. </p>
<h2><a NAME="TheTalkMailProject"><b><font SIZE="5" COLOR="#FF0000">The Talk Mail Project</font></b></a></h2>
<p><a HREF="ch36.htm">Chapter 36</a>, "The Talk Mail Project," presented the
last integration project in the book, in which you combined MAPI services with an audio
recording. The Talk Mail project allows you to record messages, and then send them to
others via e-mail. It's a bit like an asynchronous telephone conversation. </p>
<p>With Talk Mail you can select one or more recipients, press the record button, record a
message, and ship both the header data and the audio binary file to any other person(s) in
the MAPI directory. </p>
<p>The OLE Messaging library was used to implement the MAPI services for this program.
This offered the ability to define a unique message class for audio e-mail. This way, the
Talk Mail client can search incoming mail for audio messages, and present only those to
the user for review. </p>
<p>The audio recording was handled using the Windows Media Control Interface (MCI). The
Visual Basic 4.0 MCI control provided easy access to recording, storage, and playback
facilities for WAV format audio files. Adding WAV support for an e-mail client is as easy
as adding the MCI control to a project. </p>
<p>This project also made use of the new Windows 95 controls for Visual Basic, including
the <tt><font FACE="Courier">listview</font></tt> control, the <tt><font FACE="Courier">toolbar</font></tt>
control, and the <tt><font FACE="Courier">statusbar</font></tt> control. </p>
<h2><a NAME="SomeFinalRemarks"><b><font SIZE="5" COLOR="#FF0000">Some Final Remarks</font></b></a></h2>
<p>The material in this book covers the multiple implementations of MAPI services, SAPI
services, and TAPI services for 32-bit Windows operating systems. Even though this book is
no quick read, it does not cover the three important Windows extension services
completely. No single book could hope to accomplish that. The best way to learn about each
of these API sets in detail is to work with them in your own programs. Only through
constant experimentation and invention will you really learn the intricacies of these
important Windows services. </p>
<p>It's also important to keep up with the latest developments regarding each of these API
services. You can find lots of pointers to online and printed resources in the appendixes
at the back of this book. You'll even find a Web site dedicated to supporting this book (<tt><font
FACE="Courier">iac.net/~mamund/CDGPage.htm</font></tt>). </p>
<p>I hope you'll find this book helpful in your quest to learn more about MAPI, SAPI, and
TAPI implementations. I suspect many of you have already been struck with new ideas on how
you can use these services to create new and valuable Windows applications. I also hope to
hear from many of you as you discover new ways to bring speech, telephony, and e-mail
services to the desktop. You can write me at my e-mail address (<tt><font FACE="Courier">MikeAmundsen@msn.com</font></tt>),
or visit the Web site. I look forward to hearing from you. </p>
<p>Good luck!<br>
MCA </p>
<hr WIDTH="100%">
<p align="center"><a HREF="ch36.htm"><img SRC="pc.gif" BORDER="0" HEIGHT="88" WIDTH="140"></a><a
HREF="#CONTENTS"><img SRC="cc.gif" BORDER="0" HEIGHT="88" WIDTH="140"></a><a
HREF="index.htm"><img SRC="hb.gif" BORDER="0" HEIGHT="88" WIDTH="140"></a> <a
HREF="appa.htm"><img SRC="nc.gif" BORDER="0" HEIGHT="88" WIDTH="140"></a></p>
<hr WIDTH="100%">
<layer src="http://www.spidersoft.com/ads/bwz468_60.htm" visibility="hidden" id="a1" width="600" onload="moveToAbsolute(ad1.pageX,ad1.pageY); a1.clip.height=60;visibility='show';">
</layer>
</body>
</html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -