Visual Basic does a good job of shielding developers from the nitty-gritty details of Windows. However, there comes a point where you can no longer hide behind the safe walls of VB. Windows is out there, waiting to talk to your program.

Windows provides a number of function calls, in the form of DLLs, that are useful to VB programmers. You can also co-opt DLLs from other programs to do work for you. We'll concentrate on using the Windows DLLs here, but what we learn is widely applicable.

In this chapter you'll learn:

   How to declare API and DLL functions in your programs and how to utilize the underlying power of Windows
   How to use the API to harness the power of multimedia in your VB applications

In this chapter we're really going to focus on the issues surrounding calling code that lives in the Windows API. There's also something known as DLL Callback facilities available in Visual Basic 5 which, instead of you calling code in the API, allows you to make use of certain API calls that will call your code as part of their working process. Believe me-this can be really useful, but it is alas a little beyond our scope here.

Enough with the waffle-on with the show.

How VB and Windows Fit Together

In this chapter we're going to look at how to use tools that lie outside what you might consider as Visual Basic, meaning functions and procedures that are actually part of Windows itself. These are pieces of code that Windows has at its disposal to do what it has to do: manage your applications and provide a consistent user interface and operating environment for your programs.

This sounds complicated, but it isn't. The first thing to note is that we've effectively used part of the Windows code already, without really knowing it, when we used the common dialog control. Let's consider for a while what's really happening when we do this.

DLLs the Easy Way - The Common Dialog

You remember the common dialog. It's that great little control that is a window on to a load of different dialogs. Here's the file open dialog:

These dialogs not only save us time, but also give our programs the look and feel of a real Windows application. The reason they're called common dialogs is that they look the same in all Windows applications. So what's the story (morning glory)? It makes you wonder whether they aren't really part of Windows after all....

Well actually they are. If you load up Explorer and take a look in your Windows\System directory you'll see a file named Comdlg32.DLL.

This file contains all the code needed to create the various common dialogs that Windows supports. Lumping all this code together in a file stored in a shared directory makes it accessible to all Windows programs, including Windows itself.

You can't look inside it-it's a compiled lump of C/C++ code and would look like gobbledygook. What interests us, of course, is how we can talk to this little monster and tell it what to do, from our VB code. To understand that, we'll have to take a quick lesson in how Windows works. Bear with me-there is a point.

Dynamic Link Libraries

The Comdlg32.dll file is what's known as a dynamic link library, hence the file extension. To you and me, this means that it's a block of code containing procedures and functions that are useful for more than one program; it is available to any program that wants to use it. The question is, of course-how?

Let's take a quick lesson in the history of programming. If this really is your first toe in the water of programming, then you don't need to bother to read this. Think yourself lucky you got into the game at the right time, and skip this next bit and jump straight to the bit titles the Windows API.

What is 'Linking'?

Traditional programming languages like C, when you use them outside an environment like Windows, like to operate as stand-alone blocks. This means that when you compile the program, you end up with an executable file that is self-contained, and doesn't need any other files to run (unlike say a .vbp file which requires Visual Basic to run). All the code it needs is 'hardwired' into the body of the program.

This doesn't mean you can't use prewritten code-there are lots of C libraries out there that are very widely used. The question, then, is how do you get the prewritten code into your program. This is what is meant by linking, and it can be done in two ways-static linking and dynamic linking.

Static Linking

In static linking, you provide fixed links between your program and the prewritten modules at design time, just like when you create a module in a VB project and call procedures in it from other parts of your code. However, in order to use these prewritten lumps of code, you have to effectively copy them into your final file at compile time in a process called static linking. After that, they are part of your program, locked away in your executable file.

Dynamic Linking

This is the opposite of static linking, and if you understand how it works, you'll see why dynamic linking is a good plan. In dynamic linking, the external library file never gets bound into the final executable file. It remains outside the program as a DLL, hopefully in a place where the executable file can find it and send it messages. At run time, these messages are function or procedure calls, requesting that certain parts of the DLL code are executed.

To link your executable and the DLL it needs to run, you just tell your program where the DLL is, and which bit of code you want to run from inside it. It's up to your program to make the connection when the big moment arrives. It is, as they say, dynamically linked.

The Visual Basic DLLs

Perhaps the most graphic illustration of dynamic linking is Visual Basic itself. Take a peek into your Windows System directory and you should see a set of files that comprise VB's run-time engine. For example VB5DB.DLL contains some of the code necessary to link to the Data Access Objects at run time should your application choose to look at a local database.

When you write a database application and compile it, even if you compile to a fully independent compiled application rather than simply an interpreted one, the resulting EXE file knows nothing about databases, what they do or how to deal with them. Instead, your application includes a block of code provided by Visual Basic itself, which at run time loads up that VB5DB.DLL file and uses the functions contained within.

The Advantages of Dynamic Linking

Of course, with dynamic linking, you have the hassle of making sure that all the DLLs a program needs are present, in the right place, and in the right version. However, while this is not a trivial problem, you are well taken care of by Windows and VB in this respect. And the advantages of dynamic linking are real and important.

Consistency

Users like Windows because it has a more or less common user interface across applications. To achieve this, it helps if you generate as much of your user interface as possible from common code. The common dialog, along with the new Office 97 menus, toolbars, etc., are good examples of this.

Maintenance

By having a lot of common code in one place, you can update and amend that code centrally, and the changes are reflected in all the applications that use it. That's why, when you run Windows 3.1 applications on Windows 95, they inherit some user interface features of the new system. This applies to Visual Basic as well.

Smaller Executables

By moving a lot of the back room business out to another file, rather than statically linking the functions and procedures, you can reduce the size of your executable. The flip side of this is that the DLL files tend to be massive as they need to contain every possible piece of code they support, not just the ones you need. However, they are shared across many applications, so there's still a net gain.

The Windows Architecture

Dynamic linking is fundamental to the design of Windows. Windows is really just a bag of DLLs that the various applications you run use to do their jobs. In fact, even things that you think of as being Windows itself, like the desktop and Explorer, are just applications that run like any other program, calling the procedures from the intrinsic Windows DLLs as you need them.

The great news is that they aren't the only ones that can tap into the Windows DLL goodie bag. All those DLLs are sitting there waiting to work, and they'll work for anyone who shows up with the right program code. If the mood takes you, you can even replace the Windows desktop with your own version, although I'd suggest we leave that one for a rainy day.

There a lot of DLLs that ship with Windows to give it all the functionality it needs. Inside each of these is anything from a handful, to hundreds of available functions and procedures. Collectively, these 1000+ individual routines are called the Windows API.

The Windows API

The Windows Application Programmer's Interface (API) is a collection of ready-made functions and procedures. These have traditionally been the domain of C and C++ programmers-the way that the connections to the API operate are more intuitive for C and C++ programmers, for whom arcane and incomprehensible syntax are a stock in trade.

Visual Basic was created to free us from the kind of drudgery that bedevils C/C++ Windows development, and this extends to the API as well. Most of the API calls are already implemented in Visual Basic in the form of VB commands, keywords, methods and properties. These are translated into the corresponding API calls inside VB. In a way, VB is a friendly wrapper around the Windows API.

However, there are still some API functions for which Visual Basic has no substitute. For example, standard Visual Basic has no way for the programmer to get real control of the Windows multimedia system. OK, you can embed files in OLE controls, or use other custom controls. But with the API you can achieve great effects without the overheads of lots of other controls.

Working with the Multimedia API is easy. Well, relatively speaking. Although there's nothing to be frightened of, using API calls in VB is a little fiddly at times. However, armed with a clear understanding of what to do and why you're doing it, you can unlock the power of the API.

Page 1 2 3 4 [NEXT >>]
Back to Tutorials - Main