The Windows API Type Library

The Windows API type library supplied with this book eliminates the need to write Declare statements—almost. Chapter 2 explains why my code uses only a handful of Declare statements in very limited circumstances. All the other declares, types, and constants for Windows API functions come from my type library. Once you install this type library, the Windows API becomes just another part of Visual Basic. For many programmers, the type library can save more than enough time to justify the cost of this book. This version is much more comprehensive and powerful than the one provided with the first edition. Visual Basic version 5 does a better job of supporting type libraries so I was able to add more types and change many constants to Enums. I also added two features that you can’t get through Declare statements: interfaces and Unicode function definitions.

The source code for the type library is provided on the companion CD as an example of type library syntax, but as with my components, I request that you send bug reports to me rather than fix any problems you find in my library. Writing a comprehensive type library would be a full-time job since Microsoft seems to release a new API or system interface every day. If you don’t find support for your favorite API, you can use my source as a template for extending the library. If you want to win fame and the gratitude of other hardcore programmers (but no fortune), send me your source and I’ll integrate it (with credit) into the official library.

The CommonConst module of the type library needs a little more explanation. It contains constants I use frequently plus some of the constants that Visual Basic won’t let you define. You’ll see these constants throughout the book. Visual Basic offers equivalents for some, but not all, of my constants. The most useful constant, for example, is a carriage return/linefeed combination. I call it sCrLf;
Visual Basic calls it vbCrLf. I call my version of a null pointer sNullStr; they call theirs vbNullString. My version of an empty string is called sEmpty; theirs is
called "". In other words, they don’t have one. The origin of this discrepancy goes back to the beta period of Visual Basic version 4 when I donated my type library source for common constants to Visual Basic, and then enhanced my version after theirs had been cast in stone.