📄 article2.htm
字号:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<HTML><HEAD><TITLE>Article 2. Libraries Made Too Easy</TITLE></HEAD>
<!--DocHeaderStart-->
<BODY bgcolor="#ffffff" text="#000000" leftmargin=0 topmargin=0 link="#0080C0" vlink="gray">
<BR>
<table width=100% border=0 cellspacing=0 cellpadding=0>
<TR>
<TD WIDTH="10" VALIGN=TOP> </TD>
<TD VALIGN="TOP">
<!--DocHeaderEnd-->
<!-- This is a PANDA Generated HTML file. The source is a WinWord Document. -->
<P><h1>Article 2. Libraries Made Too Easy</h1>
<P>Bruce McKinney
<P><!--DATE-->April 18, 1996
<P><!--/DATE-->
<P>Microsoft® Visual Basic® 4.0 may have come as kind of a shock to those poor unfortunates who wrote large dynamic-link libraries (DLLs) to enhance Visual Basic 3.0. Although Microsoft promised compatibility with old Basic programs (and for the most part came through), it never made any promises about compatibility of DLLs. Rather than risk breaking every control ever written, Microsoft provided a compatibility layer for running VBX controls in 16-bit Visual Basic 4.0. But it provided no compatibility layer for DLLs that weren't controls. And of course, it would have been pretty difficult to make 16-bit DLLs or controls very compatible with their 32-bit counterparts.
<P>So this article (second of five in a series) will start at ground zero. I assume that you have never written a DLL for Visual Basic. If you managed to figure out the instructions in the VB4DLL.TXT file (supplied with version 4.0) and create a DLL (despite the lack of sample code), humor me. Forget everything you learned and start over with me. You can skim if you think you already know it, but I'm going to be introducing some topics that will be very important in later articles, so skip this one at your peril.
<P><h2>The Three Levels of DLL Programming</h2>
<P>There are several different ways to add procedures written in C++ (or some other compiled language) to your Visual Basic programs. Following are three ways that I discuss in some depth in this series.
<P><UL><LI> <b>Level 1.</b> Write your programs using the same style and following the same rules as the application programming interface (API) functions in system DLLs. This is an excellent choice if you happen to be on the Windows® programming team and are writing a new DLL for use by all Windows programs in all languages. But you aren't. This approach used to have some appeal because it was the only way to write language-independent DLLs for use from any language. Most languages handle numbers pretty much the same, but they have different ways of dealing with strings, arrays, and untyped variables. The system API format, although not documented as a standard, provides a compromise that works moderately well in all languages, but not very well in any language. Basic procedures you write using this style don't look like Basic procedures. This chapter will cover how to process numbers and structures at level 1, but I'm not going to say much about the old-fashioned way of doing strings and arrays.
<LI> <b>Level 2.</b> Use OLE types to create DLL functions that work transparently in Visual Basic and other OLE-compatible languages. The three OLE types you need to understand are BSTR, VARIANT, and SAFEARRAY. Numeric types work the same as in level 1. By using these types, you can make your new Basic procedures look like built-in Basic procedures. It's the polite thing to do, but implementation is more difficult. So what. You do extra work so that your customers do less work. Articles 3, 4, and 5 of this series will make the work, well, not exactly easy, but tolerable. Those of you who wrote the Visual Basic 3.0 equivalent of this type of DLL using the VBAPI library have a head start. You must forget the specifics of what you already know, but it's just another API. The principles are the same.
<LI> <b>Level 3.</b> Write OLE objects just like the ones provided by Visual Basic. You can make objects that look like objects--similar to controls and the DAO--or you can make objects that look like libraries--similar to the Visual Basic and Visual Basic for Applications libraries. This is the right thing to do because objects you write this way can raise errors, be collected in collections, have methods and properties, and do all sorts of other wondrous things that haven't even been invented yet. Alas, I'm not going to tell you how to go to level 3 in this series. Maybe another time.
</UL>This chapter tells how to write DLLs at level 2. The part of level 1 that is a subset of level 2 is also covered. Most of what you learn here will carry over when you start writing level 3 objects and libraries.
<P><h2>The Mechanics of Building DLLs</h2>
<P>We have to wade through some tedious mechanical issues before we can get to the fun of real programming. I'll use my Visual Basic Utilities DLL as an illustration.
<P>The VBUTIL DLL was provided in 16- and 32-bit formats with my book <i>Hardcore Visual Basic</i>. It contained various functions for fiddling bits, making Win32 functions more Basic-friendly, and doing a few other tasks that Basic doesn't handle. These articles provide an updated 32-bit version with a few more functions and some enhanced programming tools. The old version was written in C, but this version is in C++ and takes advantage of some C++ types (classes) that will be introduced in this article and explained in detail in subsequent articles.
<P><h3>The Sample Code</h3>
<P>The sample code for this article (and for articles 3, 4, and 5) consists of two libraries--one static, one dynamic. The OleType library is a static library intended for C++ programmers. VBUtil is a dynamic-link library intended for Visual Basic programmers. The VBUtil library uses the OleType library. When you write your own DLLs for Visual Basic, you抣l use VBUtil as a model. You抣l use OleType as a tool.
<P>The OleType library comes in two versions--Release and Debug. There are no separate Unicode™ versions of this library because Unicode conversion is handled at run time through function overloading, as you抣l see in Article 3. VBUTIL32.DLL can be built four different ways--ANSI Debug, ANSI Release, Unicode Debug, and Unicode Release. In fact, there is only one version of the file because registering four different DLLs under Visual Basic would be too much trouble. Changing the build settings overwrites the previous version. The Visual Basic project, Cpp4VB.VBP, gives the procedures in VBUTIL32.DLL a workout.
<P>The .ZIP file with the samples for this series contains a README.TXT file with specific instructions for setting up and building the sample libraries.
<P><h3>Static and Dynamic Library Summary</h3>
<P>Let抯 look at the parts of the two libraries in more detail. First, the following table shows the files in the OLETYPE project:
<P>
<TABLE WIDTH=87% BORDER=1 CELLPADDING=5 CELLSPACING=0>
<TR VALIGN=TOP BGCOLOR="#DDDDDD">
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2><b>File</b></FONT></TD>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2><B>Description</B></FONT></TD></TR>
<TR VALIGN=TOP>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>OLETYPE.MDP and OLETYPE.MAK</FONT></TD>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>These are the Microsoft Developer Studio project files. If you use a different compiler, you will have to use its project format. </FONT></TD></TR>
<TR VALIGN=TOP>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>OLETYPE.H</FONT></TD>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>This file defines the standard OLE types described later in this chapter. It includes the BSTRING.H, VARIANT.H, and SAFEARRAY.H files described below so that clients see only one include file.</FONT></TD></TR>
<TR VALIGN=TOP>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>BSTRING.H and BSTRING.CPP</FONT></TD>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>These files declare and implement a new String type that encapsulates the OLE BSTR type.
</FONT></TD></TR>
<TR VALIGN=TOP>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>VARIANT.H and VARIANT.CPP</FONT></TD>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>These files declare and implement a new Variant type that encapsulates the OLE VARIANT type.</FONT></TD></TR>
<TR VALIGN=TOP>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>SAFEARRAY.H</FONT></TD>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>This file declares and implements a new SafeArray template type that encapsulates the OLE SAFEARRAY type. Where's the .CPP file? Article 5 will explain.</FONT></TD></TR>
<P></TABLE>
<P>.<P>The result of building this project is one of the two static libraries---OleType.Lib or the debug version, OleTypeD.Lib. The OleType.H and OleType.Odl include files should be considered part of the library. Put them in your include directory and include them in the appropriate files of any projects that use the OleType library.
<P>The following table shows files for the VBUTIL project.
<P>
<TABLE WIDTH=87% BORDER=1 CELLPADDING=5 CELLSPACING=0>
<TR VALIGN=TOP BGCOLOR="#DDDDDD">
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2><b>File</b></FONT></TD>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2><B>Description</B></FONT></TD></TR>
<TR VALIGN=TOP>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>VBUTIL.MDP and VBUTIL.MAK</FONT></TD>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>These are the Microsoft Developer Studio project files. If you use a different compiler, you will have to use its project format.
</FONT></TD></TR>
<TR VALIGN=TOP>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>VBUTIL.DEF</FONT></TD>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>The .DEF file is required to define exports for new functions.</FONT></TD></TR>
<TR VALIGN=TOP>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>VBUTIL.RC
</FONT></TD>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>The only resources here are version resources. You could also embed the type library as a resource. Later I'll explain why VBUTIL doesn't.
</FONT></TD></TR>
<TR VALIGN=TOP>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>VBUTIL.ODL</FONT></TD>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>Polite DLLs should provide a type library so that clients don't have to bother with <b>Declare</b> statements. Article 1 describes type library source files. This article adds a few more details. </FONT></TD></TR>
<TR VALIGN=TOP>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>VBUTIL.CPP and VBUTIL.H</FONT></TD>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>These files just provide initialization and termination routines, global variables, error handling, and definitions used by any DLL. The real functionality goes in separate source files. They also serve as the base files for precompiled headers. </FONT></TD></TR>
<TR VALIGN=TOP>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>TOOLS.CPP and TOOLS.H</FONT></TD>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>These files provide some general utility functions for manipulating bits and other chores that can't be done easily in Visual Basic. This article contains several samples from these files.</FONT></TD></TR>
<TR VALIGN=TOP>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>WIN32.CPP and WIN32.H</FONT></TD>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>These files provide Basic-style implementations of some Win32® functions that are difficult to use in Visual Basic. You'll see examples in Articles 3 and 4.</FONT></TD></TR>
<TR VALIGN=TOP>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>OLETYPE.H, OLETYPE.ODL, and OLETYPE<i>x</i>.LIB</FONT></TD>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>These files provide definitions of standard OLE types. See Articles 3, 4, and 5.</FONT></TD></TR>
<TR VALIGN=TOP>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>TEST.CPP and TEST.H</FONT></TD>
<TD><font face="Verdana, Arial, Helvetica, Sans-Serif" SIZE=2>These files provide test functions that systematically test the <b>String</b>, <b>Variant</b>, and <b>SafeArray</b> classes. You could put this module in conditionals so that it won't be built in release builds.</FONT></TD></TR><P>
</TABLE>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -