Limits of Procedure Pointers

First, let me make one thing clear. The new AddressOf operator affects only calls to Windows API functions and other DLL calls. It has nothing to do with solving the problems that procedure parameters solve in other languages. Those problems are solved by other hacks in Visual Basic, as described in “Sorting, Shuffling, and Searching,” page 282. What AddressOf does do is eliminate the need for message tools such as Message Blaster and callback tools such as the Callback Server—both provided with the first edition of my book.

Message Blaster remains the easiest, most reliable method for softcore programmers to handle messages. The Callback Server still exists, and it will work fine in Visual Basic version 5. You don’t have to change anything. I personally prefer to use AddressOf for most simple callback tasks because I don’t like to add an extra component to my programs, but there are a few major caveats to keep in mind when using AddressOf:

• There is no type safety. You’re dealing with pure, raw pointers, and you must live with the consequences.
  
  
• AddressOf doesn’t work with objects. You can get the address of a pro­cedure in a standard module, but you can’t get the address of a method on an object. AddressOf is not hard to use, but very difficult
  to encapsulate, even though it’s the kind of ugly, low-level stuff that you most want to encapsulate. Despite the difficulties, we’ll encapsulate it in Chapter 6.
  
  
• Callback procedures don’t know Basic. In particular, they don’t know about Basic strings. It takes a whole different level of hacking to deal with strings passed as parameters to callback procedures.

So. Before us we see a freshly chopped hole in the frozen lake. Let’s take our clothes off and jump in.